Hardware Risks

Real hardware: risks

This page owns: what can go wrong on metal that cannot go wrong under an emulator.

Under the emulator, everything is reversible. A checkpoint restores, a delta is thrown away, a bad poke costs fifteen minutes. None of that is true on a real machine, and the habits built in an emulator are exactly the wrong ones to bring to one.

This page is short and it is not exhaustive.

---

Writing to a real disk

NT's Setup partitions and formats. The tools here write partition tables and filesystem structures directly. Both are destructive and neither asks twice.

• Use a scratch disk. These machines take ordinary SCSI drives; use one you do not care about.
• Physically disconnect anything you do care about. The most reliable safeguard against a misidentified target is for the target not to be present.
• Remember that a Network Server may have several drives in hot-swap bays, and that ARC paths number devices by their position on the bus — which is not necessarily the order printed on the chassis.

NVRAM and PRAM

The boot experiments here set firmware variables — little-endian? true above all. That setting persists across a reboot, which is the point of it, and a machine left in little-endian mode will not boot the Mac OS or AIX normally.

Know how to get back before you start:

• Open Firmware's own set-defaults and a reset,
• the standard PRAM reset for the generation,
• or, on this machine, the front-panel keyswitch and the documented reset procedure.

None of this is likely to damage anything permanently. All of it is likely to be alarming at 2am if you have not read it first.

A machine that will not boot

The realistic bad outcome is not a damaged machine — it is one that sits with a blank screen and no explanation.

This is the argument for the serial console being the first thing you get working. Without it a failed experiment is indistinguishable from a broken machine. → Serial console

Media

The CD this project patches is your disc image, and a patched image has to be burned to be used. Nothing about that damages the original, but be clear which is which — the tools here deliberately never modify your ISO in place, and that discipline is worth keeping.

Hardware that is thirty years old

Not a software risk, but the dominant practical one: capacitors, PRAM batteries, drives and power supplies of this age fail. A machine that misbehaves is far more likely to be tired than to be exhibiting a HAL bug, and it is worth establishing that it runs its original operating system before concluding anything about NT.

---

What this project does not promise

Plainly: nothing here has ever been run on real hardware. The HAL may not load, the firmware may behave differently, the interrupt routing may be wrong, and the failure modes are unknown because nobody has seen them.

Anyone trying this is doing original work, with the risks that implies — and the results would be genuinely valuable to the project either way. → Contributing

---

Next

• What is known and unknown
• What would have to change