Dead Newt

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.

This entry was posted in Rantage. Bookmark the permalink.

10 Responses to Dead Newt

  1. Joe Mahoney says:

    I think that’s the single greatest debugging technique I’ve ever heard of.

  2. Anon says:

    That’s a great story! Gave me quite a chuckle. I can honestly say I would never have thought of that :)

  3. Atanas Boev says:

    Wow:) Respect!

  4. I remember in 1996 when my roommate had a Linux box. With the sound card gain turned all the way up and no sound playing through it, I could hear:

    - clicks when the mouse moved or keyboard events happened;
    - silence when the CPU was idle;
    - a weird screech when top(1) was polling the system in order to processes right before displaying them;
    - alternating between two different sounds a few times a second when the system was time-slicing between two different CPU-heavy processes.

    It’s probably worth pointing at the story of “Fool on the Hill” on an Altair at the Homebrew Computer Club: http://www.startupgallery.org/gallery/story.php?ii=46

  5. MiaM says:

    Oh, i remember that on my VIC-20 the background colour got a kind of blueish shape if the 6502 had crashed on one of those illegal op codes that hung the 6502…

  6. Justin says:

    About 8 years ago my life involved flying around doing testing of new switches, technologies, etc in affected markets with T-Mobile. This was before we implemented remote automated testing, so it took 2 people 3 days of making test calls nonstop for 8 hours a day. My team set up the standardized call testing that had to be done before a new market launched, or a new switching software was deployed, or whatever reason we were there for.

    Most people don’t realize how many different ways you can dial a single local phone number (7 digit, 10 digit, 11 digit, +1 then 10 digit, 011 then 11 digit). Throw in testing mobile to mobile, mobile to local landline, mobile to long distance landline, etc and all of the combinations of the above, and it adds up quickly. Toss in testing of missed call scenerios, call features, etc and you have yourself a well paid trained monkey. Most of the fun work happened back at the office, but the air miles and hotel points paid for both my wife’s engagement ring and our honeymoon, so I was a happy monkey.

    Anyways, I became able to distinguish between call failure reasons by the subtle split second pause between rings, slightly different ring recording, different white noise in the background, etc that still stands out to this day. Hard to not notice these patterns to this day.

    My favorite diagnostic tool was also a portable radio. The cell phone gallop that you hear tells a lot about call progression.

    Sometimes we overlok the simple (but not mainstream) solutions to things… like a built-in wireless diagnostic tool.

    However, I do think you should have used the high-low as the short-long of morse code. The translator code on the computer side to translate ascii to morse code would be simple… it’s the necessary fluency in receptive morse code that presents the biggest problem :)

  7. Pingback: asmw.de » I AM flabbergasted

  8. Gray Gaffer says:

    Ah, a real oldie resurrected! I started out in computers in 1967, at a company named Elliott Automation in the UK. I worked on their 4100 series machines. One of the standard peripherals was a loudspeaker hooked in to two of the microcode decode lines. At least, it was standard on the commissioning floor where it was my job to find and fix dead transistors or mis-wires (tens of thousands of transistors – no chips then! – all hand wired together). We had a test program that walked through the logic, and after some time one became able to tell from the speaker sound which board was failing, after a bit more time which transistor. One guy with way too much time on his hands wrote a program that sang Daisy (test for the reader – why Daisy?).

    The other debugging aid from those days that has gone away are the blinkenlichten – blinking lights – so favored by 50′s era Hollywood. Basically, the states of every bit in every register were represented on the control panel, which included switches for changing their state and for single-stepping the entire machine at human speed instead of clock speed. Every computer I built after that sported both. Which lasted until I had to stop building them myself because the chips overtook me.

  9. Paul R. Potts says:

    Back in the day (circa 1978 or so) when I was 11 years old, I used to use this technique on my TRS-80 Model 1. Deliberately using different kinds of loops: no, but using a radio to determine what kind of lockup my machine code had gotten itself into. I was trying to write Life in assembly. I can’t remember if that was TMON or EDASM.

    I never did get that program to work at all, so it was back to BASIC for a Dungeons and Dragons character generators and a voting system that wrote votes to cassette. But I remember that RF noise. My stepfather, who used to love to listen to classical music on FM, was always pissed when I used the computer.

  10. frymaster says:

    just come across this – I grew up in 80s Britain, and had an amstrad CPC. When hacking away with its built-in BASIC interpreter, I realised I could “hear” delay looks (for a=1 to 1000; next – iirc that was around a second) as a high-pitched whine that, near the end of the loop, became a slightly lower-pitched high-pitched whine.

    For some reason, no matter how long the loop, the two pitches were the same

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>