Halt and Catch Fire!
Or: How a Sphere computer goes out to lunch
The phrase “Halt and Catch Fire” is the name of a slick television drama about the birth of the personal computer industry. It is also a visible failure mode on the Sphere microcomputer!
This wonderfully evocative phrase originates in the big-iron mainframe computer era, where it began life as a nerdy in-joke. But in the late ’70s, “halt and catch fire” was the name associated with a real, undocumented behavior of the Motorola 6800 microprocessor. And that is the Halt and Catch Fire we are going to talk about today, and how you can witness it happening on a Sphere computer’s video screen.
Heads-up: this is a fairly technical post, but I’ll try to make it at least legible for all interested readers!
The term comes from the 1960s, taken from lists of “humorous” computer machine instructions, the sort of thing that was passed around and republished in newsletters and tacked up to office bulletin boards. The first instance of Halt and Catch Fire, specifically, seems lost to history, but it was a joke, like ha-ha what if a computer could be programmed to catch on fire! Halt and Catch Fire was abbreviated in a mnemonic form, HCF. It was usually in the company of other groaners, like EPI (Execute Programmer Immediately) or BLI (Branch and Loop Indefinite).
After Motorola’s 6800 8-bit microprocessor reached the market in 1974, programmers eventually discovered undocumented behaviors in the chip. Each instruction for this microprocessor occupies one byte, meaning there are 256 possible instruction opcodes. For example, “clear the A accumulator to zero” is instruction 79 (aka $4F). But of the possible opcode values, fewer than 200 are actually used. When the chip encounters one of the other, invalid “instructions,” there is no hardware logic that will match to it. Unlike later microprocessor designs, there is also no logic to identify it as invalid and “trap” it. Instead, the invalid opcode’s bits will plinko through the chip’s 4,000 transistors anyway, causing happenstance side effects. In most cases these “undecoded” bytes ultimately have no effect, but there are some exceptions.
Gerry Wheeler documented all the different behaviors of the 6800 he could find in a 1977 article for BYTE. “Now for the big surprise,” he wrote, before detailing the most interesting ones: two non-instructions—$9D and $DD— had the same wild result: when the CPU encounters one of these codes it enters irretrievably into a mode that ignores all normal control signals, and at the same time starts running up the system the address bus as an incrementing counter, blindly probing every address in the 64 kilobyte address space over and over, ad infinitum.
Wheeler dubbed these two instructions Halt and Catch Fire—in honor of the old mainframe joke—because the CPU was indeed halted (i.e. had stopped executing instructions) and the rapid, nonstop address blasts seemed fancifully like “catching fire.” The only way to rescue a 6800 from this weird abyss is by doing an electrical reset on the chip— or cutting power off entirely.
Wheeler’s article says that “when this instruction is run the only way to see what it is doing is with an oscilloscope.” He means that this peculiar state should have no visible effect to the user. The computer would hang but you’d have to observe the system address signals to see the counting behavior. For nearly all systems, he’s right: the HCF is otherwise indistinguishable from any infinite loop in the code.
But not so for the Sphere! The Sphere was the first commercially available full microcomputer built around the 6800 chip, and because of a quirk (some might say “design flaw”) in its architecture, a Halt and Catch Fire mode produces a distinctive artifact on the video display. It looks like rolling static bursts on the screen, like this:
How could this possibly be? After all, the “catch fire” address counting reads all of the system addresses in order, but it only reads– it will not corrupt existing memory anywhere and in general the read operation shouldn’t have meaningful side effects on anything in the system. It certainly shouldn’t disrupt the operation of an video signal circuit!
The Sphere uses memory-mapped video. The “CRT/1” board, which accompanied nearly all Sphere systems, contains 512 bytes of static RAM representing each of the screen’s 32x16 text display characters. The video module can be thought of as two distinct circuits operating independently of each other, but sharing the video RAM memory between them: First, the video display circuitry is constantly reading out the current contents of the video memory and turning the characters into dots for the video output, over and over again. Secondly, on the other side, the CPU writes to (and reads from) video memory just like any other memory in the system. Updates to the characters in the screen RAM will be immediately reflected on the user’s display.
This means competition for the screen memory. Instead of brokering access between both side of the circuit, the hardware allows a tug-of-war to happen. Normally, the data from the screen characters is suctioned in by the video display, but anytime the CPU (program) is writing to—or even reading from!—screen memory, the CPU traffic will briefly override the normal video data. This unexpected data ends up generating random garbage dots, which appear as brief specks on the screen. By the subsequent screen redraw, the random data is gone (or is different) so the specks don’t persist. What the user sees is sparkling static, or “snow.”
None of this is related to the Halt and Catch Fire behavior specifically. In fact, the little flecks travel around the screen pretty much all the time when using a Sphere, and this was a matter of great annoyance to customers. Any time the CPU accesses video memory, some amount of the disruption happens—even when only reading from the memory. A blank screen with a slowly blinking cursor will show little blips, and scrolling a full screen of text is accompanied by a blizzard of static.
Now that we know that simply reading from screen memory can cause visible artifacts, we can get back to HCF. Recall how the side effect of the Motorola HCF hang is to count up all the addresses in the system, reading from each? During each sweep through the entire 64K address range, the 512 addresses of screen memory will experience a brief top-to-bottom scan. During this time interval—lasting about 768 microseconds— the video display circuit will render continuous garbage. That time interval works out to about 12 screen lines’ worth of detritus, after which data re-stabilizes to the actual characters. And that’s the height of the “static bar” we see on the screen: it’s about 12 consecutive scan lines of random dots on the CRT raster.1
As to why it seems to be one static bar “rolling”, well, that’s a classic optical illusion. Each burst of random dots exists by itself. But the halted CPU keeps firing at the memory map. Like a madman’s lighthouse, the sweep passes through the video memory about 10 times every second. At 30 frames per second, we might see a bar of junk every third video redraw or so. The timing works out such that the “bar” appears to be animated.2
This design quirk is a helpful diagnostic tool! It can be hard to debug a program hang. But if you see the HCF junk on the screen, you have a clue: the CPU ended up executing unexpected data as instructions, which means your program counter ended up somewhere you didn’t expect. It could be a bug in your code, or an interrupt triggered with no handler, or a subroutine returning to a bad address. But in all cases, you know that it’s not “just” an infinite loop.
The Motorola 6800’s Halt and Catch Fire mode has often been described as a sort of secret, intentional self-test mode. This was not the case, according to Bill Mensch, one of the designers of Motorola’s M6800 family—it really was an accident of the undecoded instructions’ bits. Yet just a few years later, during revisions to the chip design, product engineers asked for a scanning memory-test mode for RAM validation. The Motorola design team, recognizing that the pesky HCF behavior was exactly what was called for, simply left the circuitry in place, and blessed it as an official built-in self-test.
The AMC television company plucked the forgotten phrase “Halt and Catch Fire” from the flotsam of computer history, and hoisted it up to be the title for their 2014 series about the early microcomputer era. It was a good show! The vibes are immaculate, the soundtrack rules, and the title is certainly a more romantic, evocative use of the phrase than anything in actual computing. But the Motorola 6800 was the first real processor—and perhaps thus the Sphere was the first full microcomputer—that made that namesake mode real.
Sources:
Gerry Wheeler: “Undocumented M6800 Instructions,” in Byte, Vol 2 № 12, December 1977.
R. G. Daniels and W. C. Bruce: “Built-In Self-Test Trends in Motorola Microprocessors” in IEEE Design & Test of Computers Vol 2 № 2, April 1985. (Thanks Stan!)
Sphere CRT/1A module circuit schematic is linked here. (The video memory and access lines are shown on the last page of the PDF.)
Author correspondence with Bill Mensch.
Watch AMC’s Halt and Catch Fire here!
Footnotes:
1 The 6800 will increment the address lines on each CPU cycle. The Sphere cycle time is about 1.5 microseconds and there are 512 video memory addresses. So it takes 512 x 1.5μS = 768 μS to blast through the video memory range. NTSC video scans at about 15,750 lines per second: about 64μS per scan line on the screen. Dividing 768μs by 64μs per scan line gives us about 12 scan lines.
2 At 1.5μS per address, it takes 98,304μS (or 98.3ms) to count up through the entire 64K system address range before starting over again. That means we will see a burst of video trash about 10 times a second as it goes through the video memory. The NTSC signal is sometimes in its vertical blanking interval, so we won’t see all of the bursts.
This newsletter is part of a series of offcuts and addenda to my upcoming book about the Sphere computer and company in the context of the early microcomputer industry. Book preorders are coming soon. If you think this post was interesting, feel free to share by email or by link (below). If you were forwarded this email, please sign up for more!
If you want to play around with an emulated Sphere on the web (sans video glitches, for better or worse), you can do that here.
You can always reach me at bzotto@gmail.com. The main site for this project is at https://sphere.computer. All text is copyrighted by Ben Zotto.
Thanks —Ben Z