My encounter tonight with my old pal sn74hc688 made me realise that my vision and understanding of how "old school debugging" work is caricatural. Actually I have never used a professional In Circuit Emulator of the early 80s, though I've seen actual machines for the 6800, 6809, 68K or 8085 with their pods, their terminal... I have barely used a 6809 SBC at school but it used a monitor with assembly and a 2×16 characters LCD display. It's almost like cheating.

My best experience with debugging was with TurboPascal. Simple, efficient, lean and fast, most of my needs were met and it fits on one diskette ! But it's so far from "bare metal" vintage programming.

Now I go back to a pure hardware solution. What I first did is copy what I've seen, without thinking.

• "A vintage computer has hex displays" so I put hex displays. I have many LCD displays but they require some sort of programming or another.
• "A vintage computer has buttons and a hexadecimal keypad" so I implement them.

This is what happened in my 2nd log, I just put them there and thought the deal was closed.

But the #Discrete YASEP is a statement that things have changed in the last 30 and 40 years. A 7-segments digit was expensive, PCB surface was precious, any penny mattered and meant death or survival on the market. So you had 2 hex digits, maybe 4.

Today, many parts now are almost like "dust" so the balance and the design decisions have changed. It does not cost a meaningful lot to add a 7 Segment digits on my front panel. This project is not a "consumer product" where costs must be cut everywhere and the product is so shaved clean that you can't do much with it... There must be as many buttons as necessary and they must be convenient. It's a hobby, not a product (yet).

More importantly, now I have to rethink the whole "debugging experience" and blend the best of debugging software with what hardware does well and cheap.

I'm thinking more about the physical interface and the behaviour of the single-step feature. The keys I use for the keypad are not comfortable for fast repetitive pushes so I don't want to use the keypad for walking through a program.

At the lowest level, there are two command bytes:

• Run : let the computer clock run freely
• Step : stop the computer but send a pulse to single-step (advance by one cycle).

The rest is just a matter of sending these commands with a convenient interface. For example, the buttons should be low-pressure and low-displacement, probably with a lever.

The "Run" button is simple: it just sends the run byte command.

The "Step" button sends the step byte command.

Then there is the "Slow" button : as long as it is pressed, it sends a burst of step commands. One way to implement this is by using one of the two unused key codes of the board (32 buttons are possible but only 30 are soldered). When the unused code is scanned, the button sends the "step" code directly on the command bus, without stopping the scan. This way, you can advance a lot without having to press the "Step" button ad nauseam.

This feature creates a new problem : what is the "right" speed for running the code ? The keyboard is scanned at about 900 Hz so a single press can send you hundreds of instructions away...

It would be so nice to control that speed. The pulse could feed a variable counter to divide the frequency but this frequency will need to be controlled too. And it's never the right speed so this becomes another useability (and technical implementation) can of worms.

If we simply want to generate pulses at a desired speed, a 555 with a potentiometer will also do the trick. A potentiometer is not the best interface you can find but it's simple and easy to "get", just turn it to change...

Wait

There is something else that turns but provides a direct feedback : scrollwheels on mice, or trackballs. The inertial aspect of the trackballs makes it more comfortable for heavy rolling but even a scrollwheel allows you to control your speed dynamicly (with more efforts). Furthermore, the wheel's electronic interface is very easy to hack, using a phase quadrature signal. Just use one of the signals of the pair to send pulses on the command bus :-)

Now is the time to find a suitable mouse and hack its guts. The interface would be this :

• Left button : one step
• right button : run
• scrollwheel : steps
• press scrollwheel : move the mouse to send pulses

Today's mice are "optical" so I can't reuse the optical motion sensore, that would be priceless too.

The connector could be PS2 or USB but must be rendered incompatible with other systems for safety. The wire needs only 4 wires anyway : 5V, 0V, start pulse, step pulses. The internal controller IC would be totally bypassed but kept alive to drive the sensor's polarisation (pull-ups etc. at the right current/voltage points).

From the host point of view, a microcontroller could talk directly to a PS2 mouse but that would require programming and a lot of other things I don't want to get into. Few (fixed function) logic gates are required to implement the mouse hack anyway.

I'm sure others will reuse this idea to hack their own platform, all with software :-)

Time to implement now ;-)