Single stepping and scroll wheels

A project log for Discrete YASEP

a 16-bits YASEP computer (mostly) made of DIP/SOIC chips like in the 70s and 80s... with 2010's twists!

yann-guidon-ygdesYann Guidon / YGDES 10/25/2015 at 16:449 Comments

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.

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:

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...


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 :

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 ;-)


K.C. Lee wrote 10/25/2015 at 23:13 point

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/25/2015 at 23:22 point

Hi ! Thanks for the reminder :-) I wrote in another comment that I'm not looking for a direction discriminer, I don't care which direction the wheel turns :-) I'm currently working on the next log which will dive in the "acceleration". Schematics are on their way and the little inventory last night shows I have the necessary DIP parts. See you in the next log ;-)

  Are you sure? yes | no

K.C. Lee wrote 10/25/2015 at 23:27 point

If you only need clocks, I think a combinational logic like a XOR or EXOR connected to the 2 quadrature signals might do the job.  Haven't touch these things for ages, so I might be wrong there.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/25/2015 at 23:35 point

Yes, I just need the output signal. I've figured a way to switch from "single signal" to "XOR" dynamicly, the pics will come in a few minutes at

  Are you sure? yes | no

Eric Hertz wrote 10/25/2015 at 22:09 point

Great ideas!

I imagine reverse-stepping isn't really an option... so you could probably get away without even needing quadrature-decoding, just take the signal from one of the phototransistors? Alternatively, there's a project floating round here that converts a quadrature signal into direction pulses via discrete-components: #Democracy for rotary

You might luck-out with your optical-mouse, some of the older ones have quadrature-outputs coming out of the imaging-sensor chip.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/25/2015 at 22:25 point

This is the current investigation going on in the next log, with the old SUN mouse :-) I'm updating little by little, I must process a couple of schematics now...

Happy reading ;-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/25/2015 at 22:30 point

BTW the circuit in #Democracy for rotary  "discriminates" the rotation direction. I have a different issue : how to determine the speed, and I solved this with a few logic gates. Yeah I know it's overkill but that's the beauty of the project ;-)

  Are you sure? yes | no

Eric Hertz wrote 10/25/2015 at 22:54 point

Indeed, half the fun is figuring it out!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/25/2015 at 22:57 point

oh, there is more fun to this ? what's the other half ? :-D

  Are you sure? yes | no