Building a new Altair: hardware debugging, bootstrapping, and success!
One may have seen my earlier article about deciding to build up a 1975-style Altair 8800 from components. I left off saying parts were arriving and I was soldering away. What seems to always happen to me is that I forget something or order the wrong thing, so I end up needing to place another order and wait around for that to arrive…and end up spending a lot more on shipping than one would think. But finally I got everything I needed (except the power switch, which is still back-ordered).
In building this Altair, I created a few problems for myself that an original builder in 1975 wouldn’t have faced. First off, just having a kit with all the right parts and correct number of parts in it would have made it much easier. I kept finding I’d ordered the wrong part (the difference in part number between a 6-pin and 5-pin connector is one character in a 30 character string!) or just forgot something altogether.
But still, I can say that the hobbyists of 1975 had it rough. Building and debugging things involved several tools, all of which I’d collected over the years, but for someone just starting out would represent quite the investment: a soldering station, an oscilloscope, a signal generator, a logic probe, and a multimeter. One could probably get away with just a regular 10 watt soldering iron and a multimeter, but then one needs a little bit of extra luck that all the components are good (I had three bad chips myself)…otherwise one needs to find a friend with an oscilloscope. But come to think of it, maybe that would have been easier in 1975; TV and electronics repair shops and local vocational schools were more common and they had those tools. Still, it did require more support equipment than today’s projects of hooking the right sensors up to a Raspberry Pi; I wonder how many of the original Altair kits ended up just being tossed after their owners gave up on getting them working.
For me, my first challenge came once I’d gotten enough parts to put together the power supply, backplane, and CPU card. I thought I’d hook up my oscilloscope and check the clock signals for the CPU, as its common for the clock circuit to need a bit of tuning. But oh no! I wasn’t getting *any* clock signal. I poured over the schematic, did some research, and learned way more about oscillating circuits than I thought I ever would. At first, I thought I just had a bad crystal, but then I noticed that the line the crystal feeds was showing 5 volts, when the math on the two resistors involved said it should be 1.25 volts (my electrical engineering professor would be so proud). Tracing where the 5 volts was coming from, I identified that one of the integrated circuits was bad and back-feeding on one of its input pins! It took some time to get the replacement IC — fortunately the replacement chip solved the problem and my CPU started up!
Next, while looking over the schematic for the memory card I was building, I noticed the bus line the front panel uses to instruct a memory write wasn’t even connected. Uh oh!
This comes down to a bit of a silly decision on MITS (the builder of the Altair)’s part. The Altair actually has two bus lines for writing memory: the one used by the CPU and the one used by the front panel. The original memory cards just OR’d the two signals together for the ‘write enable’ pin on the memory chips. As front panels fell out of use as soon as boot ROMs became common, later memory card designs (including the one I was building) simply ignore the front panel bus line. But since I did want to use the front panel, I’d have to modify the logic on the memory card to accommodate.
Fortunately the memory card design had one spare OR gate and another one used for driving a LED that I could live without, so I bent up some pins on a few chips and soldered some bodge wires to recreate the same OR logic as on the original Altair cards. See this post for more details on my modifications.
So, I finally had the processor card working, the memory card working, and the front panel working. Conceptually at this point I had a Turing-complete finite state machine, aka a computer. It was time for the big test! I used the front panel to store a few bytes into memory, then examined those addresses to see if they were the same. Success! The next step was to put in a very simple program:
org 0
start mvi a,0
jmp startThis compiles to only 5 bytes to enter via the front panel, and just loops over and over. But it proved the CPU could read from memory and execute instructions!
Next, I entered two programs that only require the front panel. The first was ‘Kill the Bit’ (a simple game using the front panel lights and switches). Fun! The next was something I’ve wanted to do for years. There is a semi-famous (in geek circles anyway) anecdote of Steven Dompier presenting a program at the 3rd meeting of the Homebrew Computer Club (the same club where Jobs & Wozniak first presented the Apple 1) of a program using the Altair’s switching noise that could be picked up as music on an AM radio player. The 1996 documentary “Triumph of the Nerds” mentions it at one point. A while back I had run across Dompier’s article about it on archive.org (see page 8), and I had to try it. It took a few minutes to key in, and I had to put the AM radio right next to the Altair to pick it up, but was soon able to get a small taste of that night in 1975. Magic.
So I had a working computer, with switches for input, and LEDs and radio interference for output. If thats all the Altair ever did, it probably would have been a footnote in history. But a few things happened: other manufacturers started to clone the Altair so it became a defacto standard…and a new company called Micro-Soft released an interpreter for Basic, allowing the Altair to be programmed using a simple high-level language over a serial connection. My next goal was to load Basic 1.0 onto the Altair.
Back in the day it was common to use a teletype or video terminal like an ADM-3, but I could just use a terminal emulator from a modern computer. But first I needed to make sure the serial card I built was working. To test it, I wrote another simple program:
org 0start
in 0AAh ' check status register
ani 080h ' ignore everything but the byte ready bit
jnz start ' loop if that bit is not 0
in 0ACh ' input byte
out 0ACh ' write same byte back out
jmp start ' loop to beginning
This checks to see if a byte is available (looping until one is), then reads from the serial port (configured via dip switch on my serial card to be at address 0xAC), writes whatever it received right back out to the serial port, then loops. This way, I was able to confirm the serial card was working in both directions. But I noticed something odd. This code would echo back whatever I typed in just fine…but when I tried sending a file, bytes would be dropped. Basically, when I sent things fast enough, some of those bytes would be lost. Sending “I am a test” would result in something like “amatst.”
I eventually hooked up an oscilloscope, and found this dirty signal coming into the ‘read’ pin of the USB module:
That extra spike was just enough to trigger the module to send a second byte from the module’s buffer, losing data. I traced this dirty signal back to a 74LS244 chip that was somehow picking up a stray signal. Replacing that chip fixed the problem…and with that, my machine now had a decent input/output capability.
At this point, I’d probably coded a few kilobytes of data into the front panel while testing and debugging everything. While the ability to inspect individual bytes and step through individual instructions is certainly very nice, toggling large programs into memory manually gets very old very quickly. As such, I next needed to visit bootloading for the Altair in order to load longer programs.
A bootloader is just a bit of code that loads more code. The saying comes from the phrase “pull yourself up by your bootstraps” and directly led to the modern terminology of “booting-up” or “reboot.”
The original bootloader for Altair Basic— written on the airplane by Paul Allen while on the way to meet with MITS to pitch the product — was very simple. It just loaded from the serial device (originally a paper tape reader) into memory starting at address 0, looping while data was being read. When the tape ran out, the bootloader went into a loop waiting for more data that never came, so it was up to the user to stop execution of the bootloader manually, and then restart execution at the loaded location.
I had to modify the bootloader code and basic code to use my serial card’s addresses and status bits instead of the original Altair SIO card. This was a common activity needed back in the day as well with a variety of hardware manufacturers selling slightly different competing products.
So time for the big test: I hooked my laptop (running Linux) up to the Altair’s serial card and keyed the 20 bytes of the bootloader into the front panel. Then I dumped the tape file to the serial device and started the terminal software:
cat basic1.0-usb.tap > /dev/ttyUSB0
miniterm /dev/ttyUSB0This is the modern equivalent of running the paper tape reader and then hooking up a teletype or video terminal.
I waited a second for the Altair to load everything from the serial buffer. Holding my breath, I reset the Altair and toggled the switch for ‘run.’
And here is what I got back (along with my first test):
Words cannot describe how excited I was. I’d done it. I soldered a working computer together component by component, and got a working machine out of it, complete with a high level interpreter for easy programming.
Even if I wasn’t around to invent the future with folks in the Homebrew Computer Club in 1975, I like to think that maybe, just maybe, I would have fit in at one of their meetings, and maybe even been invited to tag along to the bar afterwards.
In my next writeup, I’ll discuss getting CPM (the original home PC operating system) running on the Altair…without the help of a floppy drive.
Next story here.
