Installing CP/M 3 (Plus?) on a home-built Z80 computer

[nockieboy]

I understand the frustration, this sort of thing is not really easy - despite what the instructions might imply. And to do this while learning (about Z80 ASM and CP/M) is even harder. If I had a virtual machine to match your hardware, I could probably be of more help. I'm strapped for spare time right now, though.

another area to pay attention to, when creating the BIOS3 code, is the DPH and associated structures. There are some subtle differences and new structures which need to be carefully handled.

I'l try to find some time this weekend to take a closer look at your BIOS code and see if I can help by inspection. If you've got something to document your hardware, that might be nice. either "programmer notes" or a schematic.

You sir are a star. :D

I don't have a single schematic for the design - the schematics are quite modular. However, here's a summary of features that should help:

The SBC has a flexible MMU, which splits the Z80's 64KB memory space into 4 16KB 'Areas', each able to be independently mapped to any 16KB Bank in the 256K available physical memory (128KB SRAM in lower half, 128KB EEPROM in upper half.) With the addition of a CompactFlash card, the SBC has permanent storage allowing it to run CP/M 2.2. It uses an ATmega328 microcontroller to enhance its IO potential:

• Z80 microprocessor at 2, 4 or 8 MHz clockspeed, software-selectable
• 128K SRAM (00000h-1FFFFh)
• 128K ROM (20000h-3FFFFh)
• MMU provides access to 256KB physical memory in 16x16KB Banks, mappable to the Z80 in any arrangement as 4x16KB Areas
• Z80 SIO/2 providing two serial interfaces, with interrupt-driven Rx channels to prevent unnecessary polling of the Rx buffer when not in use
• CompactFlash adapter with 64MB CF card providing 8x 8MB drives for file storage
• OS - Custom ROM monitor providing NASCOM BASIC, memory and Intel HEX file input utilities & CP/M 2.2
• I2C bus via Support Module - currently supports Real Time Clock module
• Fully-expandable interrupt system
• Z80 CTC for clock/timer functions and user-programmable triggerable interrupts
• Z80 PIO for 2-channel parallel IO

Memory & IO Map:

Power-up Memory Map:

• Area 0 - 0000-3FFF ROM (Bank 0F - DMI monitor)
• Area 1 - 4000-7FFF RAM (Bank 01)
• Area 2 - 8000-BFFF RAM (Bank 02)
• Area 3 - C000-FFFF RAM (Bank 03)

As the MMU allows full configuration of the memory space, this memory map is only applicable at first power-on. i.e. the RAMMODE command copies the DMI from Bank 0F to Bank 00, then maps Area 00 to Bank 00.

Memory Map in CP/M mode:

• Area 0 - Bank 0 (SRAM)
• Area 1 - Bank 1 (SRAM)
• Area 2 - Bank 2 (SRAM)
• Area 3 - Bank 3 (SRAM)

Breakdown of the CP/M memory map:

• 0000-0100 Scratch storage & interrupt vectors
• 0100-D800 TPA
• D800-E5FF CP/M
• E600-FFFF BIOS

I/O Map

• 00-07 SIO/2 dual-port serial interface
• 08-0F Reserved for PSG
• 10-17 CompactFlash interface
• 18-1F CTC 4-channel programmable clock/timer
• 20-27 PIO 2-channel parallel I/O
• 28-2F Unused
• 30-37 Unused
• 38-3F Memory Management Unit

The CompactFlash storage and format is identical to Grant Searle's design here and uses the same routines to read/write. In fact the SBC is based loosely on Grant's design, with some modifications to the IO mapping and RAM/ROM select (in my SBC it's managed via the MMU.)

The MMU is controlled via an

OUT ($38),n

command, where n is a control byte made up of the following:

• B7 - low = MMU active, high = MMU inactive
• B6 - not used
• B5, B4 = Area select
• B3-B0 = Bank select

So

OUT ($38),02

would map Bank 02 (SRAM 8000-BFFFh) to Area 0 (0000-3FFFh).

Also, I've attached the current CBIOS for CP/M 2.2 - this works with my SBC to allow CP/M 2.2 to run without problems.

Attachment: View attachment cbios64.zip

 

[durgadas311]

I did some looking around. I see that you are using Z80 vectored interrupts, but it appears the only interrupts are for serial input. I don't know if one of your serial channels is automated in any way (i.e. input may occur spontaneously at any time - like during the loader execution). To be safe, I would suggest that your loader BIOS either keep interrupts disabled or re-initialize the Z80 and SIO vector pieces for valid routines within your loader BIOS.

Another thing I noticed is that the loader BDOS expects your loader BIOS to work in CP/M 3 version structures. This means the DPH and the DPB need to be compatible with CP/M 3. This also means you could let the loader BDOS handle deblocking, if you wanted, by initializing (to non-zero) the physical sector bytes at the end of the DPB. The loader BDOS does not do any bank-switching, but it does depend on a "move" entry point to the BIOS, which is a simple (DE)-to-(HL)x(BC) move routine. The only BIOS routines that seem to be needed are COLD BOOT, CONOUT, disk setup and read, and MOVE. The loader BDOS also expects the DIRBCB and DTABCB buffer control bock chains to be valid. So, the loader BIOS is not really CP/M 2.2 nor is it a full-featured CP/M 3 BIOS.

Looking at the latest LDRBIOS.ASM that I have, I would do the following:

1) Remove all EXTRNs, and any code that uses those symbols.
2) Change all "unused" BIOS entries into a trap for debugging. since you already have routines to print a HEX address, you could change all the unused JP entries into "CALL TRAP" and have the TRAP routine pop the address and print it in an error message and then die (DI; HLT) - so you know what's being called.
3) Remove all code no longer used after (2).
4) Make (cold) BOOT do *at least* a DI (and make sure nothing enables interrupts). The loader won't use console input, but if you have other uses for that special channel then you'll need to handle it. You can either do polled input or re-initialize the interrupt vector to something inside the loader BIOS. Also, do not change the stack pointer - keep the loader's stack. Be sure to return from BOOT, do not try to "start CP/M" yourself.
5) Do not use DSEG - keep all code/data in CSEG.
6) Do not rely on the CP/M 2.2 BIOS for anything. The BDOS, including loader BDOS, remembers the BIOS structures and uses them, which won't work while the loader is overwriting the CP/M 2.2 BIOS with CP/M 3. Let alone you won't be able to call into the 2.2 BIOS.

Here's a picture that may help:


While the loader is running, it is overwriting the area used by the 2.2 BIOS with the CP/M 3 resident BIOS/BDOS. This means that any attempts to access code or data in the 2.2 BIOS area will result in a crash (either jumping to invalid code or using corrupted data). This is why the loader BIOS must be stand-alone. But since you don't need any of the write and deblocking code, or any of the extra I/O, it should be simple and small.

Does this make sense?

 

[nockieboy]

Does this make sense?

Right now, having just skim-read your post, no it doesn't really. But that's no surprise as I'm so new to CP/M and assembly that it'll probably take me a few days of reviewing what you've written and breaking it down before I get a grasp of it all. I'm hoping to get some time tomorrow or perhaps during the week to review what you've written and develop a plan of action. I'll be back with questions, no doubt!

Thanks so much for taking the time to look at it, durgadas - your help is much appreciated!!

 

[durgadas311]

Here's what I think the LDRBIOs needs to be, with minimal "gratuitous" changes. CPMLDR.ASM supports BDOS deblocking, but this BIOS still does that and tells the BDOS the physical sector size is 128. It also does not fully implement the DIR/DTA BCBs since only DIRBCB is used in this case. I also am not sure how much of the serial I/O code can go away.

View attachment ldrbios.asm.txt

Also, since I don't use Z80 mnemonics, I can't be sure the changes are 100% correct, but I'm sure your assembler will tell you. Of course, I can't be certain this will work, either. Take a look and review it, let me know if you have questions.

This LDRBIOS is derived from you CP/M 2.2 BIOS "cbios64.asm". I added extra entry points and traps for unused ones. It prints enough messages that you should be able to tell how far it gets. If the CP/M LOADER message get printed, that means that the LDRBIOS cold boot completed. If you enabled the memory map printing in GENCPM, that message gets printed after opening CPM3.SYS and reading the first few records. And of course if your CP/M 3 BIOS prints a sign-on message, that indicates you made it to the CP/M 3 cold boot routine. From there, it is debugging your CP/M BIOS.

 

[nockieboy]

Here's what I think the LDRBIOs needs to be, with minimal "gratuitous" changes.

Sorry durgadas, I got sidetracked by another mini-project (I've implemented in-circuit programming of the ROM to save me swapping the ROM out every time I want to update the monitor). I've put off working on the CP/M 3 upgrade as much as I can now, so I started looking at CP/M earlier this evening, so your post couldn't have come at a better time! Thank you so much for your help!

CPMLDR.ASM supports BDOS deblocking, but this BIOS still does that and tells the BDOS the physical sector size is 128. It also does not fully implement the DIR/DTA BCBs since only DIRBCB is used in this case. I also am not sure how much of the serial I/O code can go away.

Ah yes, don't worry about the serial I/O code - I know exactly what it's for and can just DIsable interrupts for CPMLDR. The serial I/O interrupt tells the system that a character is waiting to be read in the port A or port B buffers (i.e. the user has tapped a key in the terminal or a data stream is waiting in the B buffer from the ATmega368 support module).

Not sure what you mean by the DIRBCB/DTABCB comments - I will go away and read up on this next.

Also, since I don't use Z80 mnemonics, I can't be sure the changes are 100% correct, but I'm sure your assembler will tell you. Of course, I can't be certain this will work, either. Take a look and review it, let me know if you have questions.

Absolutely - will do! :D

This LDRBIOS is derived from you CP/M 2.2 BIOS "cbios64.asm". I added extra entry points and traps for unused ones. It prints enough messages that you should be able to tell how far it gets. If the CP/M LOADER message get printed, that means that the LDRBIOS cold boot completed. If you enabled the memory map printing in GENCPM, that message gets printed after opening CPM3.SYS and reading the first few records. And of course if your CP/M 3 BIOS prints a sign-on message, that indicates you made it to the CP/M 3 cold boot routine. From there, it is debugging your CP/M BIOS.

So... just to be clear (it's been a long day and I'm going to bed!)... To test out our new BIOS I need to compile LDRBIOS.ASM into LDRBIOS.REL using RMAC? Then use LINK to link CPMLDR.REL (supplied with the CP/M source files) with LDRBIOS.REL to create CPMLDR.COM?

 

[durgadas311]

Based on the CPMLDR.ASM I have, assuming it is what produced CPMLDR.REL, you should do this:

RMAC LDRBIOS.ASM
LINK CPMLDR=CPMLDR,LDRBIOS[OC,NR]

although, does RMAC support Z80 mnemonics? Back in the old days, we just stuck with Intel + Z80.LIB so I never tried anything else.

The DIRBCB/DTABCB are just constructs created for CP/M 3 to handle disk buffers. It's a structure (BCB = Buffer Control Block) that allows several buffers to be managed by the BDOS, basically in a least-recently-used manner. One set used for directory, the other for data.

 

[nockieboy]

Based on the CPMLDR.ASM I have, assuming it is what produced CPMLDR.REL, you should do this:

RMAC LDRBIOS.ASM
LINK CPMLDR=CPMLDR,LDRBIOS[OC,NR]

although, does RMAC support Z80 mnemonics? Back in the old days, we just stuck with Intel + Z80.LIB so I never tried anything else.

I think it does... well, I got this when I tried RMAC just now:

026C
00DH USE FACTOR
END OF ASSEMBLY

That appeared at the end of a (very) long console output of the PRN file, I'm guessing. Couldn't see any errors with my untrained eye..

The next line - LINK CPMLDR=... etc - produces this response:

A>LINK CPMLDR=CPMLDR,LDRBIOS[OC,NR]
LINK 1.31

ABSOLUTE     0000
CODE SIZE    0C6C (0100-0D6B)
DATA SIZE    0000
COMMON SIZE  0000
USE FACTOR     27

A>

So it appears to have compiled okay. Running CPMLDR seems to do nothing though?

A>cpmldr

A>sysinfo
Processor:   Z80
System:      CP/M 2.2
Top of TPA:  D800
BIOS start:  E600

It just returns to the console - a subsequent SYSINFO shows that 2.2 is still running, seemingly with no ill-effects and no trap error messages etc from CPMLDR. Am I missing something painfully obvious? :sleepy: I was hoping that it would at least attempt to load the CPM3.SYS file and (most likely) crash as I haven't compiled CP/M 3 with the new BIOS?

 

[durgadas311]

Hmmm, do you have a special, modern, version of RMAC? I tried just now on a virtual CP/M machine with RMAC 1.1 and it chokes on nearly every line. I'm guess that the RMAC result you got, 026C, is too small for the BIOS as well, indicating something went wrong. My failed attempt returned 0278 so something must be different between our two setups. The PRN file showed the first successfully assembled code was the "JP BOOT" and the "CALL TRAP". Intel mnemonics interpret "JP" as "Jump if Plus" and you follow that with a CALL TRAP with "trap" undefined (due to invalid op code at that routine) and you have a chance (depending on the CPU flags when CCP executes the loader) that the "JP BOOT" will fall-through to the "CALL TRAP" ("CALL 0000H") which simply returns to the native CP/M immediately. There are also many other opportunities to jump/call 0000H in this mangled code stream.

But, what have you been using to assemble your Z80 code up to now? Does that tool produce REL files?

I'd be interested to see your PRN file and look at what code it actually produced. Strange that it did not spew a ton of errors.

 

[nockieboy]

Hmmm, do you have a special, modern, version of RMAC?

Hmm.. not that I know of. I can't remember where I got it from as it wasn't in the original CP/M 2.2 file archive that I had. I suspect it was from a CP/M 3 archive or something...

I tried just now on a virtual CP/M machine with RMAC 1.1 and it chokes on nearly every line. I'm guess that the RMAC result you got, 026C, is too small for the BIOS as well, indicating something went wrong. My failed attempt returned 0278 so something must be different between our two setups. The PRN file showed the first successfully assembled code was the "JP BOOT" and the "CALL TRAP". Intel mnemonics interpret "JP" as "Jump if Plus" and you follow that with a CALL TRAP with "trap" undefined (due to invalid op code at that routine) and you have a chance (depending on the CPU flags when CCP executes the loader) that the "JP BOOT" will fall-through to the "CALL TRAP" ("CALL 0000H") which simply returns to the native CP/M immediately. There are also many other opportunities to jump/call 0000H in this mangled code stream.

But, what have you been using to assemble your Z80 code up to now? Does that tool produce REL files?

I've been using TASM, through the DOSBox emulator (and I suspect it is TASM 3.1, from here) - I don't do any code editing in CP/M as I don't have anything other than ED in CP/M 2.2 (which is a royal pain in the arse). I don't think I can use Wordstar or anything like that as I'm accessing the SBC through a terminal (PuTTY) rather than a CRT, so I don't have any graphics or cursor-positioning commands other than the extreme basics.

EDIT: And no, it doesn't produce .REL files as far as I can tell. :/

I'd be interested to see your PRN file and look at what code it actually produced. Strange that it did not spew a ton of errors.

I'll see if I can get it copied via the terminal and post here shortly.

 

[nockieboy]

Okay, here's the LDRBIOS.PRN file:

View attachment LDRBIOS.zip

Here's RMAC:

A>RMAC
CP/M RMAC ASSEM 1.1
A:.ASM-NO SOURCE FILE PRESENT

 

[durgadas311]

Looks like you got pretty much the same errors I got. The first character in a line indicates the error (blank means no error). Not sure why the code is different, although I did notice that the EOF (Ctrl-Z) was not present in the file you assembled, so that might have something to do with it.

If you must use RMAC, you will have to revert to Intel mnemonics plus Z80.LIB for Z80 instruction macros. I'm not aware of other assemblers that might be available, for example whether Microsoft's CP/M-80 assembler supports Z80.

 

[daver2]

There are loads of errors in the listing file...

Look in column 1 of the listing file and compare them with the descriptions on page 165 of http://www.cpm.z80.de/manuals/mac.pdf.

For example 'S' = syntax error. 'U' = Undefined symbol. 'L' = Label error. 'P' = Phase error. 'V' = Value error. 'E' = Expression error.

Looking at the list of errors, RMAC doesn't support the Zilog mnemonics. Didn't I find a Z80 MACRO library for you a while ago (or was it for someone else) I can't remember? Somewhere I think there is a set of Z80 library macros to enhance the assembler.

EDIT: Just got beaten there...

Dave

 

[nockieboy]

Looks like you got pretty much the same errors I got. The first character in a line indicates the error (blank means no error). Not sure why the code is different, although I did notice that the EOF (Ctrl-Z) was not present in the file you assembled, so that might have something to do with it.

If you must use RMAC, you will have to revert to Intel mnemonics plus Z80.LIB for Z80 instruction macros. I'm not aware of other assemblers that might be available, for example whether Microsoft's CP/M-80 assembler supports Z80.

Erm... well, I'm not using RMAC because I have to, just because it was the program that was mentioned in the CP/M 3 System Guide.

 

[nockieboy]

There are loads of errors in the listing file...

Look in column 1 of the listing file and compare them with the descriptions on page 165 of http://www.cpm.z80.de/manuals/mac.pdf.

For example 'S' = syntax error. 'U' = Undefined symbol. 'L' = Label error. 'P' = Phase error. 'V' = Value error. 'E' = Expression error.

Looking at the list of errors, RMAC doesn't support the Zilog mnemonics. Didn't I find a Z80 MACRO library for you a while ago (or was it for someone else) I can't remember? Somewhere I think there is a set of Z80 library macros to enhance the assembler.

EDIT: Just got beaten there...

Dave

Hi Dave! Welcome to the ongoing mayhem that is me fumbling around trying to get CP/M 3 up and running...

Ah yes, I missed that - not knowing anything about RMAC etc meant I missed that it was throwing all those errors! Definitely looks like RMAC doesn't like Z80 mnemonics. I don't recall you finding a Z80 MACRO library for me? Though my memory is particularly crap and getting worse all the time...

I'll have a hunt later for some Z80 library macros and get back to you guys.

 

[durgadas311]

RMAC only understands Intel mnemonics. You can extend it with a macro library to do the (new) Z80 instructions, but the instruction format is coerced to work with the macros. These were called "Z80 extensions to Intel mnemonics". The Zilog mnemonics require a completely different parser and thus RMAC won't be able to assemble Zilog mnemonics. The assembler directives are also different.

Also, RMAC uses different symbol rules so I think many of the labels/symbols in your code will have to change as well. This includes changes to satisfy uniqueness, since RMAC does not allow arbitrary length labels. In addition, RMAC may not support the expression syntax. Bottom line, I'd suggest that you either hunt down a Z80 assembler that can produce REL files or else take the hit and switch back to Intel mnemonics (and RMAC assembler syntax).

Here's the Z80.LIB macro library I use. It is loaded using "MACLIB Z80" in the ASM file. Note, this provides *most* of the official Z80 instructions, and possibly a couple undocumented ones, but is no way complete. I forget where we got it, but I did extend it a bit.

View attachment z80.lib.txt

 

[durgadas311]

For editing on CP/M I use Magic Wand. But it is screen-oriented and so requires a "terminal" config for the control/escape codes your terminal accepts. I have a H19 version (VT52-like) and a Kaypro one (ADM3-like). I also have the terminal module source, so you could configure it for your terminal codes. Let me know if you want to go down that rabbit hole...

 

[daver2]

>>> Hi Dave! Welcome to the ongoing mayhem that is me fumbling around trying to get CP/M 3 up and running...

Thanks. I have been reading your thread - but just too busy to respond. Never mind, I have broken up for Christmas now - but my wife may have a few things to say about 'relocating computers for the christmas festivities'...

Z80.LIB is mentioned at http://www.s100computers.com/Software Folder/Assembler Collection/Assembler Collection.htm but (as duragas311 has already stated) be prepared for the long haul... You may be 'better' served by trying to assemble and link externally to CP/M as you currently do - but you will have to find a relocating assembler/linker to link together the supplied CP/M relocatable object file(s) with yours...

I assume the following to be true...

CPMLDR.ASM produces CPMLDR.REL

LDRBIOS.ASM produces LDRBIOS.REL

CPMLDR.REL when combined with LDRBIOS.REL produces CPMLDR.COM

I assume CPMLDR.ASM is a Digital Research supplied file - therefore this will be written using INTEL mnemonics. [EDIT: Just checked the CP/M V3 sources and this is correct - although CPMLDR.REL seemed to be supplied by Digital research in the distribution; with CPMLDR.ASM being supplied with the source].

LDRBIOS.ASM is your own creation, therefore uses Zilog mnemonics.

If this is true, you either have to assemble CPMLDR.ASM under CP/M (RMAC) to produce CPMLDR.REL and copy that to your development machine where you would assembler your LDRBIOS.ASM to produce LDRBIOS.REL and link with CPMLDR.REL to produce CPMLDR.COM or assemble your LDRBIOS.ASM on your development machine to produce LDRBIOS.REL and copy that to CP/M and use CP/Ms linker to produce CPMLDR.COM.

The bottom line is you will need both an Intel and Zilog mnemonic assembler to produce the .REL files and a separate linker to combine them and produce a .COM file.

I would suggest drawing out the development process, identifying the input and output files, the tools (assembler, linker etc) to convert the files and the machines upon which the tools execute (this will identify the file copying necessary between machines).

I hope this makes sense?

Dave

 

[nockieboy]

For editing on CP/M I use Magic Wand. But it is screen-oriented and so requires a "terminal" config for the control/escape codes your terminal accepts. I have a H19 version (VT52-like) and a Kaypro one (ADM3-like). I also have the terminal module source, so you could configure it for your terminal codes. Let me know if you want to go down that rabbit hole...

I probably will later, but I've had a real problem focusing on getting CP/M 3 running and another distraction wouldn't do me any good at the moment. :D Thanks for the Z80.lib macro library - I suspect it will come in handy!

Never mind, I have broken up for Christmas now - but my wife may have a few things to say about 'relocating computers for the christmas festivities'...

Yeah, I know the feeling, mine keeps making random nagging noises about similar things - I've still got another week to go, workwise. :shock:

Z80.LIB is mentioned at http://www.s100computers.com/Software Folder/Assembler Collection/Assembler Collection.htm but (as duragas311 has already stated) be prepared for the long haul... You may be 'better' served by trying to assemble and link externally to CP/M as you currently do - but you will have to find a relocating assembler/linker to link together the supplied CP/M relocatable object file(s) with yours...

Am I right in thinking that so long as I can get an assembler to produce the .REL files, I can just link them in CP/M 2.2 using LINK?

I assume the following to be true...

CPMLDR.ASM produces CPMLDR.REL

LDRBIOS.ASM produces LDRBIOS.REL

CPMLDR.REL when combined with LDRBIOS.REL produces CPMLDR.COM

Well, I've been using the CPMLDR.REL file supplied with the CP/M distribution files, but yes, your assumptions are correct.

I assume CPMLDR.ASM is a Digital Research supplied file - therefore this will be written using INTEL mnemonics. [EDIT: Just checked the CP/M V3 sources and this is correct - although CPMLDR.REL seemed to be supplied by Digital research in the distribution; with CPMLDR.ASM being supplied with the source].

LDRBIOS.ASM is your own creation, therefore uses Zilog mnemonics.

Yup. Spot on. I've been using TASM from the very beginning so I'm familiar with its directives and general format and it's been the primary method by which I've learned assembly so far, hence the attachment to Z80 mnemonics. :D

If this is true, you either have to assemble CPMLDR.ASM under CP/M (RMAC) to produce CPMLDR.REL and copy that to your development machine where you would assembler your LDRBIOS.ASM to produce LDRBIOS.REL and link with CPMLDR.REL to produce CPMLDR.COM or assemble your LDRBIOS.ASM on your development machine to produce LDRBIOS.REL and copy that to CP/M and use CP/Ms linker to produce CPMLDR.COM.

The bottom line is you will need both an Intel and Zilog mnemonic assembler to produce the .REL files and a separate linker to combine them and produce a .COM file.

Yeah. Exactly what I was thinking. :shock: I think I need to draw a diagram. Where's my crayons...

I would suggest drawing out the development process, identifying the input and output files, the tools (assembler, linker etc) to convert the files and the machines upon which the tools execute (this will identify the file copying necessary between machines).

Great minds and all that. :D

I hope this makes sense?

Yes, absolutely. I'll head off and have a hunt around for some relocatable assemblers. It does seem that Linux has more options than Windows in this respect, so I might set up an Ubuntu VM as a dev environment, but if I don't have to go to those lengths I'll try to avoid it.

Thanks for your help durgadas311 and Dave - I'll be back. :D

 

[durgadas311]

Did a little searching, this might be what you need... it actually claims to generate REL files. http://48k.ca/zmac.html

 

[nockieboy]

Did a little searching, this might be what you need... it actually claims to generate REL files. http://48k.ca/zmac.html

I've just been looking myself and found the following in the manual for Z80ASM - an assembler I use in my (SIMH Altair) CP/M 2.2 emulator on the desktop to produce COM files for the SBC...

1) One pass operation (optional second pass)
2) Powerful nested macros, conditionals, and include files
3) Relocatable format allows extended math on externals
and relocatables
4) Up to 15 different data, program, and common areas
5) Zilog/Mostek mnemonics
6) Throughput of over 6000 Lines/Minute (8"SS/SD, 2Mhz)
7) Optional alphabetized symbol table
8) Optional alphabetized cross-reference
9) Directly generates a .COM, .HEX, or .REL file
10) Labels Significant to 16 characters
11) Supports time and date in listing
12) User Configurable
13) Supports ZCPR3 and CP/M+ error reporting

The bits in bold are the points of interest - it takes Zilog/Mostek mnemonics? Actually, as I've just written that, I realise that MOSTEK were licensed to create Z80's as well, weren't they? So it's not the same as saying Z80/8080 mnemonics.. My bad.

I'll go take a look at your suggestion, durgadas311 - looks promising.

EDIT: Actually, having looked at the link you supplied, it looks like it could do the job nicely. I'll give it a go tomorrow if I can find time (Sunday roasts don't cook themselves, unfortunately.) :D