Retro Z80: Debug facilities

When building a computer from scratch you are bound to run into bugs and problems. Also for software development (the bios for instance) you will want some way to debug your code. There are no fancy integrated development environments for the Z80 (as far as I know) – so this will be roughing it.

So what can we do to make life a little easier?

Hardware

There are hardware related facilities as well as software related facilities. Lets look at the things we can do to or for the hardware to make debugging easier.

Clock Speed

We have a 20MHz Z80 CPU which at full speed goes pretty fast. It would be difficult to see anything actually happen. The use of a logic analyzer may help of course but only if the sample rate is fast enough.

It sometimes helps to slow things down to a crawl and actually see the state changes in front of your eyes – then usually it clicks in your brain what the problem is.

So having a clock that can be very slow or even hand-operated pulsing clocks with a button is very handy. Also a medium speed clock will come in useful to flesh out any hardware timing related issues the design may have. And of course a full speed clock at the intended CPU operating speed.

If you really want to make it spiffy, then a single shot instruction clock would be nice. This clock would monitor the M1 line of the Z80 that indicates the start cycle of a new instruction. The Z80 instruction usually take multiple clock cycles to fully complete – or even multiple machine (M1) cycles. I haven’t seen any circuit diagrams for this anywhere, but I’m sure we can think of something.

Bus Spy

Spying the signals on the bus of the computer can be a good way to understand what is going on. This can be as simple as attaching LEDs to each bus signal (buffered as not to load the bus too much) and running at low clock speeds or single step clock mode.

At the other end of the spectrum is the option of having an intelligent bus spy that can decode the address and instructions etc. I am sure something like this exists (I am not the first to build a computer), I just haven’t looked for it. Do you know any good/cheap ones? Please leave a link in the comments.

General Purpose Visualization

We could attach a module to the system bus that visualizes data – the simplest being several LEDs. The software could latch data into the registers of this module to turn LEDs on and off – visualizing the data.

Other visualizations could include a 7-segment display or even a LCD display (HD44780).

Test Routines

We could write some software routines the exercise specific parts of the hardware in some way. Think of these as test scripts. The simplest one is a thorough memory test routine that checks if all memory addresses can be written to and read form with the correct value. Main interest here are the memory boundaries but a full sweep of all memory addresses may even catch more types of faults.

Debugging

As the software is being developed, it will become necessary to have some form of debug support. I assume that the Z80 system is connected to a PC over a dedicated serial debug port and that the PC runs software that interacts with our on-board debug facility.

This also implies that we have a separate entity on the system that controls all this without involving the CPU – lets call it a system controller. For now the idea is to put an MCU with an external bus interface on the system to provide the debug services as well as provide I/O (SPI, I2C, UART etc). At a later stage this may be swapped out for an FPGA. But because I am an FPGA beginner – learning along the way- I’d thought we’d start (relatively) simple.

Catch stray execution

It probably would be beneficial to catch bad jumps due to programming errors or bad data in a vector address table. The Z80 could fly off into nothingness, never to be seen again. So I have been thinking if you could catch something like that. I have come up with a simple trick that just might be enough.

At startup, initialize all memory locations with the value for one of the RST instructions (0xFF for RST38). Then load the program at the specific address and jump to it. Now if the execution flow spins out of control it may jump to a memory location that has the RST instruction written and the (debug) handler there, can even retrieve the jump address from the stack and report the problem over the debug serial link.

Further stack analysis may reveal more info on the execution flow previous to the fault. That analysis can be done by the software on the PC.

Breakpoints

I though it would be awesome to support debug breakpoints for the Z80. That would certainly help with software development. But how?

There is one instruction on the Z80 that came to my mind immediately: HALT. This makes the CPU execute NOPs and signals the !HALT line on the CPU. This is excellent for hooking in a breakpoint mechanism.

The HALT instruction is only one byte and therefor easy to fit in between existing code. The breakpoint have to be compiled in (for now) so you cannot set them dynamically. Allowing to do so would require in-memory modifying the code, which brings all kinds of nasty (re)addressing issues to the -already full- table.

A Non-Maskable Interrupt is issued to start the program again and continue where we left off.

One thing we need to watch out for is to disable and interrupts on a hardware level when the HALT signal is active. This is because any kind of interrupt will exit the HALT condition.

Wrap up

These are just some ideas I came up with and not all of them will probably work right of the bat. It is a start anyway and perhaps even inspire the reader.

 

Advertisements
Published in: on December 21, 2015 at 9:53 am  Leave a Comment  

The URI to TrackBack this entry is: https://jacobielectronix.wordpress.com/2015/12/21/retro-z80-debug-facilities/trackback/

RSS feed for comments on this post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: