Is there a list of Z80 monitors with source code?

[alank2]

Is there a list of Z80 monitors with source code anywhere? If not, which ones do you know about / recommend?

 

[Chuck(G)]

Probably--best approach is to check old S100 documents for source--but then you'll have to enter it manually.

Why not write your own? It's not hard--and you get to implement the features that you need.

 

[alank2]

I was just now thinking about it. Probably a good learning experience too.

 

[Dwight Elvey]

I also depends on the purpose of wanting a monitor. Monitors are often useful for debugging software but some less useful for debugging hardware. If the hardware isn't working, starting the monitor itself may not work. Often to debug, hardware, it require a sequential even, meaning writing some code.
I'm not saying it is useless for debugging, only that there is often better ways and usually the hardware problem means that you can't bring up a monitor in the first place. Still there are cases it is a useful tool that you should have.
Besides the typical S100, you might look at the H8 and H89 source code for typical monitors. The H8 is usually 8080 only code but the H89 may have Z80 specific instructions ( not sure why you'd need this in a monitor ). ( selecting I/O ports is all I can think of but for a monitor, making self modifying code isn't against the rules )
Dwight

 

[Chuck(G)]

For self-modifying code, you need functional RAM. If the purpose of your monitor is to help diagnose RAM issues, that's a nonstarter. I wrote (too many years ago) a monitor that fit in a 2708 EPROM that used no RAM at all--return addresses were passed in a register, but the monitor was not position-independent for that reason.

Although not exactly a monitor, I did have a liking for the (I think) Processor Tech assembler/editor in ROM.

 

[Dwight Elvey]

For self-modifying code, you need functional RAM. If the purpose of your monitor is to help diagnose RAM issues, that's a nonstarter. I wrote (too many years ago) a monitor that fit in a 2708 EPROM that used no RAM at all--return addresses were passed in a register, but the monitor was not position-independent for that reason.

Although not exactly a monitor, I did have a liking for the (I think) Processor Tech assembler/editor in ROM.

How did you deal with read and write of I/O ports ( I'm assuming a 8080 here )?

 

[smplfyi]

Obviously I am not at all biased but the best ones are here

https://amaus.org/static/S100/cromemco/code/operating systems/RDOS/

and the manual is here

https://amaus.org/static/S100/crome...onitor Instruction Manual 023-0021 198002.pdf



regards marcus

 

[glitch]

I wrote my own:

https://github.com/chapmajs/glitchworks_monitor

It was indeed a good experience I like using vintage ROM monitors if nothing else just to see how different folks implemented things, but I often customize GWMON-80 for vintage systems because it's small, I know how all the bits work, and it does exactly what I find useful. The syntax and included functions are based off my experience with older monitors (the syntax is pretty similar to one of my favorites, the DaJen SCI monitor) and what I found lacking for how I work with vintage computers.

 

[WSM]

I realize that most Z80 systems only use 8-bit I/O addressing even though it's capable of 16-bit I/O addresses. Like many monitors, from a quick scan it appears the Cromenco monitor assumes that. The potential problem with the IN r,(C) and OUT (C),r instructions is that they output register B on A8-A15. While it's usually not a problem, if they're not zero then the monitor can't address the internal registers on a Z180 and possibly other Z80 derivatives with integrated I/O ports.

 

[Chuck(G)]

How did you deal with read and write of I/O ports ( I'm assuming a 8080 here )?

Well, you know the answer. You put the IN or OUT in known-good RAM, plug in the I/O port and jump to it. Fortunately, for console I/O, the port address is known in advance and so can be hard-coded.

In the early 8085 days, I considered implementing some logic to force a second byte onto the bus if an IN or OUT was detected in an M1 fetch. I dropped the idea as it seemed to be too much trouble to get around a slight instruction deficiency. Although, I also considered using similar logic to latch the instruction address, so that the P-counter could be read directly. The surprising thing is that the 8080 deficiency wasn't addressed in the 8085 ISA.