Steve Wozniak's floating point routines for the 6502

For some people risk isn't something to be avoided at all costs. It's a challenge to overcome. It's the same principal when you watch an amazing ski jump, musician, or gymnastics routine--taming the chaos.

This is a fundamental drive in many people that calls on something innate.

Except for the Woz

Floating point can be tricky.

I competed in the first couple years of Sparkfun's autonomous vehicle competition. My robot had a keypad where you could enter GPS coordinates for waypoints. The microcontroller I was using had 32-bit soft floating point routines in its standard library, but I had to code my own string-to-float routine. (I think only float-to-string was provided, but not the inverse.)

Every year, the robot worked in Oklahoma but in Colorado would make a wild turn and head the wrong way. The morning of the last time I competed I realized the problem was in my string to floating point conversion code. I had made a programming assumption which was mathematically incorrect. It happened to work in Oklahoma because the fractional part of the GPS coordinates at home were in a range that didn't trigger the bug.

I also realized it meant the conversion algorithm was more subtle than I had assumed, and there was no way I was going to be able to figure out the correct algorithm in the field, under time pressure. In those years I either didn't yet have a smartphone, or I looked and couldn't find code on the web for my microcontroller.

(And I couldn't just drop in some C code - it was a Parallax Propeller and my robot's code was in the Spin language. Quirks of the chip made it unusually hard to port C to it and so C compilers for the Propeller were still what I would consider "experiemental" - or were when I started the project.)

The incorrect floating point code had been one of the first things I'd written - it'd been responsible for my robot crashing every year, including that morning. (I'd blamed hardware, upgraded the GPS unit, improved sensors, etc.)

One year later to the day, this was all on my mind again because I couldn't make it to the competition that year, and I had a shower thought. I had had a KNOWN GOOD floating point conversion routine on my hard drive and running inside my microcontroller that whole time!! I was using a Propeller GPS library. GPS data comes in NEMA strings which are... strings! By necessity, there was a private routine in the GPS object which had to be doing the conversion. I went and looked - yes, all I would have had to do was change this private routine to "public" and I could have called it.

Keyboard interaction on the Apple II is entirely CPU-dependent, memory-mapped, and works like this: when a key is pressed, the ASCII code of the character is put at $C000, with the high bit set (a consequence of this is that there is no way for the computer to know that you pushed the shift key, for instance, or to tell the difference between typing Return or typing Control-M). Your program is responsible for checking $C000 from time to time. When the high bit is set, you read the character and access memory location $C010, which clears the $C000 high bit. Interrupts are not used at all, despite the 6502 supporting them, probably because disk and cassette IO is similarly done under CPU control with tight timing tolerances, and getting an interrupt in the middle of writing data would wreak havoc.

Details on page 16 of http://www.classiccmp.org/cini/pdf/Apple/Apple%20II%20Refere...

An exception is the "Reset" key which is hard-wired to the reset pin of the 6502. On early Apple II models, pushing "Reset", which is located just above Return, had disastrous consequences. People used to put a washer under the Reset key to make it harder to push by accident. Magazines published a simple hardware mod that required Control to be held at the same time as Reset, and later versions of the Apple II came with the mod built-in.

The Apple IIe keyboard adds two "apple" keys on both sides of the space bar which are dealt with in a completely different way, and are mapped to the same locations as the two joystick/paddle buttons. This was useful for playing games which required repetitive button-mashing, as it is easier to type a key quickly than to push a joystick button quickly. Since I was used to controlling the joystick with one hand and pushing a key on the keyboard with another hand, I had no problem adapting to early Macintosh software that required shift-click, option-click and command-click to overcome the limitation of a one-button mouse.

"The Macintosh mouse has four buttons, it's just that three of them are on the keyboard."