Hardware Serial console setup

Real hardware: serial console

This page owns: how to see anything at all on a machine that boots to a blank screen.

Status: written from the machine's documentation and from how the emulated port behaves. Nobody has connected a cable to a real Network Server for this project.

The serial console is the first thing to get working on real hardware, before any NT question. Without it you are debugging a machine that cannot talk to you.

---

Why serial, and not the monitor

On this machine the monitor is not a console until something programs the video chip, and for most of the boot nothing has:

• Open Firmware leaves its console on the serial port and never programs the video.
• The veneer and OSLOADER.EXE print to whatever ARC's CONSOLEOUT names — which is multi(0)serial(0)line(0).
• The HAL can draw on the monitor, but only from phase 1, once it has mapped the framebuffer.

So everything interesting — the firmware prompt, the veneer's tracing, the loader's errors, the HAL's phase 0 output — happens on the serial port.

Essentially every trace on this project came out of it.

---

Which port

The ESCC (Zilog Z8530) in Grand Central, channel A — ttya, the modem port. That is what Open Firmware uses by default and what ARC's CONSOLEIN/CONSOLEOUT name.

Apple's serial ports of this era are mini-DIN-8, and they are RS-422 rather than RS-232 — which in practice works with an ordinary RS-232 adapter for these purposes, but is worth knowing if signals behave oddly.

You will need a Mac mini-DIN-8 serial cable and a USB serial adapter, or a machine with a real serial port.

---

Settings

Open Firmware's default on this generation is 38400 8N1, no flow control. If output is garbage, try 9600 — and confirm by whether the shape of the output looks like text at the wrong rate rather than noise.

The firmware's own ttya-mode setting is authoritative and can be read at the prompt.

---

What you should see, in order

A rough map of a successful boot, so you know which stage you have reached:

Stage	What appears
Power on	firmware banner, then 0 > if it stops
little-endian? true + reboot	the banner again; MSR reads 0x1B071
Loading the veneer	nothing, unless tracing is on
go	the veneer's own output, if VrDebug is set
OSLOADER.EXE	OS Loader V4.00
The HAL	HAL: halshinr … (phase 0)
The kernel	Microsoft (R) Windows NT (TM) Version 4.0 …

Reaching the firmware prompt and typing at it is already a significant result, and step 2 — little-endian mode — is the first thing that could genuinely fail.

---

Turning on the tracing

Two sources of detail, both of which have earned their keep:

The veneer's VrDebug — a word in its image. 0x2000 prints the argv handed to the loader; 0x1000 traces every read and seek. → Reference: VrDebug bitmask

The HAL's own output, which is unconditional and extensive: the ARC tree, the memory descriptors, every bus access, the module list, every interrupt. On a real machine that log is the debugger.

---

A caution about the prompt

Typing at Open Firmware is how several questions on this project were settled, and it is equally useful on metal. Two practical notes carried over from doing a lot of it:

• The input path drops characters when fed faster than the firmware reads them. Long lines lose their head, silently, producing errors about words that are half a word. Type, or paste, in small chunks.
• dump on unclaimed memory throws DEFAULT CATCH!. Use alloc-mem for a buffer.

→ Open Firmware §6

---

Next

• What is known and unknown — steps 1 to 3 start here.
• Risks
• Open Firmware