74 comments
David Wheeler (of subroutine fame) figured out the most sensible thing to put in the tiny ROM was a paper tape loader and mini-assembler that loaded the rest of itself from paper tape. So at switch-on the machine would start reading the tape input and run. Programs could be written on the teletype with mnemonics and relative addresses in octal.
It seems a little strange that more advanced later machines like the original PDP-11 from 1970, couldn't "autostart" from ROM like that. You had to toggle in a bootloader.
I think that was because core memory was non-volatile. (EDSAC didn't use core; it had a refreshing DRAM-like delay line memory.) With core, you only had to toggle the bootloader into once and, provided your software didn't accidentally overwrite it, it was still there after a power cycle. So re-toggling in the boot loader was not really that common, despite how much lore surrounds it.
Later cards used PROMs, and were pretty fancy. The M9312 had 512 words and included some basic CPU diagnostics. Different variants handled boot from disk, paper tape, console, etc, and you had to specify the options you wanted when you bought the card.
Having said that the bootstrap was something like 8 16-bit instructions, a pain but not impossible
Bootstrap was a small set of octal instructions on a piece of paper stuck to the front panel.
That was enough to load the "absolute loader" from paper tape on one of the ASR-33s, which then loaded blocks of BASIC from paper tape.
It was a "multi-user" BASIC that dropped string functions (except CHR$()) in exchange for allowing 3 users.
Scott Swazey gave a great talk at VCF West 2024 about restoring a GT40 and getting Lunar Lander running on it again, and it touches on everything in this thread: core memory, bootloaders, front panel single stepping, light pens, and retyping lost ROMs from listings.
https://www.youtube.com/watch?v=G6h6r6MGWyI
Your point about core surviving power cycles is part of the game (19:44): "because the game has core memory which is nonvolatile, so when I turn off the machine it saves everything, all of the carcasses from the crash landers of all the failed attempts are scattered across the screen. And interestingly enough, if you leave the game running long enough the game will crash, because there's no more memory left for any more carcasses."
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1184s
It was also arguably the first Easter egg, in 1973 (20:17). Land next to the McDonald's and the astronaut walks over and says "I'll take two cheeseburgers and a Big Mac to go." At a show he crashed into it instead and got "You have destroyed the only McDonald's on the moon", and since core remembers everything, nobody else could find it after that (21:13).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1273s
The GT40 came up in a bootloader and pulled programs down the serial line, so no toggling, but debugging it was pure front panel. Hitting line feed crashed the PDP-11, so he single-stepped through the bootloader with a diagnostic card, down to a byte compare of the high byte, which goes through a shift, and found a dead 74194 4-bit shifter (15:50).
A PROM on one of the boards had failed, and no binary of it survived anywhere, so they typed its 256 entries back in from the listings (13:46). His rule number one is "don't trust anybody": he double-checked his friend's careful transcription and found two transposed digits that "would have created a bug so subtle that it would have taken us months to find it" (14:31). The same rule caught the downloaded diagnostics, which had a stray "!" and a newline inserted that made the loader abort (17:15). And on Bitsavers: "we could not have restored it without it" (13:10).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=826s
Other highlights: Atari's 1979 Lunar Lander turns out to be a direct copy of the GT40's vector generator, binary rate multipliers and all, with a 6502, ROM and static RAM swapped in for the PDP-11 and its expensive core (5:11). At VCF Midwest the wall power sagged to 90 volts, so he ran it off his camping battery (23:39). And he showed it next to the PDP-11/45 that animated the Death Star trench briefing in Star Wars, with a dueling light pen battle between the two (24:46).
I've been doing the same kind of thing without the soldering iron: bringing Heinz Lemke's 1972 PIXIE/SYMELEC light pen system for the PDP-7 and Type 340 back to life in a browser emulator, from a scanned listing, since no tape survives. Then DEC's own 1964 370 Light Pen Diagnostic, transcribed from a scan that skips from page 5 to page 7, so page 6 had to be rebuilt from how the surviving pages use each of its symbols.
Scott's rule number one turned out to be mine too. Every bug falls into one of three kinds: ours (the emulator got it wrong), the transcription's (the listing was misread off the scan), and 1972's (the listing itself is wrong, and the emulator should faithfully reproduce the mistake). The first one was a truncated literal pool. The conversion stopped at word 11741, so every (JMP INT literal read as 0, and the machine initialized itself into a wall. So far, every bug had its answer on paper before anyone went looking. The emulator's job is to run the listing until it disagrees with itself, and then to show where.
Bug Journal:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
370 Light Pen Diagnostic (DEC-4-45-M, 7-78-M):
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
1972 PIXIE PDP-7 Assembler Listings:
https://github.com/SimHacker/WillWrightShowForFood/tree/main...
In 1972 the PDP-7 was the small one. It hung off Cambridge's Titan (an Atlas 2 that filled a room and ran the university) as a satellite, phoning home over Neil Wiseman's custom link to store and retrieve drawings in the Titan filestore.
The emulator inverts that: tiny-titan is the whole of Titan, as much of it as PIXIE ever saw, in one TypeScript file, serving its emulated satellite from inside a browser tab. It implements only what the one surviving caller ever dialed, and SYMELEC's unmodified link code runs against it.
Tiny Titan:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
tiny-titan.ts:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
PIXIE Live in PDP-7 Emulator with 340 Vector Display Simulator:
https://hyperties.org/databases/pixie/pixie-live/
Press the "DEMO" button and it will make a goofy child's drawing with the virtual light pen. I plan to ask Claude to make a new demo by trying to draw a pelican riding a bicycle.
Enable the MEMORY panel's "SOURCE" + "FOLLOW PC" mode, then slow the emulator down with the slider, to see the PDP-7 assembly source code it's executing (from the OCR of the scan of 128 pages of line printer output).
You can also pick "LIGHT PEN TEST (1964)" from the menu and press "DEMO", or pick "DUEL (1968)" and play spacewar for two, DECUS 7-40, loaded from paper tape through the RIM loader, the PDP-7's version of your bootstrap.
And I made a non-graphical "HILO (2026)" number guessing game and a "LUNAR LANDER (2026)" game to test out the TTY simulator. The lander is in the spirit of the turn-based original Scott describes (1:52), before the GT40 made it real time: "YOU ARE 500 FEET UP, FALLING AT 50 FT/S, WITH 60 UNITS OF FUEL."
Lander README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
lander.s:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
PDP-7 Unix is coming soon. Warren Toomey, Phil Budne, Tom Everett, Sebastian Rasmussen, Robert Swierczek and friends did this kind of restoration on a much bigger scale with the pdp7-unix project. Starting in 2016 they typed in Ken Thompson's 1969-70 PDP-7 Unix from Norman Wilson's scans of the only surviving printouts, wrote a cross-assembler (as7) and a user-mode simulator, and got the kernel booting to a shell with a working filesystem.
In 2019 a second notebook of missing sources turned up and was scanned and typed in too, and in January 2020 it ran on a real PDP-7 at the Living Computer Museum. It even has moo, the bulls-and-cows number guessing game, a 1970 cousin of my HILO.
PDP-7 Unix:
https://github.com/DoctorWkt/pdp7-unix
Recovered Unix documents:
http://www.tuhs.org/Archive/Distributions/Research/McIlroy_v...
Their as7 was the precedent for my own assembler, which can run in the browser and produce symbol tables and source maps, the way a TypeScript to JavaScript compiler does. That's what drives the Memory panel's Source + Follow PC mode, and it's the groundwork for live coding:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
To run Unix, the cabinet needs what its SIMH script asks for: 8K with EAE, the teletype, the clock, and the RB09 fixed-head disk. It loads boot.rim, and the bootstrap reads the system from disk. So the new part is porting SIMH's RB09.
B comes with it: the interpreter (bi.s) and loader (bl.s) survive in the scans, and Robert Swierczek rebuilt the missing compiler in 2016. There's no C on the PDP-7. C came later on the PDP-11, and B was Thompson's cut-down BCPL.
The plan is in the cabinet README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
And a couple days ago Mitch Bradley wrote a PDP-7 FORTH for it, including a Turtle Graphics package, which I'll integrate soon too! That's the other half of live coding. My assembler is TypeScript running on the emulator host, but Forth will run on the PDP-7 itself: you type new definitions at the emulated teletype, and the turtle draws them on the 340, interactively, in a language living inside the machine.
B compiles to threaded code too, so the cabinet will have two threaded interpreters, 1970 and 2026, running side by side!
Fittingly for a thread about whether the ENIAC had a BIOS: Mitch is the one who wrote Open Firmware, the Forth-based boot firmware in Sun workstations, PowerPC Macs, and the OLPC XO. So the PDP-7 is getting its Forth from the same man who invented Open Firmware to put Forth in the BIOS.
Mitch Bradley's PDP-7 Forth:
https://github.com/MitchBradley/pdp7forth/tree/main
PDP-7 Forth — Design Notes:
https://github.com/MitchBradley/pdp7forth/blob/main/DESIGN.m...
turtle.fs: Turtle Graphics for 340 vector graphics processor in FORTH (which works by assembling 340 display IOT opcodes):
https://github.com/MitchBradley/pdp7forth/blob/main/lib/turt...
Mitch Bradley singing the Open Firmware Song
https://www.youtube.com/watch?v=b8Wyvb9GotM
Mitch Bradley shows and explains Open Firmware
https://www.youtube.com/watch?v=KvxxAeuhPp0
Mitch's threading technique is a new one, as far as we can tell, small fast and elegant on the PDP-7. NEXT is three instructions, and the core of it is XCT I 10: it bumps an auto-index register and executes the thread cell it points at, so every cell in a compiled definition is itself a PDP-7 instruction, and its opcode is its type. CAL enters a colon word, JMP runs a primitive, and LAC or LAW pushes a constant or variable.
That makes location 10 a second program counter, running a virtual machine whose instruction set is the PDP-7's own. It doesn't fit Anton Ertl's threading taxonomy. For publication, "XCT Threading". For the T-shirt, "Indirectly Direct Threading".
PDP-7 Forth XCT Threading:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
Subsequent computers could have followed this "electro-mechanical ROM" approach, but I suppose it was rather bulky and inconvenient to change.
You can see what the uniselectors looked like here at 8:50
https://www.youtube.com/watch?v=Yc945sNB0uA
Of course programmable ROM chips would have to wait, so in the meantime the alternatives were either the toggle-it-in approach (still also used by the 1974 MITS Altair 8800), or other more compact types of handmade/hardcoded physical ROM such as magnetic core or diode matrices.
I was operating and maintaining several until about a decade ago.
Because the PDPs had magnetic core memory, so the bootloader, once toggled in, stayed in memory. The OS took care not to overwrite it.
And in normal operation you wouldn't have to use it at all, you just switched on your PDP, and it was in the same state as when you switched it off.
Also, bootloaders were short (because peripherals had lots of intelligence); toggling one in was a matter of minutes.
> I think that was because core memory was non-volatile.
Exactly. And when RAM cards were available to replace core (very late in the lifecycle of the minis), the RAM was battery backed to simulate that behaviour.
I first read that book before I knew that in British English a vacuum tube is called a valve (from thermionic valve and which makes more sense than the American term, I think), so I was confused by the line about how warm the room was due to all of the valves!
While 'valve' makes more sense from the point of view of what it does, 'tube' makes more sense from the point of view of what it is I think.
The content isn't very interesting, and Claude's comments aren't very detailed. Not bad for 2 minutes of work about a 62 year old computer though. Look out Ken Shirriff, AI is coming for you.²
Addr Octal Instruction Meaning
0001 7512 DCN 12 Disconnect channel 12 (put it in a known idle state)
0002 7712 FNC 12, 4000? Send function code to channel 12's device
0003 4000? └ function code (last bit unclear: 4000 or 4001)
0004 7712 FNC 12, 0001 Send another function code
0005 0001 └ function code
0006 7712 FNC 12, 1500? Send a third function code
0007 1500? └ function code (least certain row)
0010 2000 LDC 0160? Load A with a word count
0011 0160? └ the count
0012 7412 ACN 12 Activate channel 12
0013 7112 IAM 12, 0015 Read A words from channel 12 into memory starting at 0015
0014 0015 └ destination address
2. Not really. I have no idea if this disassembly is corrrect.
3. Quora is prison for words.
ENIAC in Action: Making and Remaking the Modern Computer is an excellent summary of the initial design and redesign of the Eniac.
> And John Von Neumann? He came and looked at our stuff and went back to Princeton and wrote a long document about the principles. He gets a lot of credit but the inventions were ours. Someday I’ll write a book on who really invented the computer.
>Johnny learned instantly, of course, as was his nature. But he chose to refer to the modules we had described as “organs” and to substitute hypothetical “neurons” for hypothetical vacuum tubes or other devices which could perform logical functions. It was clear that Johnny was rephrasing our logic, but it was still the SAME logic. Also, he was introducing different but equivalent symbols; nevertheless the devices still did the same things. Johnny did NOT alter the fundamental concepts which we had already formulated for the EDVAC.
>Small wonder, then, that computer history gave von Neumann the credit. Eckert and I, who left the Univ. of Penna. In 1946, no longer had access to the documents which might have helped to show “who did what, when.” But after many years, litigation has unearthed some of those documents, and historians can read what was once classified. But, even after declassification, those reports are not accessible to most people, since they were reproduced in such small quantities. Nevertheless, we hope that more historians will refer to them.
von Neumann's "First Draft of a Report on the EDVAC" was both a summary of discussions by the Eniac team as well as von Neumann's own original work proving and expanding on various aspects of those discussions. It's called the von Neumann architecture because he was the author of the seminal paper, not because he laid any particular claim to the ideas. Eckert and Mauchly were mostly upset about the paper's existence, regardless of author, because it made it impossible for them to patent the stored program idea in general.
As I understand it, even after adaptation to "stored program" mode, the program was still configured rather than loaded and stored, but now configuration was done using the function table dials (essentially a dedicated dial for each program step) rather than patch cords, and was a lot more convenient. Punched cards could be used for reading/writing data, but not for programs.
It seems there was no BIOS because I/O was so primitive. Per configuration a punched card would be read into the "constant transmitter" unit, then one of the read numbers could be copied into one of the 20 accumulators. Or you could do the same in reverse to output data from the accumulators.
As a matter of interest, "that time" being April, it was only two months later in June that the Manchester Baby ran its first stored program.
This is one of the thing we lose as more and more of the conversations turn to people privately asking LLMs things, who do their best to scrape out answers from the existing info or make up a best guess. People are losing the ability to ask experts with real, unique knowledge and then share that knowledge with humanity.
As shown in the linked picture, the byte pairs are divided into [4 groups of 3] instead of [3 groups of 4] switches, which I would find more comfortable as a hex-reader. I believe, maybe someone can confirm, that octal notation is easier to translate into bits than hex is. We just don't do either of those things terribly often anymore, so octal has mostly fallen out of favor, perhaps because it groups less nicely into multiples of 8.
Nowadays I almost never think in octal. The only time it seems to come up is for Unix file mode switches (chmod etc), which likely date to this time when octal was more common.
Just some interesting cultural drift.
Fundamentally I wouldn't say octal is fundamentally easier to interpret other than hex because it's just half as many digits. The shorthand things about octal used in unix you mentioned all still technically apply to hex as well. The only really tricky part is where it becomes letters and you have to think if D or E is the odd value with the first bit set. If you were doing hex all day though, the 6 hex letter patterns would be pretty easy to memorize.
Personally I would say for front panel systems specifically was just about physical space for the switches. If you look up CPU trainers for something like Intel 8080 in the Altair 8800, you'll see it uses a hex keypad. Multiple 16b values would have been a lot harder to fit in single bit switches.
So you programmed the front panel with 3 fingers for octal instead of 4 for hex.
Read the full thread on Hacker News →
Related stories
- Hacker News · 145 points · 5 days ago
- Alan Kay: Normal Considered Harmfulyoutube.comLobsters · 1 points · about 14 years ago
- Hacker News · 2 points · about 10 hours ago