Date: Thursday, 4 June 1987  21:17-MDT
From: Mark Dapoz
To:   info-cpm
Re:   zcpr3.3

I just finished getting zcpr3.3 to assemble with M80 version 3.44 
(dated Dec 9, 1981).  The following is a summary of the changes that 
are needed to get the CCP portion to assemble (I still haven't recieved 
the RCP & FCP portions so I don't know what changes need to be made to 
those files).

1. In all files the square brackets "[" & "]" need to be changed to "(" 
   & ")" respectively on all conditional assembly statements (ie if's).  
   DON'T do a global change with a text editor since some square 
   brackets don't need to be changed!

in the file ZCPR33.Z80:

2. The maclib command must be converted to upper case along with it's 
   arguments

3. The commands .Z80 and ASEG should be added.

in the file Z33HDR.LIB:

4. The extmpath, extmpathadr and whldir equate statements should have 
   the EQU changed to a DEFL (this should be changed anyways, I think).

in the file Z33MAC.LIB

5. M80 can only handle 6 chars for a macro argument (even in version 
   3.44) so the 'command' macro needs to be changed.  Following is an 
   updated version:

; Command table entry definition macro

; Macro to form an entry for one command in the table.  The first parameter is
; the name to be used for the command (no quotes); the second parameter is the
; flag that indicates whether or not the command is to be enabled; the third
; parameter is the wheel control flag; and the last parameter is the jump
; address to the code that carries out the command.  The command names are
; automatically padded out to the correct length (they will be truncated and
; an error message will result if a command name is too long).  The characters
; in the command name are automatically converted to upper case.

command macro cmdnam,enaflg,whlflg,addr

         if     enaflg          ;; Generate command only if enabled

whlmask defl    whlflg          ;; Initialize variables
count   defl    cmdsize         ;; Initialize to size of each command name

        irpc    char,cmdnam     ;; Repeat over letters in command name

count   defl    count - 1       ;; Count down characters in name

         if     ( count lt cmdsize )

                ;; If character is lower case, convert to upper case

         if     ( '&char' ge 'a' ) and ( '&char' le 'z' )

         if     whlmask
        defb    ( '&char' and 5fh ) + 80h
         else   ;;not whlmask
        defb    ( '&char' and 5fh )
         endif  ;;whlmask

         else   ;;not lower case

         if     whlmask
        defb    '&char' + 80h   ;; If controlled by wheel, set high bit
         else   ;;not whlmask
        defb    '&char'         ;; If not restricted, leave high bit clear
         endif  ;;whlmask

         endif  ;;lower case

         endif  ;;( count lt cmdsize )

whlmask defl    false           ;; Turn off high-bit setting after first char

        endm    ;irpc

                ;; Pad command name with blanks

         if     ( count gt cmdsize )    ;; If we underflowed
        *** Command name "&cmdname" is too long / truncated ***
         else
        rept    count
        defb    ' '
        endm
         endif  ;( count gt cmdsize )

        dw      addr            ;; Dispatch address for command

         endif  ;enable

        endm    ;command


After successful assembly, the resultant .REL file was converted to a 
HEX file using RELHEX.COM and then merged with the BIOS in the standard 
manner.  Even though M80 only outputs 6 char labels in the REL file, it 
still keeps larger labels during assembly, so the use of large labels 
in zcpr3.3 doesn't affect M80 in the least.  Hope this helps in getting 
people stared with assembling zcpr3.3 with M80.

A side note: zcpr3.3 came up the first time I tried booting it!  It did 
take me 2 hours to figure out all the changes that needed to be made to 
the source files for M80, but after that first successful assemble, it 
booted with no problems.
 
Regarding zcpr 4.0, I'd love to hear what you're doing with it Richard, 
how about posting a summary of what's going on with it, either that, or 
send it directly to me.

        -Mark

"If a hardware problem causes system software to crash, the customer 
engineer will blame the system programmer."

            Mark Dapoz
         mdapoz@watdragon.UUCP