I am getting more excited by the hour while building the SBC-85 Bus Monitor Board and so pleased with myself that I am going to start calling this Bus Monitor Supreme. I have had a couple of setbacks, first the seller that I purchased my binary to hex decoder 7-segment drivers shipped the wrong part…. discovered after waiting 5 weeks for them to arrive from overseas. The second setback is a couple of layout mistakes, a design mistake, and one or two annoying things that I just want to change on the board. Since the replacement decoder/drivers are at least a month away, I haven’t decided yet if I will finish this version of the bus monitor or just move on to the next version. Version 1.1 would arrive about the same time as the replacement decoder-drivers and I don’t want to populate components that I will just need to depopulate later.
I am taking a little break from building and testing the board, so I wanted to give you a taste of the capabilities of this Bus Monitor Supreme to whet your appetite to build one.
Like most any run-of-the-mill bus monitor, there is a binary display of the 16-bit address values and a display of the 8-bit data byte. Also included are 18 LEDs to display the full suite of bus and CPU status signals. For convenience, the bus monitor also has a decoded hexadecimal display version of the address and data via six 7-segment displays (hence the need for the missing binary to hex decoders).
Of course bus monitors are most useful when they have single step capabilities, so Bus Monitor Supreme includes a single step mode and a momentary push button to step the program from opcode to opcode. To automate the single step during the boring bits, there is also a manually adjustable ‘slow-step’ (555 astable adjustable in the neighborhood of 0.5 Hz to 60 Hz) that saves you the trouble of repeatedly pushing the single step button when watching how a portion of your code plays out. All in all, this set of these features make for a very nice bus monitor and single step system.
… But wait, there’s more….
Generally, single stepping implies instruction by instruction stepping, i.e., step from one opcode fetch to the next opcode fetch. However, when looking for something more specific have you ever thought it would be nice to skip ahead past the generic opcode fetches and single step between some other type of bus cycle? For example, possibly single step from I/O port read to port read? Or from memory write to memory write? Since the 8085 status lines preface the machine state, they can be decoded and used to filter the single step triggers. The SBC-85 bus monitor allows the user to select (via software control or a rotary switch) from any of the possible machine state types that will trigger the stopping point and enter the single step. These bus cycle types consist of the following:
- Any Bus Cycle
- Memory Write Cycles
- Memory Read Cycles
- Opcode Fetch Cycles
- I/O Write
- I/O Read
- Interrupt Acknowledge
- Breakpoint Match
When set for I/O write, for example, the CPU runs at full speed until a OUT instruction occurs, at which point the CPU is stopped and in STEP mode where the CPU will wait until the STEP button is pressed. Once past the step wait state, it will run in full speed until the next OUT instruction. If in the slow-step mode, the monitor basically presses the button for you, so the monitor runs full speed between OUT instructions and then waits for the timer pulse before continuing to the next OUT instruction. Very useful for watching bit patterns come out an I/O port.
As a final diagnostic tool, address and data breakpoint capabilities have been included. The bus monitor board occupies four output ports. One port is for a configuration byte, two for an address breakpoint value register (MSB and LSB), and one for a data breakpoint value register. In operation, the user writes the target address to the address registers and/or the target data byte to the data register. The user then sets individual configuration bits to enable the following breakpoint options:
- Break on match of A15-A0
- Break on match of A15-A8 OR A7-A0
- Break on match of D7-D0
The 8-bit configuration port also includes a Single Step Override bit that puts the single-step (or slow-step) under software control. With this bit set the step mode is enabled, when cleared the step mode is disabled and the CPU runs at full speed. This allows the user to write into their code (or a diagnostic monitor) an instruction to enter or exit the step mode. Very handy when debugging to turn off the step during console I/O and other timing critical portions of code that do not need debugging.
Going back to the type of bus cycle filter… if the user does not want to use the rotary switch to select which type of bus cycle triggers the step mode, the IO/M*, S1, and S0 pattern can be set via three bits of the configuration port.
The most significant bit of the configuration port is connected to a speaker to allow the bus monitor to make noise– always a crowd pleaser.
I forgot to mention that the breakpoint match and/or an opcode fetch can also be used to trigger a hardware vector interrupt. This would be handy, for example, if one wanted to jump to a routine to display register values as a part of a diagnostic resident monitor.
As far as the building and diagnostics go, so far it looks like the following have checked out OK:
- Binary display
- Single step
- Slow step
- Machine state filter of steps
- Configuration port and three data registers.
- Address breakpoint
Left to test are the 7-segment displays, finish up the testing of the data breakpoint, populate the rest of the LEDs, and check out the interrupt generation upon breakpoint or opcode fetch.
Hopefully you agree that this will be a useful addition to the SBC-85 system. Let me know what you think and check out the documentation here. I do not have a lot of room, but if you think of something that needs to be added to the board, please share.