The Origin 200's First Firmware Prompt

On the evening of 2026-08-12 the emulator ran SGI’s own Origin firmware, a PROM image built in April 1998, and the firmware printed its banner, dropped into its diagnostic monitor, and answered typed commands. Within the hour I used that prompt as a debugging instrument and closed a question the project had carried for days.

What the machine printed

The transcript is committed as docs/boot-logs/firmware.boot.2026-08-12T22:22-07:00. The firmware identifies itself:

IP27 PROM SGI Version 6.11  built 03:19:48 PM Apr 29, 1998

Before that line it does a few things I find interesting. It reports that it cannot reach the machine’s debug switches and settles them to zero, which is the condition every boot this project has ever reasoned about was taken under, fixed by a failure rather than chosen. It runs its own I/O bridge sanity check, prints eight expected-versus-received register mismatches, and then deliberately provokes an address error to test the bridge’s error detection, which shows up as an exception the firmware takes on purpose and recovers from.

Then it drops into its monitor and waits:

0A 000: *** General Exception on node 0
0A 000: *** EPC: 0xc00000001fc2357c
0A 000: *** Press ENTER to continue.
0A 000: POD Junk Dex>

That prompt was typed at. ? returned the monitor’s full command list, some 140 commands, counted off the transcript, across calculator, register, memory, cache, network, environment, error-register and I/O-diagnostic groups. why returned the fault state:

 Cause  : 0x000000000000801c (INT:8------- <Data Bus Err>)
 BusAdr : 0x9600000004000018
 Reason : 242 (Unexpected General Exception.)

BusAdr is the payoff. That address had been the subject of an open investigation. Asked to load it, the machine faulted again, and the new exception’s program counter was the monitor’s own load routine rather than the routine that first met the address. That distinction is what turned a repetition into evidence: the fault belongs to the address, not to the memory-sizing code that happened to touch it, which removes that code from the question. The address sits in a gap between two of the four memory slots the trunk maps, and is backed on the branch that maps one contiguous run. A days-old fault was closed by one command to the firmware’s own decoder.

That is what an interactive prompt on the vendor’s firmware is for. Everything before it was inference from outside the machine.

Why the firmware had been silent

The firmware had been reaching its diagnostic monitor for some time without printing anything, and the reason is that a monitor with no console writes to nothing.

SGI’s power-on diagnostics manual documents the firmware’s console search, and I had read it closely enough to find that the manual disagrees with itself. One table lists three console types with the order they are checked and an LED pattern for two of them. A different table, describing the prompt’s own format, lists four values for the field naming the console currently displaying the prompt, including one absent from the first table entirely: a junk-bus UART.

My machine’s captured LED pattern matched neither of the two documented patterns. The best-supported reading at the time, and marked as an inference throughout the document that made it, was that the firmware had selected a console that is not a physical serial port at all, which would explain a machine reaching a prompt and writing nowhere.

The prompt the firmware eventually printed names its own console, and it reads Junk. The monitor’s command list confirms what the name means, offering ioc3, junk, elsc and talk as ways to move the console between the I/O controller’s UART, the junk-bus UART, the system controller’s port and another node.

The inference is not refuted by that, and saying so matters. It described a machine with no junk-bus UART fitted. Fitting one changed the machine, so the two observations are of different configurations and the later one cannot settle the earlier. What the boot does establish is narrower and still worth having: with that port present, the firmware finds it, selects it and talks.