Ruud's Commodore Site: Debugger-LPT Home Email


What is it?

The Debugger-LPT enables you to observe the behaviour of the processor step by step. In contrast with Debugger it is controlled by the printer port of a PC.

The story

My original debugger has three disadvantages:
  • The used intelligent 7-segment displays aren't cheap.
  • In quite some situations the display is not well readable due to its position in the system-under-test.
  • In many situations the card is not well accessible due to its position in the system-under-test; I cannot manipulate the switches.
This raised the idea to use a PC to display the content of the display of the debugger. The printer port could serve as the interface between the card and the PC. Beside the improved accessibility and readability, there was another advantage: the debugger could be used as a kind of analyzer and error detector.
  • Analyzer
    The PC can record the steps the system-under-test goes through. But reading the values on the address-, data- and control bus will take much more time then this system will need to perform one cycle. This means that the debugger never will be a real time analyzer.
    I have thought about it to call it a sampler, but sampling means to pick only some parts/items out of the whole and the debugger still collects everything, although slow.
  • Error detector
    Having recorded the behaviour of a good system, the data can be compared with the behaviour of a bad system. The point in the program where the bad system starts to behave different could lead to the faulty hardware.

The hardware

The idea is quite simple: replace all 7-segment displays with 541 buffers and replace all switches with the output of a 573 latch.
Two remarks:
- My original debugger has no means to watch the state of the various lines of the control bus. In this case a 541 buffer can take care of it.
- I want to use this debugger for systems equipped with the 65816 processor. Therefore I need some means to watch the segment address as well.

As you know, there exist several versions of the printer port: uni-directional (the original printer port), bi-directional (also known as PS/2 printer port), EPP and ECP. Fortunately for us we only have to choose between using the uni-directional port or one of the other three.
What do we need:
- one 541 for reading the segment byte of the address bus
- one 541 for reading the high byte of the address bus
- one 541 for reading the low byte of the address bus
- one 541 for reading the data bus
- one 541 for reading the control bus
- one 573 for setting the high byte of the address selector
- one 573 for setting the low byte of the address selector
- one 573 for replacing the switches

The uni-directional version

This version is nothing more then the automated version of the original debugger. This design lacks certain features described above. I only give the schematic as it is to show you how it can be done.

Two 573's, IC5 and IC9, replace the two 8-bit dipswitches and another 573, IC10, replaces all other switches. The data coming from the data bus of the printer port, is clocked into the IC by a 138 (IC11), 3-to-8 de-multiplexer, through some inverters in IC12A, a 74LS240. Of course you can use three inverters from a 74LS14, I only used a 240 as this occupies less space in the drawing then three single inverters :)
The 138 is directed by the four outputs of the printer port.

The uni-directional printer port cannot use its data bits to read data, therefore we use four of the five handshake lines. The data is delivered by three 74LS257 quad 2-to-1 multiplexers. The signal for telling the 257's what nibble to transfer is generated by IC10 as well.

The bi-directional version

Roughly the schematic is the same. But the 257's have been replaced by 541 buffers and the line for selecting the right nibble has been dropped.

Having questions or comment? You want more Info?
You can email me here.