Until recently, I had not given much thought to the “debugging” Z80 code other than the simple “single-step” circuitry that some of the Z80 computers had at the time. I started to realize that debugging code without being able to “see” the memory and internal registers of the Z80 could be a problem since during all my years of hardware and software design, I always had access to some sort of hardware emulator for such purpose. I never really spent much time using the “poor man’s” method of debugging code on any MCU by toggling an I/O pin when my code hit a certain location. The only thing I ever used I/O pin manipulation for was to measure and/or check timing or interrupt response.
Now that the Z80 SBC PCB’s are due to arrive soon, I will have access to a real hardware platform. There is still MUCH work to be done before I can even get to this point but it warrants some more thought. Besides, I am sort-of in a “holding pattern” until said PCB’s arrive.
In software, the “single-stepping” will be easy because the AVR can completely control the Z80 clock, address, data and control buses. However, I don’t see much use in “seeing” what data is on the data bus at a certain location at a certain time. About the only thing useful in that approach is seeing if your program is branching or jumping to the correct location as the right time or if some data in RAM is getting over-written. Seeing the internal registers of the target CPU (or MCU) is much more useful, as is the ability to set hardware and/or software breakpoints.
Emulating “shadow registers”: I’ve started looking into a Z80 emulator for the AVR. All I have found is the “SpritesMods” web page here. That emulator appears to be an 8085 emulator.
I widened my search to include ANY Z80 emulator and found two generic Z80 emulator libraries; Gabriel Gambetta’s is here and Marat Fayzullin’s is here. Both look good but I have not spent enough time looking through the code and seeing how I might use them. I am, however, considering that I may just write my own because I really do not need to “emulate” the Z80, I already have one. I just need to decode the opcodes and update the “shadow registers” with the values from the operands. More to be determined.
I wish to address implementing breakpoints. There are two potential implementation schemes; hardware and software.
Hardware Breakpoints: Since the AVR will be in complete control of the Z80’s clock, address, data and control buses, hardware breakpoints could be set by the user to trigger at certain addresses. That would be easy to implement by monitoring the address bus for an address match then halting the Z80’s execution of code. It is also conceivable that data breakpoints could also be implemented by monitoring certain memory addresses to be a certain value or perhaps even a read from, write to, data match or data change at a specific address. I am considering this method to be better than implementing software breakpoints simply because I have access to the hardware buses.
Software Breakpoints: Most “modern” CPU’s and MCU’s feature a “breakpoint” instruction. The Z80 does not have one but that does not mean that one cannot be defined using one of the various “undefined” opcodes for the Z80. In theory (practice?), the AVR being used in debugging mode could place the breakpoint opcode (not operand?) in memory and save the original opcode. While monitoring the Z80’s hardware buses and updating the “shadow registers”, if the opcode for a breakpoint is detected, then the appropriate action can be taken. Update: In looking over the Z80 instructions, sorted by OPCODE number, I see that there are no unused single-OPCODE instructions available. There are a few “extended” (or “undocumented”) ‘DDxx’ prefix instructions available but using a single-byte OPCODE as a software breakpoint is much more desirable since it can replace another single byte OPCODE. Thus, hardware breakpoints in this case are the chosen method of implementation.
Upon preliminary consideration of the two methods, I do not see that software breakpoints have any advantage over hardware breakpoints. As a matter of fact, I see a distinct advantage in hardware breakpoints over software breakpoints.
I welcome any thoughts and comments from visitors on this subject.