• Please review our updated Terms and Rules here

Suggestions for Z80 assembler, debugger, editor

L

lrochfort

New Member
Joined
Jun 5, 2026
Messages
2
Hello all,

I just finished designing a Z80 CP/M machine and writing the BIOS. Now I'd like to write some CP/M programs. My first aim is to write some simple CP/M utilities, but I would then like to move to extending my BIOS by developing on the CP/M box itself.

I wrote a couple usind ED, ASM, and DDT, but I really don't know or like 8080 mnemonics.

I went to look for Z80 alternatives, but there are far more assemblers, debuggers, and editors available for CP/M than I'd anticipated!

As far as I can tell the newer DR offerings aren't really fully Zilog mnemonics. Microsoft's offerings seemed popular, but I couldn't find a debugger. I've seen reference to others like SLR's Z80ASM, but couldn't find a matching debugger.

Any suggestions whilst I install them all and try them out would be much appreciated.
 
As far as those you run on CP/M, there are less options. MicroSoft's M80/L80 do support both Intel and Zilog mnemonics, but the command syntax can be obtuse and there are limitations to how L80 works (for example, if you are trying to assemble a new BIOS that is ORGed at it's final address, L80 is going to give you trouble). As you mentioned, DRI's tools don't support Zilog mnemonics.

As far as debuggers, the main one is DDT - which as you know only uses Intel mnemonics. DRI did make ZSID that uses Zilog mnemonics, and there are copies of it out there.

I have not explored assemblers/debuggers other than the "big two". Back in the day, the company I worked for decided to use DRI tools and I had no objection. I personally don't like Zilog mnemonics anyway, but I know there are a lot of people who do. I won't get into that cat-fight, but my decision was not made lightly and I still prefer Intel mnemonics to this day.
 
You could always write yourself a simple assembler in Z80 assembly language (or start with C to get the overall design down) using a modern machine and then bring that over to your CP/M system.

The chief difficulty would probably be making sure you are producing the appropriate binary format.

Unless you want to split your code across multiple files or include someone else's code (library?) you may be able to skip on a linker.
 
durgadas311 said:
if you are trying to assemble a new BIOS that is ORGed at it's final address, L80 is going to give you trouble
Click to expand...
ORG might give you some trouble trying to figure out the proper L80 parameters. However, I've always written my various Z80 & Z180 BIOSes using M80/L80 and rather than ORG I use M80's .PHASE pseudo-op which hasn't caused me any issues.

Likewise I'm not going to wade far into the Intel vs Zilog mnemonics debate. Coming from a S/360 ASM background at the time, I preferred the Zilog mnemonics and that decision has made my various developments on the Zilog eZ80 much easier. To the best of my knowledge there are no Intel mnemonic assemblers for the eZ80 which is the only Z80 derivative still in Zilog production.
 
I think I probably put things a bit strongly when I said I don't like 8080 mnemonics. I've done a fair bit of Intel assembly and as with everything it has its pluses and minuses.

For this particular project my entire BIOS is written in Z80 mnemonics and so it makes sense to continue that way when moving to the CP/M system. There's something very rewarding about writing BIOS software on the machine itself.
 
You've already mentioned the SLR software (assembler and disassembler). That's what I use (mostly) for coding on my Z80's. I use ZSID for debugging. Editors are a whole different story. The VDE editors are OK, but I often find myself using WordMaster. Trouble with any of these editors is the WORDSTAR-like keystrokes. I just can't wrap my head around them. I'm more tuned to VI on a Linux box. I find the keystrokes so distracting that I'm paying more attention to them than the actual code itself. <frown>
 
lrochfort said:
Hello all,

I just finished designing a Z80 CP/M machine and writing the BIOS. Now I'd like to write some CP/M programs. My first aim is to write some simple CP/M utilities, but I would then like to move to extending my BIOS by developing on the CP/M box itself.

I wrote a couple usind ED, ASM, and DDT, but I really don't know or like 8080 mnemonics.

I went to look for Z80 alternatives, but there are far more assemblers, debuggers, and editors available for CP/M than I'd anticipated!

As far as I can tell the newer DR offerings aren't really fully Zilog mnemonics. Microsoft's offerings seemed popular, but I couldn't find a debugger. I've seen reference to others like SLR's Z80ASM, but couldn't find a matching debugger.

Any suggestions whilst I install them all and try them out would be much appreciated.
Click to expand...
I would strongly suggest writing something you actually need and somebody didn't write before you (like assemblers or editors or others).

One option is adding your machine to z88dk (cross compiler in C which can generate CP/M binaries and much else) that allows you to use the special stuff of your machine easily. https://z88dk.org/site/targets. Like configure serial port speeds, set the time (all modern machines have RTC's, yes?), interact with the world if you are emulating inside a more powerful machine. Etc.

I plan on writing the following for the RC700. Perhaps it can inspire you 🙂

  • Set cursor shape and blink/not blink.
  • Configure CRT number of lines and other intricacies
  • Configure serial port speeds (Z80 SIO and CTC)
  • Define character sets for machines with RAM instead of ROM here.
  • Setting software real time clock
/Thorbjørn
 
I would suggesting writing what you want, regardless of what has been done before...

I ended up writing a paired assembler - one that runs under windows 10/11 or on Linux, and one that runs native on z80 - with the objective that they both respect the same source files and support macros and other useful functions.

They worked well, and I ended up writing a full CP/M replacement in z80 from scratch working backwards from the API with them. I started with a simple z80 assembler on PC, then wrote the z80 native assembler to run under CP/M and then wrote a new PC assembler to use the same source files and create the same binaries. I don't use a linker - they generate code directly.


I wrote them simply because I wanted to. Not because I needed them ( though I did find it very helpful to be able to adapt to my needs ) and I don't care that others have written similar. I created a small footprint z80 assembler with a lot of functionality and it does what I wanted.

Whatever you do, remember your primary stakeholder is only a mirror away.
 
Just circling back around to this - I've finally released the first Beta of mine in case you're interested what an assembler project might look like in z80 source...

It's an ultra-compact (12kb) z80 native assembler designed to work with minimal memory and has a matching cross-assembler for the PC/Linux.

As someone who's walked this exact path, happy to take specific questions if it helps?

You can find it at: https://github.com/cj7hawk/Loki-Z80-Assembler
 
cj7hawk said:
I would suggesting writing what you want, regardless of what has been done before...

I ended up writing a paired assembler - one that runs under windows 10/11 or on Linux, and one that runs native on z80 - with the objective that they both respect the same source files and support macros and other useful functions.

They worked well, and I ended up writing a full CP/M replacement in z80 from scratch working backwards from the API with them. I started with a simple z80 assembler on PC, then wrote the z80 native assembler to run under CP/M and then wrote a new PC assembler to use the same source files and create the same binaries. I don't use a linker - they generate code directly.


I wrote them simply because I wanted to. Not because I needed them ( though I did find it very helpful to be able to adapt to my needs ) and I don't care that others have written similar. I created a small footprint z80 assembler with a lot of functionality and it does what I wanted.

Whatever you do, remember your primary stakeholder is only a mirror away.
Click to expand...
If what you need is the pleasure of writing your own tools then by all means 🙂 Not much that is more satisfactory than having the first Hello world program go through your own tool chain and work.

I have had quite a bit of fun optimizing every last byte out of my firmware rewrites, first the z88dk sdcc and then llvm-z80 C compilers. Especially with linker magic to get data and code in the right places. I like the power of assembly being close to the metal, but also teaching a compiler to get code which is almost as good for a cpu not intended for that (getting the DJNZ in the innermost loop when having selveral small nested loops was not easy 🙂 )
 
Thorbjørn Ravn Andersen said:
If what you need is the pleasure of writing your own tools then by all means 🙂 Not much that is more satisfactory than having the first Hello world program go through your own tool chain and work.

I have had quite a bit of fun optimizing every last byte out of my firmware rewrites, first the z88dk sdcc and then llvm-z80 C compilers. Especially with linker magic to get data and code in the right places. I like the power of assembly being close to the metal, but also teaching a compiler to get code which is almost as good for a cpu not intended for that (getting the DJNZ in the innermost loop when having selveral small nested loops was not easy 🙂 )
Click to expand...

How do you benchmark compilers like this? I've always wondered what you would use as a yardstick for measuring performance -?
 
cj7hawk said:
How do you benchmark compilers like this? I've always wondered what you would use as a yardstick for measuring performance -?
Click to expand...
My goal here has been extreme code density which is very easily measurable - the size of the binary generated.

Speed is a little more complicated. z88dk contains a headless emulator which allow you to measure how many cpu ticks a given binary uses before exiting. Then you compile with a certain set of flags and measure. I set up a set of test programs which was then compared with the explicit goal that clang (llvm-z80) should perform better than the SDCC compiler in z88dk which is mature and widely used. For all those slower or bigger, Claude then investigated the generated machine code and found out why, and the source code responsible for it in the compiler. A modern cpu can run z80 code much faster emulated than the original ones could.

I have reached the goals I wanted, so now I am working on bringing the findings upstream in as simple a form as I can fixing the root causes, with the goal of it being usable by others. I consistently see code being 10-15% smaller and often faster with llvm-z80.
 
Almost direct Z80 equivalents of ASM and DDT are ZSM and ZSID :)
These would keep your process 'period appropriate' unlike modern IDE's
 
Phil_G said:
Almost direct Z80 equivalents of ASM and DDT are ZSM and ZSID :)
These would keep your process 'period appropriate' unlike modern IDE's
Click to expand...
SID is DDT with symbols. ZSID is SID with Z80 mnemonics, and a very powerful tool, especially if you convert the assembler symbol list to a form ZSID understands.

That said, the GDB interface is widely supported for Unix-world debugging. MAME supports it and I *think* I've seen something in the z88dk distribution.
 
lrochfort said:
Hello all,

I just finished designing a Z80 CP/M machine and writing the BIOS. Now I'd like to write some CP/M programs. My first aim is to write some simple CP/M utilities, but I would then like to move to extending my BIOS by developing on the CP/M box itself.

I wrote a couple usind ED, ASM, and DDT, but I really don't know or like 8080 mnemonics.

I went to look for Z80 alternatives, but there are far more assemblers, debuggers, and editors available for CP/M than I'd anticipated!

As far as I can tell the newer DR offerings aren't really fully Zilog mnemonics. Microsoft's offerings seemed popular, but I couldn't find a debugger. I've seen reference to others like SLR's Z80ASM, but couldn't find a matching debugger.

Any suggestions whilst I install them all and try them out would be much appreciated.
Click to expand...
If you're already comfortable with CP/M's standard tools but want proper Z80 mnemonics I'd suggest taking a look at SLR's Z80ASM first. It was quite popular among Z80 users and generates solid code. For debugging many people still ended up using DDT or ZSID even when assembling with a different tool, simply because good Z80-specific debuggers were harder to find.

Personally I'd focus more on finding an assembler you enjoy using than trying to match it with a perfect debugger. Once you get productive with Z80 mnemonics switching between tools becomes much less of an issue. Also congratulations on getting your own CP/M machine and BIOS running.
 
The other day I noticed in passing that GDB (the GNU debugger) has gotten Z80 support in 2025. This may make it possible to use modern tools for debugging live z80 code, perhaps even on physical hardware (unlikely but would be extremely powerful).
 
You must log in or register to reply here.
Back
Top