I was tinkering with the Merlin assembler under ProDOS (Merlin-Pro 
2.54). For some reason, the Q (quit) command crashes under ProDOS 
2.0.3 and ProDOS 1.1.1.

I found a disk of documentation on Asimov, and I extracted all 128K 
into a text file. Strangely, chapter 8 is not present. Can anyone 
tell me what this chapter is about?

Thanks!

-- 
John
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

"John B. Matthews" <nospam@nospam.com> wrote in message
news:nospam-932B15.10342106022005@news-server-fe-02.columbus.rr.com...
: I was tinkering with the Merlin assembler under ProDOS (Merlin-Pro
: 2.54). For some reason, the Q (quit) command crashes under ProDOS
: 2.0.3 and ProDOS 1.1.1.
:
: I found a disk of documentation on Asimov, and I extracted all 128K
: into a text file. Strangely, chapter 8 is not present. Can anyone
: tell me what this chapter is about?
:
: Thanks!

For $5 to cover the cost of media and shipping,
I can send you a disk woth all of Merlin on it.  :o)

Apple II Forever, Apple II Together
Bill @ GarberStreet Enterprizez
Web Site - http://garberstreet.netfirms.com
Email - willy46pa@comcast.net

John B. Matthews wrote:
> I was tinkering with the Merlin assembler under ProDOS (Merlin-Pro 
> 2.54). For some reason, the Q (quit) command crashes under ProDOS 
> 2.0.3 and ProDOS 1.1.1.
> 
> I found a disk of documentation on Asimov, and I extracted all 128K 
> into a text file. Strangely, chapter 8 is not present. Can anyone 
> tell me what this chapter is about?

Chapter VIII is Technical Information, a 7-page chapter covering
internals, like memory allocation and configuration for both the
DOS 3.3 and the ProDOS versions of Merlin Pro (8-bit version).

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

In article <O_-dnXuL3YGh4pvfRVn-2A@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> John B. Matthews wrote:
[...]
> > I found a disk of documentation on Asimov, and I extracted all 128K 
> > into a text file. Strangely, chapter 8 is not present. Can anyone 
> > tell me what this chapter is about?
> 
> Chapter VIII is Technical Information, a 7-page chapter covering
> internals, like memory allocation and configuration for both the
> DOS 3.3 and the ProDOS versions of Merlin Pro (8-bit version).
> 
> -michael

Thanks Michael & Bill. In addition, I found helpful information here:

http://www.cs.nyu.edu/~cdm232/appleml/merlin/index.html

I was intrigued to learn that Merlin does indeed descend from the 
Randy  Wiggington's "weekend assembler," TED II. I've often been 
troubled by the divergent syntax used for specifying the hi/lo byte 
of 16-bit immediate operands.

-- 
John
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

"John B. Matthews" <nospam@nospam.com> wrote in message

> I found a disk of documentation on Asimov, and I extracted all 128K
> into a text file. Strangely, chapter 8 is not present. Can anyone
> tell me what this chapter is about?

<THIS CHAPTER LEFT INTENTIONALLY BLANK>

just kidding....

John B. Matthews wrote:

> I was intrigued to learn that Merlin does indeed descend from the 
> Randy  Wiggington's "weekend assembler," TED II. I've often been 
> troubled by the divergent syntax used for specifying the hi/lo byte 
> of 16-bit immediate operands.

I'm so used to Merlin that I was unaware of other conventions.

Think of "<" as "less" significant, or "smaller", and ">" as
"greater" significance, or "larger".  Or think of "<" as the
lower addressed (left) part of a 16-bit number and ">" as the
higher (right) address.

(Of course, only ">" actually does anything, since any context
requiring an 8-bit value will simply use the low-order byte
of a 16-bit value in Merlin.)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

"Michael J. Mahon" wrote:
> Think of "<" as "less" significant, or "smaller", and ">" as
> "greater" significance, or "larger".  Or think of "<" as the
> lower addressed (left) part of a 16-bit number and ">" as the
> higher (right) address.

Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
the high byte.  I never use #<VAL or #>VAL because I own 6502
assemblers that use them in exactly the opposite way.

Another habit I have is using #0-5 instead of #-5 because I
used an assembler that could not understand a unary minus but
did understand a subtraction.

--
Paul R. Santa-Maria
Monroe, Michigan USA

In article <4208428C.5C714B48@buckeye-express.com>,
 "Paul R. Santa-Maria" <paulrsm@buckeye-express.com> wrote:

> "Michael J. Mahon" wrote:
> > Think of "<" as "less" significant, or "smaller", and ">" as
> > "greater" significance, or "larger".  Or think of "<" as the
> > lower addressed (left) part of a 16-bit number and ">" as the
> > higher (right) address.

When using Apple, Kyan and various cross-platform assemblers that 
use the opposite syntax, I came to think of #< as "left side" (hi) 
and #> as "right side" (lo).

> Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
> the high byte.  I never use #<VAL or #>VAL because I own 6502
> assemblers that use them in exactly the opposite way.

Excellent! Looking back I see that I used this in macros.

> Another habit I have is using #0-5 instead of #-5 because I
> used an assembler that could not understand a unary minus but
> did understand a subtraction.
> 
> --
> Paul R. Santa-Maria
> Monroe, Michigan USA

Thank you gentlemen!

-- 
John
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

funny it was

John B. Matthews wrote:
> In article <4208428C.5C714B48@buckeye-express.com>,
>  "Paul R. Santa-Maria" <paulrsm@buckeye-express.com> wrote:
> 
> 
>>"Michael J. Mahon" wrote:
>>
>>>Think of "<" as "less" significant, or "smaller", and ">" as
>>>"greater" significance, or "larger".  Or think of "<" as the
>>>lower addressed (left) part of a 16-bit number and ">" as the
>>>higher (right) address.
> 
> 
> When using Apple, Kyan and various cross-platform assemblers that 
> use the opposite syntax, I came to think of #< as "left side" (hi) 
> and #> as "right side" (lo).

Ah, but that is a "big endian" view of memory.  ;-)

>>Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
>>the high byte.  I never use #<VAL or #>VAL because I own 6502
>>assemblers that use them in exactly the opposite way.
> 
> Excellent! Looking back I see that I used this in macros.

I have also used this in macros, since it allows taking
the MSByte of any expression, not just a variable.

I have never been very concerned about the "portability"
of assembly code to other assemblers, since most of my
programs use macros and other features that tend to be
peculiar to each assembler.  My standardization on Merlin
came early and has persisted.

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
news:EvidncT2FKE6a5XfRVn-qQ@comcast.com...
: John B. Matthews wrote:
: > In article <4208428C.5C714B48@buckeye-express.com>,
: >  "Paul R. Santa-Maria" <paulrsm@buckeye-express.com> wrote:
: >
: >
: >>"Michael J. Mahon" wrote:
: >>
: >>>Think of "<" as "less" significant, or "smaller", and ">" as
: >>>"greater" significance, or "larger".  Or think of "<" as the
: >>>lower addressed (left) part of a 16-bit number and ">" as the
: >>>higher (right) address.
: >
: >
: > When using Apple, Kyan and various cross-platform assemblers that
: > use the opposite syntax, I came to think of #< as "left side" (hi)
: > and #> as "right side" (lo).
:
: Ah, but that is a "big endian" view of memory.  ;-)
:
: >>Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
: >>the high byte.  I never use #<VAL or #>VAL because I own 6502
: >>assemblers that use them in exactly the opposite way.
: >
: > Excellent! Looking back I see that I used this in macros.
:
: I have also used this in macros, since it allows taking
: the MSByte of any expression, not just a variable.
:
: I have never been very concerned about the "portability"
: of assembly code to other assemblers, since most of my
: programs use macros and other features that tend to be
: peculiar to each assembler.  My standardization on Merlin
: came early and has persisted.

Let me at this point verify for my own record that a "Macro"
is a snippet of code that performs a function that I do a lot and
I just insert the Macro name where I want this done. Am I at
all correct???  For example, instead of placing in a jump to a
place where this code would be, I simply insert the macro name
and the assembler adds that snippet of code at that location.
This is just to rectify my own mind. Are their any other short-
cuts that you can use to simplify your source code??   :o)

Pages in manual will suffice so I can read up on them. Please,
bive manual name and page number with each example, if you
would happen to know or have it handy.

Thanks,

Apple II Forever, Apple II Together
Bill @ GarberStreet Enterprizez
Web Site - http://garberstreet.netfirms.com
Email - willy46pa@comcast.net

Bill Garber wrote:
> "Michael J. Mahon" <mjmahon@aol.com> wrote in message
> news:EvidncT2FKE6a5XfRVn-qQ@comcast.com...
> : John B. Matthews wrote:
> : > In article <4208428C.5C714B48@buckeye-express.com>,
> : >  "Paul R. Santa-Maria" <paulrsm@buckeye-express.com> wrote:
> : >
> : >
> : >>"Michael J. Mahon" wrote:
> : >>
> : >>>Think of "<" as "less" significant, or "smaller", and ">" as
> : >>>"greater" significance, or "larger".  Or think of "<" as the
> : >>>lower addressed (left) part of a 16-bit number and ">" as the
> : >>>higher (right) address.
> : >
> : >
> : > When using Apple, Kyan and various cross-platform assemblers that
> : > use the opposite syntax, I came to think of #< as "left side" (hi)
> : > and #> as "right side" (lo).
> :
> : Ah, but that is a "big endian" view of memory.  ;-)
> :
> : >>Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
> : >>the high byte.  I never use #<VAL or #>VAL because I own 6502
> : >>assemblers that use them in exactly the opposite way.
> : >
> : > Excellent! Looking back I see that I used this in macros.
> :
> : I have also used this in macros, since it allows taking
> : the MSByte of any expression, not just a variable.
> :
> : I have never been very concerned about the "portability"
> : of assembly code to other assemblers, since most of my
> : programs use macros and other features that tend to be
> : peculiar to each assembler.  My standardization on Merlin
> : came early and has persisted.
> 
> Let me at this point verify for my own record that a "Macro"
> is a snippet of code that performs a function that I do a lot and
> I just insert the Macro name where I want this done. Am I at
> all correct???  For example, instead of placing in a jump to a
> place where this code would be, I simply insert the macro name
> and the assembler adds that snippet of code at that location.
> This is just to rectify my own mind. Are their any other short-
> cuts that you can use to simplify your source code??   :o)
> 
> Pages in manual will suffice so I can read up on them. Please,
> bive manual name and page number with each example, if you
> would happen to know or have it handy.

Macros are generally what you describe, and their syntax and
semantics vary a lot from implementation to implementation.
(Perhaps that is because most macro generators are their author's
_first_ (and last) macro generator, providing little opportunity
for learning.  ;-)

In the late 1950's Doug MIlroy at Bell Labs added the first general
macro expander onto an assembler for the IBM 709.  In a few years,
it developed a quite general string processing/string substitution
capability, which allowed whole computations to be done at assembly
time in the macro expander!

In the 1960's Christopher Strachey's GPM, and Calvin Mooers' and
Peter Deutsch's TRAC defined the general purpose macrogenerator
as a string-oriented computational model.

In the microprocessor era, many of the lessons of the mainframe era
had to be learned all over again, and macro expanders are no exception.
Most microprocessor macro expanders are quite limited in what they can
do, but all can "regurgitate" a macro definition in-line, and most can
substitute actual arguments supplied with the call for formal arguments
used in the definition.  The real power of macros comes with the
inclusion of conditionals, and operations to dissect and concatenate
strings, as well as define new macros as a side effect of an expansion.

Merlin Pro (8) is a relatively limited macro assembler, with limited
substitution and conditional operations, and no capability to define
or redefine macros during expansion (so it is hard to "remember" things
from one expansion to the next, unless it is a numeric value).

Merlin, curiously, also cannot define a label inside a macro, which
makes it hard to create a DO/UNTIL kind of macro set.

Nevertheless, Merlin's macros are a handy way to codify some useful
snippets of assembly code.  They are documented in the on-line manual
in chapter 7, and conditionals and variables at the end of chapter 6.

Some examples I find useful:

Definition:

align   mac                     ; Align modulo parameter
         ds    *-1/]1*]1+]1-*    ; ]1 is the first supplied parameter
         eom

Use:
         align 256               ; Align to next page boundary

Definition:

inc16   mac                     ; Increment 16-bit word
         inc   ]1
         do    ]1+1/$100         ; If ]1 is non-page zero
         bne   *+5               ; - No carry.
         else                    ; Else if ]1 on page zero
         bne   *+4               ; - No carry.
         fin
         inc   ]1+1              ; Propagate carry.
         eom

Use:
         inc16 count             ; Increment 16-bit count

Definition:

cmp16   mac                     ; Compare 16-bit words
         lda   ]1                ; Lo byte of first operand
         cmp   ]2                ; Lo byte of second operand
         lda   ]1+1              ; Hi byte of first operand
         sbc   ]2+1              ; Hi byte of second operand
         eom

Use:
         cmp16 end;ptr           ; Compare 'end' to 'ptr'
         bcs   :loop             ; Loop if end .ge. ptr

As you can see, macros can save re-creating standard patterns
of code and, when used properly, can actually contribute to
ease of understanding the source code.

Macros are also very useful in table generation, allowing
the table to be expressed in terms of its meaning instead
of its data representation.  Microcomputer macro expanders
are somewhat limited to use for this, in my experience.

Another fundamental use of macros is to contain the effects
of a decision about how something is implemented--abstraction.
In this case, the definition of the macro(s) can be changed
at any time and the program reassembled to incorporate that
change.  For example, the macro "initACIA" could be used to
abstract from exactly what was needed to init a particular
ACIA, so that the remaining code would be independent of
that choice.

Closed subroutines can be used similarly, but at the cost
of linkage instructions and possible parameter passing.
In many cases, a macro expands into a very few instructions,
so that linkage instructions would be a considerable penalty.

Many developers use macros to encapsulate the parameter
setup and calling for subroutines, so that they can easily
change parameter passing and register assignments later if
it should be useful.

Sorry for getting a bit carried away, but for many years
I saw clever macros as the solution to many problems.  ;-)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

Bill Garber wrote:
> "Michael J. Mahon" <mjmahon@aol.com> wrote in message
> news:EvidncT2FKE6a5XfRVn-qQ@comcast.com...
> : John B. Matthews wrote:
> : > In article <4208428C.5C714B48@buckeye-express.com>,
> : >  "Paul R. Santa-Maria" <paulrsm@buckeye-express.com> wrote:
> : >
> : >
> : >>"Michael J. Mahon" wrote:
> : >>
> : >>>Think of "<" as "less" significant, or "smaller", and ">" as
> : >>>"greater" significance, or "larger".  Or think of "<" as the
> : >>>lower addressed (left) part of a 16-bit number and ">" as the
> : >>>higher (right) address.
> : >
> : >
> : > When using Apple, Kyan and various cross-platform assemblers that
> : > use the opposite syntax, I came to think of #< as "left side" (hi)
> : > and #> as "right side" (lo).
> :
> : Ah, but that is a "big endian" view of memory.  ;-)
> :
> : >>Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
> : >>the high byte.  I never use #<VAL or #>VAL because I own 6502
> : >>assemblers that use them in exactly the opposite way.
> : >
> : > Excellent! Looking back I see that I used this in macros.
> :
> : I have also used this in macros, since it allows taking
> : the MSByte of any expression, not just a variable.
> :
> : I have never been very concerned about the "portability"
> : of assembly code to other assemblers, since most of my
> : programs use macros and other features that tend to be
> : peculiar to each assembler.  My standardization on Merlin
> : came early and has persisted.
> 
> Let me at this point verify for my own record that a "Macro"
> is a snippet of code that performs a function that I do a lot and
> I just insert the Macro name where I want this done. Am I at
> all correct???  For example, instead of placing in a jump to a
> place where this code would be, I simply insert the macro name
> and the assembler adds that snippet of code at that location.
> This is just to rectify my own mind. Are their any other short-
> cuts that you can use to simplify your source code??   :o)
> 
> Pages in manual will suffice so I can read up on them. Please,
> bive manual name and page number with each example, if you
> would happen to know or have it handy.

Macros are generally what you describe, and their syntax and
semantics vary a lot from implementation to implementation.
(Perhaps that is because most macro generators are their author's
_first_ (and last) macro generator, providing little opportunity
for learning.  ;-)

In the late 1950's Doug Mclroy at Bell Labs added the first general
macro expander onto an assembler for the IBM 709.  In a few years,
it developed a quite general string processing/string substitution
capability, which allowed whole computations to be done at assembly
time in the macro expander!

In the 1960's Christopher Strachey's GPM, and Calvin Mooers' and
Peter Deutsch's TRAC defined the general purpose macrogenerator
as a string-oriented computational model.

In the microprocessor era, many of the lessons of the mainframe era
had to be learned all over again, and macro expanders are no exception.
Most microprocessor macro expanders are quite limited in what they can
do, but all can "regurgitate" a macro definition in-line, and most can
substitute actual arguments supplied with the call for formal arguments
used in the definition.  The real power of macros comes with the
inclusion of conditionals, and operations to dissect and concatenate
strings, as well as define new macros as a side effect of an expansion.

Merlin Pro (8) is a relatively limited macro assembler, with limited
substitution and conditional operations, and no capability to define
or redefine macros during expansion (so it is hard to "remember" things
from one expansion to the next, unless it is a numeric value).

Merlin, curiously, also cannot define a label inside a macro, which
makes it hard to create a DO/UNTIL kind of macro set.

Nevertheless, Merlin's macros are a handy way to codify some useful
snippets of assembly code.  They are documented in the on-line manual
in chapter 7, and conditionals and variables at the end of chapter 6.

Some examples I find useful:

Definition:

align   mac                     ; Align modulo parameter
         ds    *-1/]1*]1+]1-*    ; ]1 is the first supplied parameter
         eom

Use:
         align 256               ; Align to next page boundary

Definition:

inc16   mac                     ; Increment 16-bit word
         inc   ]1
         do    ]1+1/$100         ; If ]1 is non-page zero
         bne   *+5               ; - No carry.
         else                    ; Else if ]1 on page zero
         bne   *+4               ; - No carry.
         fin
         inc   ]1+1              ; Propagate carry.
         eom

Use:
         inc16 count             ; Increment 16-bit count

Definition:

cmp16   mac                     ; Compare 16-bit words
         lda   ]1                ; Lo byte of first operand
         cmp   ]2                ; Lo byte of second operand
         lda   ]1+1              ; Hi byte of first operand
         sbc   ]2+1              ; Hi byte of second operand
         eom

Use:
         cmp16 end;ptr           ; Compare 'end' to 'ptr'
         bcs   :loop             ; Loop if end .ge. ptr

As you can see, macros can save re-creating standard patterns
of code and, when used properly, can actually contribute to
ease of understanding the source code.

Macros are also very useful in table generation, allowing
the table to be expressed in terms of its meaning instead
of its data representation.  Microcomputer macro expanders
are somewhat limited to use for this, in my experience.

Another fundamental use of macros is to contain the effects
of a decision about how something is implemented--abstraction.
In this case, the definition of the macro(s) can be changed
at any time and the program reassembled to incorporate that
change.  For example, the macro "initACIA" could be used to
abstract from exactly what was needed to init a particular
ACIA, so that the remaining code would be independent of
that choice.

Closed subroutines can be used similarly, but at the cost
of linkage instructions and possible parameter passing.
In many cases, a macro expands into a very few instructions,
so that linkage instructions would be a considerable penalty.

Many developers use macros to encapsulate the parameter
setup and calling for subroutines, so that they can easily
change parameter passing and register assignments later if
it should be useful.

Sorry for getting a bit carried away, but for many years
I saw clever macros as the solution to many problems.  ;-)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

Bill Garber wrote:
> "Michael J. Mahon" <mjmahon@aol.com> wrote in message
> news:EvidncT2FKE6a5XfRVn-qQ@comcast.com...
> : John B. Matthews wrote:
> : > In article <4208428C.5C714B48@buckeye-express.com>,
> : >  "Paul R. Santa-Maria" <paulrsm@buckeye-express.com> wrote:
> : >
> : >
> : >>"Michael J. Mahon" wrote:
> : >>
> : >>>Think of "<" as "less" significant, or "smaller", and ">" as
> : >>>"greater" significance, or "larger".  Or think of "<" as the
> : >>>lower addressed (left) part of a 16-bit number and ">" as the
> : >>>higher (right) address.
> : >
> : >
> : > When using Apple, Kyan and various cross-platform assemblers that
> : > use the opposite syntax, I came to think of #< as "left side" (hi)
> : > and #> as "right side" (lo).
> :
> : Ah, but that is a "big endian" view of memory.  ;-)
> :
> : >>Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
> : >>the high byte.  I never use #<VAL or #>VAL because I own 6502
> : >>assemblers that use them in exactly the opposite way.
> : >
> : > Excellent! Looking back I see that I used this in macros.
> :
> : I have also used this in macros, since it allows taking
> : the MSByte of any expression, not just a variable.
> :
> : I have never been very concerned about the "portability"
> : of assembly code to other assemblers, since most of my
> : programs use macros and other features that tend to be
> : peculiar to each assembler.  My standardization on Merlin
> : came early and has persisted.
> 
> Let me at this point verify for my own record that a "Macro"
> is a snippet of code that performs a function that I do a lot and
> I just insert the Macro name where I want this done. Am I at
> all correct???  For example, instead of placing in a jump to a
> place where this code would be, I simply insert the macro name
> and the assembler adds that snippet of code at that location.
> This is just to rectify my own mind. Are their any other short-
> cuts that you can use to simplify your source code??   :o)
> 
> Pages in manual will suffice so I can read up on them. Please,
> bive manual name and page number with each example, if you
> would happen to know or have it handy.

Macros are generally what you describe, and their syntax and
semantics vary a lot from implementation to implementation.
(Perhaps that is because most macro generators are their author's
_first_ (and last) macro generator, providing little opportunity
for learning.  ;-)

In the late 1950's Doug McIlroy at Bell Labs added the first general
macro expander onto an assembler for the IBM 709.  In a few years,
it developed a quite general string processing/string substitution
capability, which allowed whole computations to be done at assembly
time in the macro expander!

In the 1960's Christopher Strachey's GPM, and Calvin Mooers' and
Peter Deutsch's TRAC defined the general purpose macrogenerator
as a string-oriented computational model.

In the microprocessor era, many of the lessons of the mainframe era
had to be learned all over again, and macro expanders are no exception.
Most microprocessor macro expanders are quite limited in what they can
do, but all can "regurgitate" a macro definition in-line, and most can
substitute actual arguments supplied with the call for formal arguments
used in the definition.  The real power of macros comes with the
inclusion of conditionals, and operations to dissect and concatenate
strings, as well as define new macros as a side effect of an expansion.

Merlin Pro (8) is a relatively limited macro assembler, with limited
substitution and conditional operations, and no capability to define
or redefine macros during expansion (so it is hard to "remember" things
from one expansion to the next, unless it is a numeric value).

Merlin, curiously, also cannot define a label inside a macro, which
makes it hard to create a DO/UNTIL kind of macro set.

Nevertheless, Merlin's macros are a handy way to codify some useful
snippets of assembly code.  They are documented in the on-line manual
in chapter 7, and conditionals and variables at the end of chapter 6.

Some examples I find useful:

Definition:

align   mac                     ; Align modulo parameter
         ds    *-1/]1*]1+]1-*    ; ]1 is the first supplied parameter
         eom

Use:
         align 256               ; Align to next page boundary

Definition:

inc16   mac                     ; Increment 16-bit word
         inc   ]1
         do    ]1+1/$100         ; If ]1 is non-page zero
         bne   *+5               ; - No carry.
         else                    ; Else if ]1 on page zero
         bne   *+4               ; - No carry.
         fin
         inc   ]1+1              ; Propagate carry.
         eom

Use:
         inc16 count             ; Increment 16-bit count

Definition:

cmp16   mac                     ; Compare 16-bit words
         lda   ]1                ; Lo byte of first operand
         cmp   ]2                ; Lo byte of second operand
         lda   ]1+1              ; Hi byte of first operand
         sbc   ]2+1              ; Hi byte of second operand
         eom

Use:
         cmp16 end;ptr           ; Compare 'end' to 'ptr'
         bcs   :loop             ; Loop if end .ge. ptr

As you can see, macros can save re-creating standard patterns
of code and, when used properly, can actually contribute to
ease of understanding the source code.

Macros are also very useful in table generation, allowing
the table to be expressed in terms of its meaning instead
of its data representation.  Microcomputer macro expanders
are somewhat limited to use for this, in my experience.

Another fundamental use of macros is to contain the effects
of a decision about how something is implemented--abstraction.
In this case, the definition of the macro(s) can be changed
at any time and the program reassembled to incorporate that
change.  For example, the macro "initACIA" could be used to
abstract from exactly what was needed to init a particular
ACIA, so that the remaining code would be independent of
that choice.

Closed subroutines can be used similarly, but at the cost
of linkage instructions and possible parameter passing.
In many cases, a macro expands into a very few instructions,
so that linkage instructions would be a considerable penalty.

Many developers use macros to encapsulate the parameter
setup and calling for subroutines, so that they can easily
change parameter passing and register assignments later if
it should be useful.

Sorry for getting a bit carried away, but for many years
I saw clever macros as the solution to many problems.  ;-)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
news:wsGdnQipCM3byZTfRVn-jA@comcast.com...
: Bill Garber wrote:
: > "Michael J. Mahon" <mjmahon@aol.com> wrote in message
: > news:EvidncT2FKE6a5XfRVn-qQ@comcast.com...
: > : John B. Matthews wrote:
: > : > In article <4208428C.5C714B48@buckeye-express.com>,
: > : >  "Paul R. Santa-Maria" <paulrsm@buckeye-express.com> wrote:
: > : >
: > : >
: > : >>"Michael J. Mahon" wrote:
: > : >>
: > : >>>Think of "<" as "less" significant, or "smaller", and ">" as
: > : >>>"greater" significance, or "larger".  Or think of "<" as the
: > : >>>lower addressed (left) part of a 16-bit number and ">" as the
: > : >>>higher (right) address.
: > : >
: > : >
: > : > When using Apple, Kyan and various cross-platform assemblers that
: > : > use the opposite syntax, I came to think of #< as "left side" (hi)
: > : > and #> as "right side" (lo).
: > :
: > : Ah, but that is a "big endian" view of memory.  ;-)
: > :
: > : >>Or, do what I do.  #VAL gives the low byte, and #VAL/256 gives
: > : >>the high byte.  I never use #<VAL or #>VAL because I own 6502
: > : >>assemblers that use them in exactly the opposite way.
: > : >
: > : > Excellent! Looking back I see that I used this in macros.
: > :
: > : I have also used this in macros, since it allows taking
: > : the MSByte of any expression, not just a variable.
: > :
: > : I have never been very concerned about the "portability"
: > : of assembly code to other assemblers, since most of my
: > : programs use macros and other features that tend to be
: > : peculiar to each assembler.  My standardization on Merlin
: > : came early and has persisted.
: >
: > Let me at this point verify for my own record that a "Macro"
: > is a snippet of code that performs a function that I do a lot and
: > I just insert the Macro name where I want this done. Am I at
: > all correct???  For example, instead of placing in a jump to a
: > place where this code would be, I simply insert the macro name
: > and the assembler adds that snippet of code at that location.
: > This is just to rectify my own mind. Are their any other short-
: > cuts that you can use to simplify your source code??   :o)
: >
: > Pages in manual will suffice so I can read up on them. Please,
: > bive manual name and page number with each example, if you
: > would happen to know or have it handy.
:
: Macros are generally what you describe, and their syntax and
: semantics vary a lot from implementation to implementation.
: (Perhaps that is because most macro generators are their author's
: _first_ (and last) macro generator, providing little opportunity
: for learning.  ;-)
:
: In the late 1950's Doug MIlroy at Bell Labs added the first general
: macro expander onto an assembler for the IBM 709.  In a few years,
: it developed a quite general string processing/string substitution
: capability, which allowed whole computations to be done at assembly
: time in the macro expander!
:
: In the 1960's Christopher Strachey's GPM, and Calvin Mooers' and
: Peter Deutsch's TRAC defined the general purpose macrogenerator
: as a string-oriented computational model.
:
: In the microprocessor era, many of the lessons of the mainframe era
: had to be learned all over again, and macro expanders are no exception.
: Most microprocessor macro expanders are quite limited in what they can
: do, but all can "regurgitate" a macro definition in-line, and most can
: substitute actual arguments supplied with the call for formal arguments
: used in the definition.  The real power of macros comes with the
: inclusion of conditionals, and operations to dissect and concatenate
: strings, as well as define new macros as a side effect of an expansion.
:
: Merlin Pro (8) is a relatively limited macro assembler, with limited
: substitution and conditional operations, and no capability to define
: or redefine macros during expansion (so it is hard to "remember" things
: from one expansion to the next, unless it is a numeric value).
:
: Merlin, curiously, also cannot define a label inside a macro, which
: makes it hard to create a DO/UNTIL kind of macro set.
:
: Nevertheless, Merlin's macros are a handy way to codify some useful
: snippets of assembly code.  They are documented in the on-line manual
: in chapter 7, and conditionals and variables at the end of chapter 6.
:
: Some examples I find useful:
:
: Definition:
:
: align   mac                     ; Align modulo parameter
:          ds    *-1/]1*]1+]1-*    ; ]1 is the first supplied parameter
:          eom
:
: Use:
:          align 256               ; Align to next page boundary
:
: Definition:
:
: inc16   mac                     ; Increment 16-bit word
:          inc   ]1
:          do    ]1+1/$100         ; If ]1 is non-page zero
:          bne   *+5               ; - No carry.
:          else                    ; Else if ]1 on page zero
:          bne   *+4               ; - No carry.
:          fin
:          inc   ]1+1              ; Propagate carry.
:          eom
:
: Use:
:          inc16 count             ; Increment 16-bit count
:
: Definition:
:
: cmp16   mac                     ; Compare 16-bit words
:          lda   ]1                ; Lo byte of first operand
:          cmp   ]2                ; Lo byte of second operand
:          lda   ]1+1              ; Hi byte of first operand
:          sbc   ]2+1              ; Hi byte of second operand
:          eom
:
: Use:
:          cmp16 end;ptr           ; Compare 'end' to 'ptr'
:          bcs   :loop             ; Loop if end .ge. ptr
:
: As you can see, macros can save re-creating standard patterns
: of code and, when used properly, can actually contribute to
: ease of understanding the source code.
:
: Macros are also very useful in table generation, allowing
: the table to be expressed in terms of its meaning instead
: of its data representation.  Microcomputer macro expanders
: are somewhat limited to use for this, in my experience.
:
: Another fundamental use of macros is to contain the effects
: of a decision about how something is implemented--abstraction.
: In this case, the definition of the macro(s) can be changed
: at any time and the program reassembled to incorporate that
: change.  For example, the macro "initACIA" could be used to
: abstract from exactly what was needed to init a particular
: ACIA, so that the remaining code would be independent of
: that choice.
:
: Closed subroutines can be used similarly, but at the cost
: of linkage instructions and possible parameter passing.
: In many cases, a macro expands into a very few instructions,
: so that linkage instructions would be a considerable penalty.
:
: Many developers use macros to encapsulate the parameter
: setup and calling for subroutines, so that they can easily
: change parameter passing and register assignments later if
: it should be useful.
:
: Sorry for getting a bit carried away, but for many years
: I saw clever macros as the solution to many problems.  ;-)

No need to be sorry, Michael. This was very interesting and
enlightening. Macros are really more than I thought they were.
You can do calculations in them. I didn't realize that. I guess
just about anything can be a macro, as long as like you were
saying, you be careful that they don't expand themselves into
oblivion, which can be done very easily, I imagine. Of course
they should be a routine in themselves so as not to pass any
variables that could lead to confusion.  I'm hoping that once
I get through studying all of these books and PDF files that
I can actually program these things. I'd really like to see
what I'm made of.  :o)

BTW, did you use a macro to post this, it expanded 3 times.
 LOL    :o)

Apple II Forever, Apple II Together
Bill @ GarberStreet Enterprizez
Web Site - http://garberstreet.netfirms.com
Email - willy46pa@comcast.net

Bill Garber wrote:

> BTW, did you use a macro to post this, it expanded 3 times.
>  LOL    :o)

You'd think so!  I cancelled it twice because I couldn't spell
McIlroy correctly.  ;-)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
news:SZKdnczKmqBr9pTfRVn-vA@comcast.com...
: Bill Garber wrote:
:
: > BTW, did you use a macro to post this, it expanded 3 times.
: >  LOL    :o)
:
: You'd think so!  I cancelled it twice because I couldn't spell
: McIlroy correctly.  ;-)

Did you this time?? I never could figure out that name.  :o)

Apple II Forever, Apple II Together
Bill @ GarberStreet Enterprizez
Web Site - http://garberstreet.netfirms.com
Email - willy46pa@comcast.net

"Michael J. Mahon" wrote:
> inc16   mac                     ; Increment 16-bit word
>          inc   ]1
>          do    ]1+1/$100         ; If ]1 is non-page zero
>          bne   *+5               ; - No carry.
>          else                    ; Else if ]1 on page zero
>          bne   *+4               ; - No carry.
>          fin
>          inc   ]1+1              ; Propagate carry.
>          eom

This can be simpler:

INCW MAC
     INC ]1
     BNE Z
     INC ]1+1
Z    EOM


> cmp16   mac                     ; Compare 16-bit words
>          lda   ]1                ; Lo byte of first operand
>          cmp   ]2                ; Lo byte of second operand
>          lda   ]1+1              ; Hi byte of first operand
>          sbc   ]2+1              ; Hi byte of second operand
>          eom

This one cannot handle a comparison against a constant.
My version uses a couple of helper macros that are used
in other macros as well.

LDHI MAC
     IF #=]1
     LDA ]1/256
     ELSE
     LDA ]1+1
     FIN
     EOM

SBHI MAC
     IF #=]1
     SBC ]1/256
     ELSE
     SBC ]1+1
     FIN
     EOM

CMPW MAC
     LDA ]1
     CMP ]2
     >>> LDHI,]1
     >>> SBHI,]2
     EOM

--
Paul R. Santa-Maria
Monroe, Michigan USA

Paul R. Santa-Maria wrote:
> "Michael J. Mahon" wrote:
> 
>>inc16   mac                     ; Increment 16-bit word
>>         inc   ]1
>>         do    ]1+1/$100         ; If ]1 is non-page zero
>>         bne   *+5               ; - No carry.
>>         else                    ; Else if ]1 on page zero
>>         bne   *+4               ; - No carry.
>>         fin
>>         inc   ]1+1              ; Propagate carry.
>>         eom
> 
> 
> This can be simpler:
> 
> INCW MAC
>      INC ]1
>      BNE Z
>      INC ]1+1
> Z    EOM

This is very interesting.

I have used variables as labels inside macros before, but I would
have expected the label Z to be multiply defined as soon as the
macro was called a second time.  But Merlin seems to treat it as
a variable.  Except that it cannot be referenced outside the macro!

I have been frustrated by my inability to get Merlin to define a
global label in a macro that is referenceable outside a macro, and
this, unfortunately, is no exception.

Do you know a way to accomplish this?

>>cmp16   mac                     ; Compare 16-bit words
>>         lda   ]1                ; Lo byte of first operand
>>         cmp   ]2                ; Lo byte of second operand
>>         lda   ]1+1              ; Hi byte of first operand
>>         sbc   ]2+1              ; Hi byte of second operand
>>         eom
> 
> 
> This one cannot handle a comparison against a constant.
> My version uses a couple of helper macros that are used
> in other macros as well.
> 
> LDHI MAC
>      IF #=]1
>      LDA ]1/256
>      ELSE
>      LDA ]1+1
>      FIN
>      EOM
> 
> SBHI MAC
>      IF #=]1
>      SBC ]1/256
>      ELSE
>      SBC ]1+1
>      FIN
>      EOM
> 
> CMPW MAC
>      LDA ]1
>      CMP ]2
>      >>> LDHI,]1
>      >>> SBHI,]2
>      EOM
> 

Nice generalization.

I also usually write the "]1+1" part as "1+]1" so that it can handle
indexed operands.

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

!! wow !!
A most enjoyable read.  And I was thinking a macro is just a sequence 
that helps me typo less.  (Keyboard macros in Wordperfect mostly, batch 
files frequently.)

Thankx,
Ed

Michael J. Mahon wrote:
> Macros are generally what you describe, and their syntax and
> semantics vary a lot from implementation to implementation.

How to use the Append command from Merlin
8 Prodos?

I get error 56, "memory in use"

I LOAD main file
I quit to main menu
I press A)ppend
it asks me for filename
I type in "paste" (the name of the file I want to paste into my main
assembly)
It gives me the error.

Rich

How to use the Append command from Merlin
8 Prodos?

I get error 56, "memory in use"

I LOAD main file
I quit to main menu
I press A)ppend
it asks me for filename
I type in "paste" (the name of the file I want to paste into my main
assembly)
It gives me the error.

Rich

aiiadict@gmail.com wrote:
> I LOAD main file
> I quit to main menu
> I press A)ppend
> it asks me for filename
> I type in "paste" (the name of the file I want to paste into my main
> assembly)
> It gives me the error.

That works for me with Merlin-8 version 2.58.
Perhaps both files together are too big to fit?

--
Paul R. Santa-Maria
Monroe, Michigan USA

"Michael J. Mahon" wrote:
> I have been frustrated by my inability to get Merlin to define a
> global label in a macro that is referenceable outside a macro, and
> this, unfortunately, is no exception.
> Do you know a way to accomplish this?

Do you mean this?

                1             ORG   $5678      
                2    TESTMAC  MAC              
                3             NOP              
                4    ]VAR     EQU   *          
                5             NOP              
                6             EOM              
                7    ]VAR     =     $1234      
5678: 34 12     8             DA    ]VAR       
                9             >>>   TESTMAC    
567A: EA        9             NOP              
                9    ]VAR     EQU   *          
567B: EA        9             NOP              
                9             EOM              
567C: 7B 56     10            DA    ]VAR       


> I also usually write the "]1+1" part as "1+]1"
> so that it can handle indexed operands.

Another great tip!  Thanks again.

--
Paul R. Santa-Maria
Monroe, Michigan USA

Paul R. Santa-Maria wrote:
> "Michael J. Mahon" wrote:
> 
>>I have been frustrated by my inability to get Merlin to define a
>>global label in a macro that is referenceable outside a macro, and
>>this, unfortunately, is no exception.
>>Do you know a way to accomplish this?
> 
> 
> Do you mean this?
> 
>                 1             ORG   $5678      
>                 2    TESTMAC  MAC              
>                 3             NOP              
>                 4    ]VAR     EQU   *          
>                 5             NOP              
>                 6             EOM              
>                 7    ]VAR     =     $1234      
> 5678: 34 12     8             DA    ]VAR       
>                 9             >>>   TESTMAC    
> 567A: EA        9             NOP              
>                 9    ]VAR     EQU   *          
> 567B: EA        9             NOP              
>                 9             EOM              
> 567C: 7B 56     10            DA    ]VAR       

Almost.  This is a way to pass a value from a macro
_forward_ in a program.  And I would have expected
to use a global label. (Although, from your earlier
example, clearly "global label" definitions inside
a Merlin macro expansion are treated as variables).

But what I often need is a way to pass a value from
a macro called late in a program back to an address
context earlier in the program.  Put another way, I
want the label evaluated during pass 1, and the value
used during pass 2.  I have found no way to do this
in Merlin.  Outside a macro, a simple global label
does this job perfectly.

Of course, if the value is used to determine the
length of an instruction or data area, then it would
have to be a pass 1 value.

(For example, if I planned to do an "lda x", then x
would have to be known in pass 1 when the "lda" was
encountered, since it could be a 2- or 3-byte op
depending on whether x was on page 0 or not.  But
if I instead used "ldaa x", which forces Merlin
to use the 3-byte absolute address format, then x
could be a pass 2 value (since its value is not
needed to keep an accurate location counter.)

I find it expecially frustrating, since in my simple
string substitution model of macro expansion it just
works with no extra mechanisms whatsoever.

>>I also usually write the "]1+1" part as "1+]1"
>>so that it can handle indexed operands.
> 
> 
> Another great tip!  Thanks again.

Glad you like it!  You've got me questioning my admittedly
fragmentary model of Merlin's macro scheme.  ;-)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

Paul R. Santa-Maria wrote:
> aiiadict@gmail.com wrote:
> 
>>I LOAD main file
>>I quit to main menu
>>I press A)ppend
>>it asks me for filename
>>I type in "paste" (the name of the file I want to paste into my main
>>assembly)
>>It gives me the error.
> 
> 
> That works for me with Merlin-8 version 2.58.
> Perhaps both files together are too big to fit?

Bingo.

When constructing larger assembly programs, it is a good idea
to break them up into logical pieces which you then "put" into
the assembly.  My pragmatic rule is that if a chunk of code is
too big for Merlin-8, then it's too big a chunk.

Merlin provides several tools for easing the creation of large
programs, including assembling to disk.

I generally use a top-level program that has only global
declarations, of constants (including conditional assembly
constants), macros, and data areas.  This top-level module
sets the origin for the code, then "put"s each of the component
modules, followed by any "end code" that may be required.

This causes one to consider a higher-level modularity than a
subroutine (objects, anyone ;-), and provides plenty of "room"
for editing.  You can almost consider the top-level module to be
a kind of "make" file for the program, particularly if you have
several versions of the program that are closely related, but
different.

In this case, there is one top-level module for each program,
with most (or all) of the constituent modules shared between
them.  The use of conditional assembly can greatly facilitate
this approach.

Examples of my use of Merlin are on the website in my .sig.
For example, the listing of NADA.PRODOS, the ProDOS version
of NadaNet, has line numbers that start over from "1" and
grow a ">" several times during the listing.  This is Merlin's
way of numbering a file that is "put" into an assembly.  You
can see just how the assembly is structured by reading the "put"
lines just prior to a line number restart.  Of course, the line
numbers correspond to the lines within each included file.

NadaNet has versions for ProDOS, DOS 3.3, OS-less machines like
the AppleCrate, a Message Server Crate version, and a Crate Boot
ROM version.  All versions are constructed from the same code
modules, with selective "put"s and conditional assembly used to
omit unnecessary functions to save memory.  Each version also
has a different origin, to fit a particular OS environment.
The listings of the ProDOS version, the Crate version, and the
Boot ROM version are on my site.  (And I'd be happy to provide
more info to anyone who is interested.)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

Hi  Michael,

I looked at your NADA.CRATE source on your webpage.

Very nice looking compared to my code :-)

can you post how to "put" the following few dummy
files together?

Thanks for any help,
Rich

File 1
*******************************
main
org $800
nop
nop
nop
jsr sub1
jsr sub2
jsr sub3
rts
EOF


File 2
*******************************
sub1
ORG ?????
nop
nop
nop
RTS
EOF

File 3
*******************************
sub2
ORG ?????
nop
nop
nop
RTS
EOF

File 4
*******************************
sub3
ORG ?????
nop
nop
nop
RTS
EOF

aiiadict@gmail.com wrote:
> Hi  Michael,
> 
> I looked at your NADA.CRATE source on your webpage.
> 
> Very nice looking compared to my code :-)
> 
> can you post how to "put" the following few dummy
> files together?
> 
> Thanks for any help,
> Rich

For a scheme like this, the following would do.

> File 1
> *******************************
> main
> org $800
> nop
> nop
> nop
> jsr sub1
> jsr sub2
> jsr sub3
> rts
   put file2
   put file3
   put file4
> EOF
> 
> 
> File 2
> *******************************
> sub1
> ORG ?????
> nop
> nop
> nop
> RTS
> EOF
> 
> File 3
> *******************************
> sub2
> ORG ?????
> nop
> nop
> nop
> RTS
> EOF
> 
> File 4
> *******************************
> sub3
> ORG ?????
> nop
> nop
> nop
> RTS
> EOF

Then you would only assemble File 1, and all the other
code would be brought in automatically.  Typically, you
would not want ORGs in the included files (unless required
for some other reason).

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

Thanks a bunch!

I cut the assembly into its individual routines,
PUT them in the main file, and the main file
contains equates, tables, and JSR's to the
main function of the program.

I can understand my own code again!

I introduced a few errors into the assembly
when I did this.  I would load  MAIN, ASM it,
and it would spit out "bad opcode in line 19 > 174"

Is there an easy way to tell WHICH file this error
came from?  I commented out PUTS one by one
until I found the culprit file.  It had an RT instead
of RTS.

It is nice having my code broken into logical
chunks instead of one huge document.  It seems
to have made reading error messages (line numbers/filenames)
harder.

Rich

aiiadict@gmail.com wrote:
> Thanks a bunch!
> 
> I cut the assembly into its individual routines,
> PUT them in the main file, and the main file
> contains equates, tables, and JSR's to the
> main function of the program.
> 
> I can understand my own code again!

Great--I'm glad you like it!

Keeping the main program source small allows the
maximum amount of space during assembly for each
of the included modules.  You will also notice
that macros must be in either the main file or
in files that are included with the USE statement
instead of the PUT statement.  (The main and USEd
files stay in memory throughout the assembly.)

> I introduced a few errors into the assembly
> when I did this.  I would load  MAIN, ASM it,
> and it would spit out "bad opcode in line 19 > 174"
> 
> Is there an easy way to tell WHICH file this error
> came from?  I commented out PUTS one by one
> until I found the culprit file.  It had an RT instead
> of RTS.

The error is on line 174 of the file included by the
PUT on main program line 19.

This is pretty obvious if you are getting a listing
(or watching it go by on the screen).

> It is nice having my code broken into logical
> chunks instead of one huge document.  It seems
> to have made reading error messages (line numbers/filenames)
> harder.

It gets pretty easy after you get used to the nn>mm
error notation.  And in practice, most errors you will
encounter are in the module you just made changes to.  ;-)

-michael

New Applesoft BASIC interface for NadaNet networking!
Home page:  http://members.aol.com/MJMahon/

Thanks, I should have been able
to figure that one out!

I haven't used Macros yet.  I'll
have to read more about them.

Rich

Michael wrote:

>The error is on line 174 of the file included by the
>PUT on main program line 19.