Z80 project - bus monitor

[TomS_]

Hi everyone.

Lately Ive been plotting a new project, my own take on a Z80 based "computer". More on that later perhaps.

As part of the project, Ive been inspired by another video to design/build a "bus monitor" () to display what is currently happening in the CPU and on its busses and enable some forms of interaction. Other than using an emulator, I figure this is probably about as close as Ill be able to get to an in-circuit debugger. I also intend for the bus monitor to be an interface to single instruction stepping functionality.

As part of the design Ive included what I believe should function as a series of triggers on certain read-based events, each of which can cause the WAIT line to be asserted low, and from there allowing a value to be manually latched on to the data bus, and then resume CPU execution - i.e. the CPU should then read in what ever value you placed on the bus.

Ive come up with what I think is a pretty nifty design, but Id be interested to hear from others whether Ive goofed anything up or if there are better ways I could do it. Attached is a schematic, but to help you make sense of it, this is what I have designed (intention):

* Two "capture registers" which can be triggered on things like I/O or memory reads or writes, instruction fetch, or simply display what ever is going on on both busses
* Some trigger circuitry which is based off some traditional single stepping circuitry, but with the added capability to not only single step from an M1 cycle, but also from a I/O or memory read
* A lot of buttons and associated debounce circuitry connected to some D flip flops, which can be used to input a value which can then be latched on to the data bus during one of the above mentioned trigger events

By default the manual data bus output is isolated from the data bus by a tri state buffer, with some series resistors in case you do something silly like latch on complementary values when something else is already driving the bus - the idea being that the resistors should limit any potential damage that might have otherwise been caused by creating some short circuits. At least thats what I think could happen... idiot proofing?

Some "interlocking" prevents manual data bus latching if a trigger hasnt occurred, and the value is then unlatched at the end of the read event so that it doesnt hang around and interfere with later reads/writes.

A button with associated flip flop allows you to cycle between the two capture registers so you can see what was captured based on the trigger that each register was setup for. At the moment I just have some 4 way DIL switches in the schematic to select between 4 of 5 possible triggers. I plan to replace these with some 4 position rotary switches instead (just need to create the parts), to prevent multiple options being switched in at the same time, which could be bad... The theory behind those triggers is that when the two component signals return high at the end of the read/write event, the values of the address and data busses should be latched in to which ever capture register has been setup for that event. Ive not tested it yet, but theory wise I think it should work.

Still a lot more breadboarding to do to verify some aspects of the design, but what do you think? 

[Blinkenlights]

If the traces to the 74ach573 inputs can be kept reasonably short, you could dispense with IC1, IC2, IC7 - as the two 74ahc573 loads would be handled okay by the bus.  A pulldown is needed on the common side of SW1 and SW2.  Your design as it stands has the no programmable parts, which makes it great to hack with.  However, IF the whole right hand side of the diagram was replaced with a single chip micro, you could do even more, - although admittedly making it harder for other people to use/hack, and being a bigger project.

The 8x74AHC74 flip flops could be replaced by a hexadecimal keypad processed by the single chip micro and presented as the 8 bit data bus. The wait circuitry (really the "continue" function) could also be triggered by the single chip micro.  The single chip micro could also read the Z80 data bus.  (Frankly, it could read the address bus as well, but that would complicate your design, and right now your design is easy to understand.)  The single chip micro could, for instance, send that data stream to a PC for display or logging, and data input if rqd.  The single chip micro or the PC could expand out the hex codes seen in each M1 cycle to actual op-codes, - disassembly in real time, so to speak.

[TomS_]

If the traces to the 74ach573 inputs can be kept reasonably short, you could dispense with IC1, IC2, IC7 - as the two 74ahc573 loads would be handled okay by the bus.  A pulldown is needed on the common side of SW1 and SW2.  Your design as it stands has the no programmable parts, which makes it great to hack with.  However, IF the whole right hand side of the diagram was replaced with a single chip micro, you could do even more, - although admittedly making it harder for other people to use/hack, and being a bigger project.

The 8x74AHC74 flip flops could be replaced by a hexadecimal keypad processed by the single chip micro and presented as the 8 bit data bus. The wait circuitry (really the "continue" function) could also be triggered by the single chip micro.  The single chip micro could also read the Z80 data bus.  (Frankly, it could read the address bus as well, but that would complicate your design, and right now your design is easy to understand.)  The single chip micro could, for instance, send that data stream to a PC for display or logging, and data input if rqd.  The single chip micro or the PC could expand out the hex codes seen in each M1 cycle to actual op-codes, - disassembly in real time, so to speak.

Thanks for your feedback.

I see what you mean about SW1 and SW2. I suppose in my head I figured there would always be one trigger source switched in so there would have always been a current source or sink, but there would be a small period of float in between changing the switch position.

As for using a microcontroller, this is something I hadnt even thought about because I was so interested in building a discrete logic solution, but its sparking my imagination with the possibilities for cool features and functionality that it could unlock....! Something to ponder .. maybe I'll do a second design based around this. And perhaps if I base it on an Arduino Nano or some such it would at least be "more accessible" from that perspective than if it were a standalone microcontroller. I have a few of these laying around, so it would be good to put one to use in some way other than collecting dust.

I am also thinking about the ability to read/write memory locations as well. It is a bit of feature creep from my original intentions, but it could help to make it more universal. With a micro, doing things like "next/prev memory location" for reads and writes would also be possible.

So much to ponder!

[C]

First think of how much your bus monitor will assist you.

You have a digit display.
The display has to change very slow to be of any use. A normal Z80 program is moving all around in address space.
Even just led's on signals become something that changes intensity.
So a Z80 program running at a few ten's of hertz makes display useless.
What you have is not great even for debugging a program. You often need to do thousands or more instructions before debug area.

You need very little rom code to get a Z80 running. With a running Z80 you can replace hardware with software and gain easy change.

First start with a rom that the Z80 can write to. After initial programming that could be done via an arduino, the Z80 has control and can update it.

Basic hardware
A 273 chip that is reset on power on.
A 8-bit input port with switches.
A 8-bit output port with led's
Huge ram chip
Huge rom chip  ( remember it's Z80 writable )
Would be smart to start with 512k memory. You can get this in a 32-pin dip package. It's not hard to strap extra address inputs at project start and then use more later.
This is foundation for a powerful Z80.

One bit of 273 can control if read comes from rom or ram

Power up could be simple read from rom and write to same address of ram. After this switch from rom read to ram read by changing bit of 273

Often forgotten is that a CPU like Z80 can write to more then one chip. To update rom you could read from ram and write to rom or both.

Now for a nice debug/status display you could use one of the many character display modules with simple software to control. Think you will find that most list a 8080 interface mode.
You have many choices of lines vs characters on line with simple interface.

A second input port with push button switches will make input simple.

Remember that Z80 has 8 one byte restart instructions that are often used for debug. single stepping a program becomes removing a byte from ram and replace with restart instruction.
Code called by restart instruction then replaces original byte.
 
Large writable ROM lets you have power off storage. With storage like this comes more powerful system.

You have foundation of easy system that you can add to.

[TomS_]

So a Z80 program running at a few ten's of hertz makes display useless.

That was why I had single step, with two registers able to capture address and data bus contents on various combinations of signals, like memory read/write or IO read/write. If the CPU is halted after capturing a value, you can then view what it was. When single stepping the display is more readable - obviously I am aware that at more than a few hz the display would be useless.

What you have is not great even for debugging a program. You often need to do thousands or more instructions before debug area.

Something I have been thinking about after Blinkenlights post is an address breakpoint. This would be easier to achieve with the MPU based approach as it could be very trivially entered via a keypad.

Im also looking at ROM monitor options. It would be very useful for testing small routines as opposed to keying it all in using the bus monitor itself. Load some code in to a memory address and then call that location.

Remember that Z80 has 8 one byte restart instructions that are often used for debug. single stepping a program becomes removing a byte from ram and replace with restart instruction.
Code called by restart instruction then replaces original byte.

Im not quite sure I follow how a restart instruction can be used for debugging? Unless it involves loading some new code at the reset vector address after the CPU has started up, and at that reset vector it can then "do stuff" to pull WAIT low for example?

[TomS_]

First think of how much your bus monitor will assist you.

There is also some "fun factor" in building it just because. 

[C]

Costs little to dream with paper. Thinking far ahead can give you good hints so you can build what you want and have easy way to change in future.

Think about Z80 being able to read switches & output to displays.

Good luck

[ale500]

Im also looking at ROM monitor options. It would be very useful for testing small routines as opposed to keying it all in using the bus monitor itself. Load some code in to a memory address and then call that location.

Think of the following possibility:

There are at least two ways of handling that:

1. You edit/compile on your PC and download the ready code into RAM via a monitor using a serial terminal.
2. You edit/compile on your PC and download the ready code into "RAM" using a RAM emulator: You need just an (for instance) ATMega328  that receives the new code from the PC and acts as a RAM. The Z80 has a wait line you can control with the uC and gives you time to read the program from FLASH and deposit it on the corresponding PORT.

You can use option 2 to develop a monitor. You may think that using another uC as a helper is "cheating"... it may well be .

[TomS_]

Sooo I did some work during the week and re-designed the bus monitor to include a full hex keypad, with two extra buttons for 00 and FF.

The other buttons on the keypad are used for toggling between the two capture registers, toggling BUSRQ, stepping, selecting between read/write, toggling between entry for address, data or another neat feature mentioned below, and a "load" button. Im hoping this new design will allow for the ability to read/write memory if I can get the control signal timing right, hence the load button.

Ive got an Arduino Nano spec'd in for the "micro" which I think makes it more accessible as a project for other people, but the "purist" in me wants to use a straight PIC.

Otherwise its much the same as the previous design, although I went another step further and included some comparators which I intend to be used for "address breakpoint" functionality - i.e. assert the WAIT line when a certain address is accessed.

There is also provision for some '166 parallel to serial shift registers which could provide an ability to read the address and data busses as suggested. I dont know if I'll actually build that functionality, but the design work is there.

I think this thing is now officially more complicated than the Z80 it is meant to drive. Not to worry though, even if this doesnt see the light of day, Ive quite enjoyed the design challenge.

I will definitely need to build this over two boards now though. The original idea was a single 120x180 proto board of which I had a couple in stock, but with the full size keypad and additional circuitry I dont think that is going to be possible any more.

[C]

Think you will find if you check data sheet that the Z80 has limited current output capability.

Driving led's directly from Z80 pins is not a good idea.

Also think you got a logic error with your address buss break point.
Think the address buss has random data until one of the qualifying signals goes active.

When you have iorq active you have ___ & ____
When you have mreq active you have ___ & ____
When you have refresh active you have ___ & ____
otherwise it is changing.

Keep in mind that display is not useful at normal Z80 speeds.

And you could revise your drawing and make it a lot easer to under stand. Better understanding lets you and others find errors easer.

[TomS_]

Also think you got a logic error with your address buss break point.
Think the address buss has random data until one of the qualifying signals goes active.

Good point, I think youre right about that. More work needed!

And you could revise your drawing and make it a lot easer to under stand.

It is quite a big schematic. Are there particular things that you find difficult to follow? Happy to re-draw if there are particular suggestions.

[C]

When you have a lot of things the same, make them match.

Will save time when you draw & make it easer to understand.

Make good flows paths so that you do not have to jump all over the place following the wires.

For example

You have a Z80 that needs buffers, make it easy to see that all needed pins are using buffers.
In stead of a bus that has A0-A15, your drawing should have two buses that are close with one A0-A7 & A8-A15.
this lets you follow a bus line and hit a buffer. Then put the 74HCT688 inline with output instead of jag.

You have  two chips  to do serial in & out with a bus connected between align them.
Make the input trace and output trace stand out.

You have three groups of two digit circuits make them match and remove the bends when you do better alignment of parts.
You have a cross over up by digits, would be better to cross at 573 chip as you would see two groups of four connect dots.

Try to remove splatter of AVR connectios
A SPI bus could be easer to follow.

Like I said, think you have logic errors but you have a mess and takes time to decode a mess.

Could be that many pages would save you time, make things easer to change & follow.

Make you drawing good & logical not a rats nest.
 

[C]

Press S13 & S9 and think about what could happen.
Will not happen is not a good answer.


I would put AVR interface at bottom of drawing.

[TomS_]

Press S13 & S9 and think about what could happen.

Thats a good one that I have overlooked. I have been thinking about this, but only from a software perspective. 

Much appreciate your feedback! 

[TomS_]

Latest iteration. 

Yes, I forgot about the diodes in my keypad matrix, so that is now resolved.

I breadboarded the circuitry that generates the capture and single step triggers and that had to change from what I originally thought would work based on my interpretations of the timing diagrams in the datasheet. During that testing I found that a small capacitor at the output of U36A, which is the memory read trigger, was necessary to prevent some false triggers. Maybe I should have used a slower logic family (AHCT is pretty quick!) 

Otherwise some general shuffling to try and tidy things up, line things up etc as suggested, and some options to mask different types of address breakpoints and/or the high byte of the address.

I think now the largest problem is one of software to handle keypad interaction and all of the shift registers.

[C]

Some times is takes little change to gain a lot.

You know what you want and have one design.
Make a list of capabilities.
Make a list of not capable.

Set this design aside.
Just on paper and keeping it simple, make some other designs.

For example
1. what would the circuit look like if a second Z80 was in place of the AVR.
Could some of this make what you have better?

2. How would the design change if the Z80 also could read the keyboard?

3. How would the design change if the Z80 could write to display?

4. How about the AVR being I/O for the Z80?

Would a 74x273 help?
Would a 74x138 help?



Think about SPI. Think that it's clocked at 16m, If so and the AVR can keep up that is one byte every 500ns.

What happens and how could circuit change if you counted SPI bits.
What would happen if you treated this like a ram chip.

What if your 74HCT688 could check many addresses during one Z80 memory cycle?

You might not have heard about it, but often a good design will use one or more TTL delay lines. Think of a chip that you input MREQ and get a bunch of outputs each delayed by X time.

Think about how the Z80 works compared to your AVR.

After thinking of all these things, does you design change?

[TomS_]

After thinking of all these things, does you design change?

Lots of questions.

I think it would change quite a bit!

But simply, I dont intend to have the MCU read the address/data busses continuously, attempting to capture every change - although I have included some 74x166's that would allow me to read those busses, I picture that being more for linking this to a PC with some software to control stepping etc. I dont know how likely I'll be to implement something like that, but it doesnt cost much to include the hardware.

And based on that, I also dont intend to have the keypad readable, or display writeable by the Z80. This is purely, in my own mind, a debug interface. Even just on a breadboard with only parts of the circuitry implemented, and with a simple program in EEPROM that does some "fake" memory/IO reads/writes (along with the legitimate ones) I am able to step through instructions etc to check that it is executing the code as I intended. Pretty cool I think - its doing exactly what I wanted. 

I dont think I would replace the MCU with another Z80, I think that is beyond the intention for this, and maybe not as functional as I would like. Certainly I dont think I would have the space for it - Im already up to two boards to implement this design and originally I wanted to fit it on one. Im aiming to build something a bit more "old school" like, so I dont intend to do anything like using a modern MCU to implement peripherals/memories/etc. I'll do plenty in software when I start writing assembly for the Z80. 

Some of those things may be adventures for someone else to take.

[C]

There is the problem, I did not ask if you would want that. I asked how it would change the hardware.

If you went through a simple think of the questions, I think you would see a better way of reading the keyboard with the AVR. Just a minor change of what you have now!

That is just one of many that I see. But it's your project.
Thinking about Z80 will help you in future for Z80 but could help you here also.

[TomS_]

If you went through a simple think of the questions, I think you would see a better way of reading the keyboard with the AVR. Just a minor change of what you have now!

Maybe I am blinded by my own vision, or ignorant, or both. Perhaps if you can drop some more hints I will see what it is that you are suggesting?

[C]

Maybe I am blinded by my own vision, or ignorant, or both. Perhaps if you can drop some more hints I will see what it is that you are suggesting?

By looking at many designs you have something to compare.
Thinking can be fast, very simple scratches on paper not as fast. Your drawing is great but takes time, So quick and dirty something you can use.
So your idea as a big low detail block drawing might not change but at same time there are many options for circuit.

How many ways can the AVR talk to logic?

With the Z80 you have access to more then just an 8-bit port like the AVR has.
With the AVR you need extra bits of a another port to use an 8-bit port for 8-bit data. The Z80 WR signal.
You need to toggle that extra bit/wire/signal. So one Z80 out instruction becomes three AVR instructions.

When you change to SPI, you have just switched some parallel wires to serial format.
Z80 uses addresses for extra bytes, SPI uses less flexible forced serial order.

So your current display connection is as a 1by Z, and you have added some switches to get the 1 to change so you have X by Z.
The Z80 works by bytes, so you need X by Y by Z(.
This also works for AVR. Now you have an address, AVR gains ease to update just one address.
AVR can still be using SPI.

As you added the debug address compare you added control signal. With address base you would use an additional address.
Three wires and valid signal gives 4 addresses. One more wire and you have 8 addresses you can use.

So AVR to SPI to bytes then to where needed.
Your hardware knows which bit is current bit on SPI
Your hardware could use this for an X by Y by Bit or byte.

So dumb quick thinking. The Z80 has 40 pins, that is 5 bytes.
As serial that is 10 chips. As combination of serial and parallel, could be less, and at some point in pin count will be less.

Keyboard is ___ or ____ or ___. Many ways you could think.

[TomS_]

So, Ive been a little busy over the past month and a bit. Part of that was buying a house, the other part was finishing the design and build of the bus monitor. I went for it, and it works! 

Ive tested it at clock rates up to 10MHz, but unfortunately it doesnt quite work properly at those speeds, and single step triggers end up overshooting by one address usually. It does work perfectly at 4MHz though. Im going to grab a 6 and 8MHz oscillator and test those to work out what speed it will work to.

I did end up going with the microcontroller solution to handle the keypad and other interface bits, this made it possible to implement a reasonably full featured keypad. I ended up using an Arduino Nano, hoping that this may make it a slightly more accessible project for others that may want to build something similar. Maybe I will write a pure PIC implementation of it at some stage if I feel like a bit of a challenge.

Ive yet to finish a couple of small software details, and then I will upload all of the design work to my github account along with full operating instructions, but in the mean time here is the latest as-built schematic and a couple of photos. Enjoy!

I do have one issue that I am yet to fully investigate, and that is that when using the onboard clock generator, the Z80 seems to lose its mind shortly afterwards and ends up in some crazy loop accessing high memory addresses. But as I have now just bought a house I think this project will end up on hold for a little bit. Good timing for near completion though perhaps!

[georges80]

^ Bundling wires together can make things look tidy, but can also introduce a lot of crosstalk and cause difficult to diagnose problems.

I learnt long ago (when wirewrapping was common and SMT devices did not exist) that an 'ugly' layout typically operates more reliably...

cheers,
george.