meh. i did this paper design during the year i was working in san francisco, while josh was in law school. i didn't have any way to work on anything physical so i did this paper design. it will never get built of course. feb 2012
My most recent (and most complicated) project is this Universal Machine. I keep repeating this paragraph from the Logical Design manual (below) as I've not yet said it better:
The goal of this project is to produce a fully functional stored-program digital computer, an idealized yet arguably authentic 1950-style vacuum tube computer capable of running real programs, with the express purpose of revealing the incredibly beauty and elegance inherent in these earliest machines, though mostly hidden under the primitive technical necessities of the time. The Machine will be the central focusing component in an art environment, either as an audience-participatory event or a passively-observed installation, depending on the software running in the machine.
Right now this project is in slow-motion. It's a rather large project, and will require a real budget to complete and probably a year (or two's) time. The user experience should really be as close as you want to get to e real tube computer.
It exists only on paper (and bits) today. This page contains everything but the schematics (twenty or so B-sized drawings). First, there is the Operator's Manual, a reasonably complete user's overview of the logical machine, required reading if you want to run the assembler and simulator (I recommend starting with THE OPERATOR'S VIRTUAL MACHINE section of that document). Next, if you get this far, is the Logical Design, an overview of the hardware design and accompanyment to the logic diagrams. Sorry, both documents lost pretty formatting in conversion to HTML.
Note that this is a design in progress: details will change at will. Notably, we're playing with memory technologies; the original design called for a magnetic drum, until the simulator proved that serial drum machines are in general too slow to output even canned text to a teletype at human speed (machines fast enough for human-scale I/O took some time to appear). We're looking at Williams Tubes electrostatic storage, as well as a discrete component memory investigated and abandoned on the SEAC machine. "We" includes myself and David and Scott Forbes, with whom I've been discussing memory issues.
The assembler and simulator have changed substantially. In addition to catching more errors (always nice :-) memory architecture and geometry are passed from the assembler to the simulator in the object metacode. This allows simulating a non-contiguous serial drum store, a fast disk, segmented memories, as well as plain old flat, linear memory (we're so spoiled today you have no idea).
No, there is no physical design visible here. Essentially, the Machine will be approximately the form factor of a small desk, with casters, or an equivelant cabinet. I/O is a standard Teletype Model 28 or equivelant. It will have a fully functional front panel, of course!
Here is the software component by component. The Perl code runs under Linux, and should run under other unices, and probably Windows with environmental changes.
Here are the Design-sheets.pdf referenced in the design manual.
The schematics and block diagrams are all on paper, one day i'll scan them...
| ac The Automatic Compiler, aka the assembler. This is a vanilla two-pass non-macro symbolic assembler, very 1972. The "order code" (aka instruction set) is an abomination, syntactically very 1960's, but the code itself is very 1952. It's a pretty abysmal order code, but a damn sight finer than a lot of 50's machines, it at least has immediate addressing. Run by itself and it will give you a tiny hint how to run, or stare at the source code like the rest of us. |
| sim The simulator. Perl, as above, run by itself for usage. It will run your program silently or with order-by-order chatter, which you will use to figure out why your "hello world" program is outputting one to two characters per second to the "teletype". (As it turns out, this is in fact how slow serial drum machines like the Royal McBee LGP-30 are. It puts a new (old) spin on display data output speed emphasis.) The only OS-dependent thing I can think of in this code is the sleep routine used to simulate realtime execution speed (admittedly necessary). |
| gill.asm The Gill Test was an important benchmark, once upon a time. Today you'd have a hard time detecting, never mind measuring, its execution speed. The UM executes it in about 400 milliseconds. Drum machines really suffer in this test. It is a good demonstration of optimum coding, however. An assembled "listing" is available as gill.p and the object code gill.o used by the simulator, not very interesting is it. |
| library.asm and listing library.p This is the start of a drum-resident library, not quite an operating system, but meant to be left in place on the drum for use as user-callable functions occupying the low-numbered tracks. They would likely occupy lower tracks. Very little of this is optimally coded, yet. Note the tricky teletype I/O routines, which use drum latency to perform bit timing (said feature eliminated a good 20 tubes from the design!) There is test code globbed onto the end. |
| ttow.asm listing ttow.p This innocuous-looking bit of code is the entire teletype serial output routine. It uses drum latency to time outgoing bits. This is the sort of sick stuff real programmers once did (I do not include myself as one, optimum coding terrifies me). |
| tty.asm listing tty.p Hmm, maybe this is the current teletype I/O source. No matter, it's all here, and all are decent (but novice) examples of drum machine code. This does contain the teletype input routine. |
| skew A tiny Perl tool to calculate drum sector skew tables, a major technique for recovering some performance with a machine like this. The answer: 4. |