Calculators and 64-bit integer math.

Completed HC08 emulator in Java; will post as soon as I get a chance to validate the code. Also completed a basic 64-bit integer library for the HC08 that fits in about 1.2k. (Multiply and divide use shift/add rather than the HC08 mul and div instructions.) My goal: a basic floating point calculator written for the HC08.

Because who says a steampunk calculator should work like the el-cheapo four-banger calculators you get at the office supply store, but with brass inlay?

We used to make things.

I remember a time when we used to make things. Duvac in Pasadena used to carry wire wrap supplies and integrated circuits. Fry’s used to have a wide selection of products for making circuits that weren’t contained in packaging that yellowed with age. You could buy Nixie displays from Radio Shack.

Perhaps it was a matter of economics: if you wanted a home computer on the cheap you needed to make it yourself. Perhaps it was a matter of tinkering: back then, you had to build your own stuff, while today “tinkering” involves playing with PHP and building your own web site. Or perhaps it’s simply just a matter of a culture which wants things faster, better, cheaper–and when you can buy a really cool computer or GPS gizmo with full color display for under a couple of hundred bucks, who wants to spend a thousand to get a small box with a handful of LEDs that flash?

But no-one seems to make things anymore. Which is a shame.

So in my spare time I decided to build a Simon-like game clone–because I can.

Here’s the circuit diagram: game circuit diagram, and here’s the source kit for SDCC for the software for the game: game source kit. The final ROM size is 1193 bytes, well under the 4K limit for the HC08QY4. (With some work it probably could be made to fit in less than 1K, suitable for the HC08QY1, which in quantity is around $1/unit.)

Update: There is a typo in the diagram. The CPU used is the MC68HC908QY4, not the QT4. The QY4 is the 16-pin version, and what is shown is the 16-pin DIP version of the circuit. The QT4 is the 8-pin version of the same processor.

Here are some pictures, including the box I made to hold the game:


And here’s a video of the game in action.

The source files uses SDCC for compiling the source kit from C to assembly language. There were a few gotchas that occurred while making the game:

(1) While the SDCC documentation says if you use the __interrupt(N) keyword an appropriate interrupt entry will be entered into the interrupt table of the HC08 processor, I found that for some reason the entry wasn’t added after all. Thus, the interrupts.s file actually provides the correct entries into the interrupt table. If you add a new interrupt, you should then update the interrupts.s file to reflect the new interrupt.

(2) I use stack variables rather than globals; this is because the underlying architecture is interrupt driven. In events.c I use the timer interrupt (configured to interrupt every 1/100th of a second) to poll the keyboard and generate key up/key down events, as well as fire off an event. This architecture is perhaps a little overkill, but it does allow me to respond to very complex logic without worrying if the logic fits in a 1/100th of a second window. Further, this has the advantage that in my GetNextEvent() routine, if there are no events taking place, I can place the processor into a low-power WAIT state, which reduces considerably the amount of power drawn by the device.

The overall advantage of this is that the game runs just fine on a couple of AA batteries. And I expect that, during game play when no lights are turned on, the total draw of the circuit should be on the order of 1.1mA. By contrast, the biggest draw are the LEDs.

I love the interrupt-driven architecture, by the way: if the same architecture were to wait for key strokes using the keyboard interrupt architecture–for example, we were using this chip for a keypad for a combination lock–we could put the processor into STOP mode. Without any external circuits being powered, in STOP mode the QT4 draws 0.36µA of power–meaning it could run in this standby mode on a couple of AAs for nearly 22 months.

The stack-based variables, however, is so I can keep everything straight, since in theory any routine could be re-entrant.

But this means that many of the built-in run-time libraries for the HC08 on SDCC don’t seem to work right. My random number generator deals with the reality that in-line long integer multiply drops to a library call–so it doesn’t work right at all. However, a long-integer shift does work correctly, so I implement the GNU random() number generator algorithm using shifts and adds in C, which then generates the right (non-library calling) routine.

(3) There is no sound. That’s because I didn’t have access to a small speaker. I intend to fix this with a future version when I have some time. When I do this, I’ll probably use the same interrupt loop (slightly tweaked) to drive the speaker to seven different sounds: one for each position, and an “you fail” sound. (One possibility would be to tweak the interrupt timer duration and adjust all the timing of the rest of the game to match. Another would be to up the interrupt timer frequency, and maintain two additional counts: one which indicates if I pull up or down the speaker line, and another which indicates if I should drop into my old 100Hz interrupt routine.)

(4) The animations are perhaps a little over the top. With sound I probably could simplify the startup sequence. I also wonder if I shouldn’t add a seventh ‘start’ button to start the game instead of using the “hit any button to start” method I’m using now.

(5) Why are the lights so strange, with D1 being the lower right LED? Because I got disoriented when I was hooking up the LEDs: my intention was to make D1 the top light, with other lights working clockwise around. Instead, I wired up LED 6 as the lower light, with the other lights working counter-clockwise–meh. It was easier to rework the software than re-glue the lights. I worked the switches in the same order deliberately so I didn’t get confused.

Sure, it’s a silly little gizmo with a handful of lights. But I had fun!

Embedded Software

You know embedded software and embedded microprocessors are everywhere when you find a reference design for an embedded microprocessor system for a vacuum cleaner. They’re using a processor more powerful and faster than the old TRS-80 in order to control the speed of the motor. And why not? The basic design could be reduced to an 8-pin HC08 CPU, a triac, and whatever other components (LEDs, buttons) the designer wants to add for ‘coolness’, such as a “more suction/less suction” button. The total cost of the parts are cheap: the 8-pin CPU is around 84 cents in bulk, and the motor triac is around the same. The most expensive part is the software development and engineering costs, but if you make a single module, you can then just reuse the same module and add or remove LEDs as needed.

What’s really interesting is the idea that you could do different “effects” in software (like revving the motor up and down, or, for a light dimmer, flashing the light) in the same basic component–though I suspect no-one has thought of doing something like having the overhead lamp in your house blink in morse code…