Once upon a time I had a prototype Newton that didn’t boot. The crash was occurring early enough that the screen was not initialized, and the debugger we usually used for low-level problems wasn’t usable. The audio chip was too complex to write to, and in fact there probably wasn’t physical memory available to safely do audio DMA. The serial port was out for some reason (I forget why. Hush now, don’t bug me, this is a story ).
So I wrote some loops of ARM assembly language. The loops didn’t access any memory, didn’t print anything, and they didn’t exit, and didn’t cause any output lines to change. In fact, each of the loops was identical except for their length. I sprinkled them through the boot code and quickly (within about an hour) found the problem (some configuration of stuff in the flash store caused the Newt OS to hurl).
So how did the loops help?
This isn’t a Car Talk puzzler, so I’ll give you the answer right away: Each of the loops had a distinctive sound when I held an AM radio up to the Newton. There was a “high sounding” short loop and a “low sounding” longer one, and by stuffing these into various forks of the boot code I could trace the system’s progress and even shift some data out.
In retrospect I could also have:
- Asked a tech to solder an LED to a spare output line (I’m not sure if we had any, though. Output lines, I mean).
- Clicked the speaker by stuffing data into it (though this might have required setting up DMA and so forth) or maybe just turning its power on an off.
- Gritted my teeth and initialized the serial output on the Newton (this looked hairy to me, and while it probably would have taken longer, it would have given the team a way to debug boot issues later on, sans radio).
As they say: “Any stort in a porm.” I also think that debugging with a radio was pretty cool.