Z80 Assembler

[Robb Bates]

My previous project, B8Script was a lot of fun. I used the online ASM80.COM Z80 assembler to build it from one giant file. And it did the job. 

But now I'm working on a much much more ambitious project. And I'm having to break it up into many smaller files in order to be able to work with it. 

However, the online assembler just isn't cutting it anymore. So I figured I'd download a "real" Z80 assembler. I did a search and there are quite a few options. But the one that seems to be at the top is z88dk.

Unfortunately, it is a large beast of a program, and a little daunting to figure out. Does anyone know if a good straightforward tutorial to get me going? Or maybe just a quick "Just do this" set of instructions to get it running with Visual Studio Code?

Thanks, 

Robb

[Robb Bates]

Or maybe recommend a different one? Something that is as simple as:

ASM INPUT.ASM OUTPUT.COM

I don't need a million options and target platforms and command line options... At least not yet at this point in my journey.

Just assembly in, binary out

Robb

[Wayne Hortensius]

On Thu, 11 Dec 2025 18:39:28 -0800 (PST) Robb Bates wrote:

> Or maybe recommend a different one? Something that is as simple as:
>
> ASM INPUT.ASM OUTPUT.COM

I'm a fan of ZMAC (http://48k.ca/zmac.html). I came across it when I
was looking for something I could run on Linux/Windows that could
handle the same syntax as A.E. Hawley's identically named ZMAC that I'd
used for years on ZCPR.

Regards,
Wayne

[Michelle Lawson]

My Z80 IDE/Assembler of choice is this one: https://sourceforge.net/projects/zdevstudio/. It has a Linux version, but all I've ever used is the Windows version.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/20251211195807.768cb8da%40mars.

[Phillip Stevens]

On Friday, 12 December 2025 at 10:34:29 UTC+8 Robb Bates wrote:

However, the online assembler just isn't cutting it anymore. So I figured I'd download a "real" Z80 assembler. I did a search and there are quite a few options. But the one that seems to be at the top is z88dk.

Unfortunately, it is a large beast of a program, and a little daunting to figure out. Does anyone know if a good straightforward tutorial to get me going? 

The easiest way to get it going is to follow the installation instructions and use Version 2.4 (not the daily build as is suggested).

There are some rather large and important changes in the works for z88dk and its libraries, and they're being added AFTER the Version 2.4 release.

So, as the documentation is being fixed after the changes are done, it would be best to stick to Version 2.4 in the interim.

After you've done the binary installation (for Mac, Windows, or Linux), then using the assembler z88dk-z80asm by itself is a straightforward command line exercise.

However, as most of the time you're actually wanting to have a finished binary output to run on a RC2014 or CP/M machine then with z88dk it is better to use the zcc frontend tool which will pull all the pieces together to ensure that the output of the assembler is converted into what you need to load onto the machine. This might have some CRT0 code added, it might be set to certain origins (like 0x0100 for CP/M), and it might set up a stack for you in a safe place, for example.

Assuming we're talking about CP/M (all versions and derivatives) as your target, then the best thing to do is just to use zcc +cpm build your COM or HEX file. Just put your assembly file in the command line, and start with a label of _main to get it to be called by the CRT0, and off you go.

If you're using a RC2014 Classic running the MBASIC with a HLOAD command then there is an instruction for that too (also works with hexload, if you have an older ROM). Use the -subtype=basic option to get your assembly program placed at the correct origin and converted to HEX to be easily loaded.

Actually, the hexload build instructions make a nice example on how to use assembly with z88dk. There is a lst file containing the name of the two assembly files to be built, and it gives the command line used. You can check your results with the provided HEX file to see that you're getting what is expected.

Any detail questions, let me know.

Cheers, P

[Phillip Stevens]

On Friday, 12 December 2025 at 10:39:28 UTC+8 Robb Bates wrote:

Or maybe recommend a different one? Something that is as simple as:

ASM INPUT.ASM OUTPUT.COM

I don't need a million options and target platforms and command line options... At least not yet at this point in my journey.

Just assembly in, binary out

For a z80 machine start with this.

zcc +z80 --no-crt -v -m input.asm -o output_binary

+z80 is the machine target --no-crt will ensure no CRT0 is added -v be verbose so processing can be seen -m generate a map file to see where your symbols are located -o name of the binary file

To turn it into HEX code try.

appmake +glue -b output_binary --ihex --clean

+glue describes the output type (+cpm is another option) -b is the name of the binary and map files --ihex is the final output type --clean removes intermediate files.

[Phillip Stevens]

On Friday, 12 December 2025 at 10:34:29 UTC+8 Robb Bates wrote:

However, the online assembler just isn't cutting it anymore. So I figured I'd download a "real" Z80 assembler. I did a search and there are quite a few options. But the one that seems to be at the top is z88dk.

Unfortunately, it is a large beast of a program, and a little daunting to figure out. Does anyone know if a good straightforward tutorial to get me going? 

 

On Friday, 12 December 2025 at 12:35:58 UTC+8 Phillip Stevens wrote: 

Actually, the hexload build instructions make a nice example on how to use assembly with z88dk. There is a lst file containing the name of the two assembly files to be built, and it gives the command line used. You can check your results with the provided HEX file to see that you're getting what is expected.

For interest, I've just played with the hexload program, and have found a few issues with the Makefile. It is sad how bitrot just occurs. I've updated it now to be specific to python2 (otherwise the whole python script needs to be fixed to be compatible with python3), and have added the prefix for z88dk-appmake (which has been the case for a few years).

Anyway, now the hexload Makefile is now correct, and hexload program provides a useful example of how to use z88dk with pure assembly files.

Hope that helps.

Cheers, Phillip

[Ed Silky]

All through the 80's I wrote Z80 code at my company. I used a macro cross-assembler from UNIDOT. Since it was a cross-assembler that was running on a UNIX (not Linux at that time) system, I thought I would look into whether it might still be available (and could possibly run on Linux or Mac). I did find a website for them that mentions assemblers/compilers, but for anything on the site it says to contact them, so I sent them a note - we'll see what I find out.

-Ed

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/2b10d8ee-d164-4f0f-a37e-9d6cb877b3ccn%40googlegroups.com.

[Robb Bates]

Thanks for all the suggestions everyone.

I've decided on z88dk's assembler.  Turns out it is pretty straightforward to use.  Best to start getting used to it and growing into all the other features it has I guess.

Now I'm trying to set up a CP/M emulator with debugging features that can tie in to and track along with the source code in Visual Studio Code.  Currently I'm trying out MAME with the RC2014 engine.  I think Wayne H had a hand in that?

The debugger seems to work well.  Memory maps, registers, step into/over and all the usual stuff.

But now to figure out how to tie it into VSC and to automate sending the compiled output file straight into MAME.

Robb

[Robert Price]

Hi Robb,

It's not for CP/M, but I use VS Code when developing for my RC2014
Classic ][. I have some tasks to assemble the code, send it to the
RC2014, and run it.

I use the Sjasmplus assembler, along with some of the z88dk tools to
assemble the code and convert it to hex.

I wrote it up as part of last year's Retro Challenge. It may be of use to you.
https://www.robertprice.co.uk/robblog/rc2024-part-13-my-rc2014-mac-development-environment/

Cheers

Rob

> To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/a80b49a9-0fca-451c-a778-a989d15409f4n%40googlegroups.com.

[Jonathan Harston]

Another vote for ZMAC. Available for multiple platforms, I use it on
RISC OS and Windows. Additionally, fits my requirement of a single
executable simply called with CMDNAME filename. Eg, here's one
of my build files:
H:\Apps\zmac editmc.asm
That's it! If you want more control, you can do eg:
H:\Apps\zmac -o ANSI.COM -x ansi.lst ansi.asm

jgh

[Robb Bates]

Michelle, does ZDev emulate CP/M and also have a debug feature?

I'd really prefer to stick with Visual Studio Code since I'm familiar with it, but I really need a debugger.

Robb

[Michelle Lawson]

Robb, I'm not exactly sure what you mean by "emulate CP/M". It's an IDE, so you can write the code and then assemble it all in one place. I just set the 'org' equate for 0100h, assemble the code with a .com extension, upload it to my CP/M machine with a terminal program, and then save it to my CP/M disk (CF card). I can execute it from there. That said, I have done that on my CP/M 2.2 machine, which is an STD bussed version of the CPUville SBC and my S100 machine from S100computers. I haven't done it yet on my RC2014 yet since that is a Christmas present and I have to wait a couple more weeks. There is no reason it shouldn't work on that as well.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/0cfa4d70-2eef-4889-bcea-2ca07a3473e3n%40googlegroups.com.

[Robb Bates]

Well, running it directly on my ZedPro doesn't allow me to halt the program and inspect the memory or registers.  That's why I'm looking for an emulator with those features.

Robb

[Ed Silky]

The company I worked for in the 80's built large systems that were completely Z80-based. There was so much Z80 HW and SW development that they had me design a Z80 ICE, and they manufactured several dozen of them for internal use (and two were sent to Zilog). I was allowed to keep one when I left, and I still use it. Maybe I should create a new version of it and make it available as a kit. It provides 2 hardware breakpoints that can be instruction fetch from given locations, or memory reads or writes from/to a location of any value or a specific value including don't-care bits. They can be breakpoints for code, or they can just provide a sync signal for debugging hardware. It allows single-step, register view/modify, reading and writing memory or I/O, and includes the ability to just continually read/write (again, more for hardware debugging). For code in RAM, it also provides an additional 8 soft code-only breakpoints.

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/2ca000de-117f-41a2-ba8a-45ffdc50edcan%40googlegroups.com.

[Richard Deane]

Z80pack emulator can be built with a Mostek ICE debugger capability. Terminal-Break to invoke. Same available in emulator subset on  rp2350-geek.

Richard

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/2ca000de-117f-41a2-ba8a-45ffdc50edcan%40googlegroups.com.

[Michelle Lawson]

Ed, I'd love to see that thing. Might it be something that is a candidate for a modern rebuild?

[Bill McMullen]

As this thread has wandered into the area of debuggers, I thought I'd mention that Zilog solved many of these issues when they created the eZ80.  The silicon has an integrated debug interface (ZDI) which uses a 6-wire interface to provide various debug features like breakpoints, single stepping, register, memory & I/O port displaying / altering, etc.  There's also an even more powerful debug interface (OCI) which I haven't experimented with.

While I've used ZDS/ZDI to debug Z80 application code, mostly I've used it with I/O drivers and BIOS code.  Since it's a hardware-based debugger, one of the unique features is that it can set breakpoints on addresses in read-only memory.  In keeping with the RC2014 group theme, I'll admit that I used the ZDS/ZDI debugger while developing my eZ80 RCBus card.

[Ed Silky]

Here is the ICE I designed and my company produced: (with and without cover)

Since Bill mentioned it, this can also set breakpoints in ROM. That's what I mean by 'Hardware Breakpoints'. It also records 8K of all bus states, at each operation. So, you can 'View History' and see:

 MEM WR 7E02 : 9E

 I/O RD 3680 : 3A

 IF     F28A : C3   JP F500

 IF+         : F500

 ...

for the previous 8000 operation.

For memory or I/O read/write breakpoints, the two can be used independently, or they can be combined to break on a read or write between two addresses. For IF they can be set to A or B, or they can be used together for A then B.

It also disassembles code to show what was executed (in the history and single-step), or for a block of memory.

-Ed 

 

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/78a41b32-6fa6-4c04-bc6d-27d55a4c8941n%40googlegroups.com.

[Bill McMullen]

Ed: That's a really neat and useful piece of test gear!  I'm sure the Z80 community would appreciate it if something like that could be built for a reasonable price.  Given that the objective is functionality vs true retro, perhaps it could be simplified a bit by using newer components like CPLDs and/or memory chips.

[Ed Silky]

Yes, it would need to be changed some, as some of the parts are no longer available (even on eBay). It does use some programmable logic (the smaller chips with the labels). Those would need to be changed as well, as the particular parts used are no longer available. The ram is 4x8K chips, which are written 32-bits (wide) at a time to record the history, and read 8-bits at a time (to access for history and the monitor's operating RAM). When I finish my current project (a Z80 SBC (ZMB) with an RC2014/Z80 bus), I will look at reproducing this for people. I am making a debug board to go along with my ZMB that plugs into the RC-Z80 bus, but it uses the Z80 'special' reset, which I bring out to the bus separately from the Board-Reset.

BTW - I wrote all of the operating code for the ICE:

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/753dd251-9713-423c-b795-b58d7c229a92n%40googlegroups.com.

[Richard Deane]

The ICE in Z80pack is full featured with memory read or write etc breakpoints. Really handy in rp2350-geek, about £9 (15 dollar?)

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/CACc-QnKXiTT0srJGGM2cMLuqG-zDuprFyO7PwaDAVbYrm31ZXQ%40mail.gmail.com.

[Michelle Lawson]

LOL Ed, that is a lot more complex than I was imagining; but, OMG, that is an amazing piece of equipment. Best I ever put together was a little box with a bunch of switches to static test the signals to/from the Z-80 so I could trace them out. I do tip my hat to your work Ed......

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/CACc-QnKV%3Dcv8%3DHTrr3st1DcqHt%2BpS%2BjfrRYnqxYxQEx4U70yrw%40mail.gmail.com.

[Ed Silky]

That IS really cool. That is a great price too. I looked at the GitHub, and it mentions a Mostek ICE, but there wasn't a picture of that, only the emulator portion. Does that actually plug into a board in place of the Z80 (like mine does)? If so, then it is a really great deal. I'll have to look into getting one (to play with).

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/CAG2GuRYn%3DAn0gh3-aY5a1xdxtw5PqA%3D1cMhVy2HUJ26N52zJoQ%40mail.gmail.com.

[Bill Shen]

As Bill McMullen has said earlier, CPLD may replace a boardful of logic and shrink the board size down to a RC2014 module.  It can be useful to publish the spec of your ICE and see how the modern devices can reduce the size and cost of an updated ICE.
Almost 6 years ago, I've published a rudimentary DiagRC module which is a small 64-macrocell CPLD on a RC2014 prototype board, https://groups.google.com/g/rc2014-z80/c/3FaFwSZYRyY.  It has no memory, but collected addresses, data, control signals and formatted it into serial data stream and transmit it out at 460K bps; it is essentially a trace module.  RC2014 boards need to slow down to about 10KHz so serial port can keep up.  Looking at the design again, I feel a larger CPLD with RAM can keep up with 7.37MHz Z80, insert multiple breakpoints and display the register contents at the breakpoint.  It should be an interesting board to design.
Bill

[Ed Silky]

Hi Bill (Shen),

There isn't actually a lot of discrete logic on the board. As I mentioned, the 5 chips with labels (not the EPROM) are programmable logic (3x 22V10 and 2x 16V8). I imagine that those 5 could be combined into a more modern CPLD, which would be good. Maybe it could reduce 5 chips to 1, but I would need to look at the number of signals in and out. There are some CPLD's that have 64+ pins, so maybe? At any rate, I would need to do something with those devices, as they aren't easy to find, so I would want to change them anyway. There are some other parts that are no longer available or very hard to find:

4x 74AS866  8-Bit, LT/EQ/GT Comparator w/LD&CLR

1x 25LS2521  8-Bit EQ Comparator

4x HM6264  8Kx8 Static RAM

There are also 3 counters (74ALS191) that generate the address for the RAM to record the bus-signals for the history (while it is recording). They might be able to be put into the CPLD if it doesn't run out of pins. I say that, because the Z80 address bus flows through the counters when the data from the RAM is being used by the ICE (rather than recording bus history). So that is 24 pins (ZA2-ZA13 in and HA0-HA11 out).

And then the Z80 and Z-SCC. My unit uses 8MHz parts, but I would bump that up so it would work on faster boards.

The board has two RS-232 serial ports, one for the terminal and one for a printer. I would consider changing that to a single USB-C. That would replace the RS receivers and drivers and the +/-12V power module with an FT231XS (20-SSOP chip). I don't have a serial printer that I want to send output to directly from the ICE (we did back in the 80's). Now, I just capture output from the laptop that I'm running the terminal emulator on.

As I also mentioned, I'm designing a RC2014-Z80 Bus debugger to work along with my ZMB (Z80 SBC w/2014RC-Z80 bus). It will have a single hardware breakpoint (or sync signal) that can break on IF, MR, MW, I/O-R, I/O-W, at an address (ROM or RAM). It won't be recording any bus history. For the break, it generates the Z80 'special reset', so my ZMB has a separate board reset and Z80 reset. I bring both out to the RC bus separately. (Board-Reset resets everything, but Z80-Reset only goes to the Z80)

I should probably create a separate post for any further discussion.

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/b1a3432d-95c3-4c9c-91cd-0799d75c1e53n%40googlegroups.com.