Debugger-LPT
What is it?
A device which enables you to watch the behaviour of the processor of your C= or other computer step by step. In contrast with Debugger it is controlled by the printer port of your 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 (SUT).
- In quite some situations the card is not well accessible due to its position in the system-under-test; I cannot manipulate the switches.
- Analyser
The PC can record the steps the SUT goes through. But reading the values on the address-, data- and controlbus will take much more time then this system will need to perform one cycle. This on its turn means that the debugger never will be a real time analyser.
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 controlbus. 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 very original LPT 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
Schematics
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 dipswiches and another 573, IC10, replaces all other switches. The data coming from the databus of the printer port, is clocked into the IC by a 138 (IC11), 3-to-8 de-multiplexer, through some invertors in IC12A, a 74LS240. Of course you can use three invertors from a 74LS14, I only used a 240 as this occupies less space in the drawing then three single invertors :)
The 138 is directed by the four outputs of the printer port.
The uni-directional printer port cannot use its databits 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
Schematics
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.