pdp7-unix

casses." 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...

_chdir_ was spelled _ch_; why this was expanded when we went to the PDP-11 I don't remember." Now here's where it gets curious: While reading the [Unix V0 shell source code (`pbsh.s`)](https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbsh.s#L199C1-L210C18), I found something that seems to check for a built-in command matching the string `"chdir"` — but compares the first 3 characters, NOT 2 or 5: ```asm " https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbsh.s#L199C1-L210C18 chdirstr: <ch>;<di>;<r 040 . . . . . . " check for built-in "chdir" command lac argv0 sad chdirstr skp jmp 1f lac argv0+1 sad chdirstr+1 skp jmp 1f lac argv0+2 sad chdirstr+2 jmp changedir ``` This logic suggests it would match a string like `chd` — since only the first 3 characters are compared (`argv0`, `argv0+1`, `argv0+2`). However, when running the Unix V0 in SIMH, I can only get `ch` to work — `chd` doesn't appear to be recognized as a command. This seems contradictory with what the shell source implies. Has anyone seen `chd` documented or working in early Unix shells? Would love to hear from others who have explored this layer of Unix archaeology.

yscall tables. 32 bit ARM and x86 are more-or-less matches, with ARM differing on a few early syscalls, while 64 bit ARM and amd64 differing quite dramatically. The old ABI for 32bit MIPS also matches, but both the n32 and n64 ABIs use slightly variant syscall tables. PowerPC 32/64 bit is also a close match, although it has some impedance (I think it matches closer to AIX by design) At the end of the day, I think the similarity is mostly a mixture of coincidence, system developers being influenced by their bootstrap system's syscall tables, and no real reason to change them up. No reason to not change them, either, since it's pretty trivial to use different dispatch tables for different types of processes, like how the BSD's handle other-OS compat.