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?