Research UNIX was ported to the UNIVAC, which (I believe) was the first SMP kernel implementation. It ran on top of the native kernel, known as EXEC-8. A later port to IBM hardware did the same.
"The UNIX system for the UNIVAC 1100 series was built as an integrated development environment for transactions that run directly on EXEC. Unlike most other implementations, therefore, it runs not directly on the hardware but as a collection of user-level activities under control of EXEC. These obtain services that would normally be provided by device drivers, and some process creation and management services from EXEC. Any configuration supplied by Sperry, including multiprocessor ones, can run the UNIX system."
WOW! I started off thinking "this could be a boring meandering through registers and op codes" but by the time I got half way through your write-up, I was bouncing off the walls excited. Thanks for sharing your awesome write-up and glad you had such a cool project!
What a great write up, and a video too! Even though Minecraft stuff ofc was a bit of a bait, it would be interesting see the answer to "Can it run Doom?".
From the article:
Only 40,960 words of memory. That’s only 90kb total memory to split between our code and the memory it needs at runtime.
Also it's a 250khz CPU. Not megahertz. Kilohertz. It's slower than the 1MHZ 8-bit home computers like the Apple ][ or c64.
"Running" Doom might be possible with some insane hack that offloads storage and/or processing to more modern hardware crammed into the UNIVAC case but given that this is one of two UNIVACs in the entire world, and the only one that actually runs, I don't think the museum is gonna let anyone cram a Raspberry Pi up in there.
> a bit of a bait
"a bit" is doing a lot of work there. It was absolute nonsense. They were no closer to running a Minecraft server than I am to running UKGOV.
They hosted a program that allowed minecraft clients to connect... I'd class that as a minecraft server, even if it wasn't a very good one
> They hosted a program that allowed minecraft clients to connect...
Connect in the sense of receiving a login packet and saying "yes". That's it. Steps 1, 2, 3, 9, 10 of [0] (they didn't mention encryption or compression, I'm assuming they didn't implement it.)
They didn't mention anything about any of the steps past 10 - again, assuming they didn't implement them.
It's a trivial thing they've implemented - good work, sure, but a Minecraft server? Absolutely not.
Now, if the game was libre software it could be improved and ported to Puny Inform (a 'lite' version of Inform6 tuned for smaller machines) creating a really small Z3 file being able to play it from the PDP10 and 8 bit microcomputers to anything from today. From smartphones to PDA's to GNU/Linux with Frotz to Winfrotz and Lectrote and Fabularium for Android/Mac and iOS.
So, 'does it run Doom'? Man, you can play Zork in a pen with writting detection. How cool is that?
It could probably run the code for doom, once recompiled for the risc-v emulator, but given that the only output is a paper teletype, displaying it would be a problem
> but given that the only output is a paper teletype, displaying it would be a problem
You are in a maze of twisty passages, all alike. A cacodaemon floats by, hissing.
I wonder which would be faster: computing a frame, or printing it? If you could print one frame at a time, you could make a flip-book animation.
And given the NES emulator example, take half an hour per frame.
Feels kind of like when Usagi Eletric got "Doom" running on a vacuum tube computer with a teletype interface without support for even ASCII, but it was just an imitation of the background music.
Anything for the thumbnail.
"What's My Line" had in-show advertisements for the UNIVAC computer.
Favourite article I've read in a while, what a delight. I wonder what kind of performance you could get if someone hand wrote a dedicated, modern C compiler for it.
According to the article, it takes 40 univac instructions to run a single risc-v instruction, so potentially up to 40x the current performance. Though you'd probably need more instructions to do things than a single one, so probably less than that, say 10-20x? Especially if you made a custom compiler that made the best use of the hardware you could, since it's weird
RISCV is a VEEEEERY poor emulation target - the piecemeal scattering of immediates all over the instr makes it very slow to assemble them (lots of ANDs, shifts, and ORs) . Re-encoding them is one solution, yeah, but then this is a mandatory messy post-compilation step that also needs to know what is code and what is data. It is almost a pessimal setup. MIPS is much simpler to emulate
Hey, wait a minute, you're the guy who got Linux to run on a 4004 by writing a MIPS emulator[1]! If there's anyone who's been down a similar path before it'd have to be you.
> it takes 40 univac instructions to run a single risc-v instruction
Which is wild, given:
> The computer’s original purpose was to be used by the Navy to read in radar signals and direct artillery
I'd really be fascinated to see how that was done on such a primitive machine, shame that's probably been lost.
The radar "reading" was done by first plotting analog radar signals to the antique rotary radar displays. Then there would be human operators with a light pen, marking each radar signature on each radar turn.
So the Univac would receive input coordinates for each target and track those in memory each turn.
Hah, I heard about this at VCF East this year, but didn't get to check out the exhibit. There was another MC server demo running on old Macs IIRC. Shame the event was cut short due to a bomb threat.
Yeah, I was there on Saturday and could not imagine how it would end the next day. Got to see the Univac powered up but not spitting out those awesome outputs at the time.
Give me access to the machine and i'll have linux up on it in a few weeks ;) For real, not just the login prompt
Does anyone know why the jal RISC-V instruction scrambles it bits in this way?
RISC-V's instruction encoding is designed to keep the bits of literals in common positions between different instruction types. I believe this is to simplify/speed up instruction decoding. The MSB of the literal is always the MSB of the instruction, which makes sign extension consistent. Most of the other bits in the J-type encoding line up nicely with the I-type or U-type encodings.
I watched the video when it came out, I've been a fan of his stuff for a while. It'd been a while since he uploaded and I was rewatching some of his videos the night before this was uploaded!
On '18 bit words'... if you know some experts on the PDP10, these might help you, they already created new software for ITS and Tops20.
"Claude Code can’t write UNIVAC assembly yet" Who knew. It's hard just to look for data on the internet(besides wikipedia).
Stupid question, would a quick&dirty LLVM backend for univac be possible to write, or are there inherent incompatibilities due to its weird architecture?
I'm not sure if LLVM would support ones-compliment (does GCC even support that any more?)
I would like to see this code instead compiled native instead of via the RISC-V interpreter.
Research UNIX was ported to the UNIVAC, which (I believe) was the first SMP kernel implementation. It ran on top of the native kernel, known as EXEC-8. A later port to IBM hardware did the same.
"The UNIX system for the UNIVAC 1100 series was built as an integrated development environment for transactions that run directly on EXEC. Unlike most other implementations, therefore, it runs not directly on the hardware but as a collection of user-level activities under control of EXEC. These obtain services that would normally be provided by device drivers, and some process creation and management services from EXEC. Any configuration supplied by Sperry, including multiprocessor ones, can run the UNIX system."
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/other...
WOW! I started off thinking "this could be a boring meandering through registers and op codes" but by the time I got half way through your write-up, I was bouncing off the walls excited. Thanks for sharing your awesome write-up and glad you had such a cool project!
What a great write up, and a video too! Even though Minecraft stuff ofc was a bit of a bait, it would be interesting see the answer to "Can it run Doom?".
From the article:
Only 40,960 words of memory. That’s only 90kb total memory to split between our code and the memory it needs at runtime.
Looking at a copy of Doom on the Internet Archive (https://ia800404.us.archive.org/view_archive.php?archive=/15...), DOOM.EXE is about 709k, and DOOM.WAD is about 11159k.
I think that's a pretty solid no.
Also it's a 250khz CPU. Not megahertz. Kilohertz. It's slower than the 1MHZ 8-bit home computers like the Apple ][ or c64.
"Running" Doom might be possible with some insane hack that offloads storage and/or processing to more modern hardware crammed into the UNIVAC case but given that this is one of two UNIVACs in the entire world, and the only one that actually runs, I don't think the museum is gonna let anyone cram a Raspberry Pi up in there.
> a bit of a bait
"a bit" is doing a lot of work there. It was absolute nonsense. They were no closer to running a Minecraft server than I am to running UKGOV.
They hosted a program that allowed minecraft clients to connect... I'd class that as a minecraft server, even if it wasn't a very good one
> They hosted a program that allowed minecraft clients to connect...
Connect in the sense of receiving a login packet and saying "yes". That's it. Steps 1, 2, 3, 9, 10 of [0] (they didn't mention encryption or compression, I'm assuming they didn't implement it.)
They didn't mention anything about any of the steps past 10 - again, assuming they didn't implement them.
It's a trivial thing they've implemented - good work, sure, but a Minecraft server? Absolutely not.
[0] https://minecraft.wiki/w/Java_Edition_protocol/FAQ#What's_th...?
Not enough dedotated wam for all that.
Yeah, my thought exactly, execution lacked, but i do admire the attempt.
Not Doom, but a ZMachine interpreter might run with:
- Zork I-III
- Calypso
- Tristam Island
- All the Z3 machine games at IF archive
- The rest of Infocom propietary games
https://www.ifwiki.org/List_of_Z-machine_interpreters
Also: https://ifdb.org/viewgame?id=lkr2jf03np19ieix
Now, if the game was libre software it could be improved and ported to Puny Inform (a 'lite' version of Inform6 tuned for smaller machines) creating a really small Z3 file being able to play it from the PDP10 and 8 bit microcomputers to anything from today. From smartphones to PDA's to GNU/Linux with Frotz to Winfrotz and Lectrote and Fabularium for Android/Mac and iOS.
So, 'does it run Doom'? Man, you can play Zork in a pen with writting detection. How cool is that?
It could probably run the code for doom, once recompiled for the risc-v emulator, but given that the only output is a paper teletype, displaying it would be a problem
> but given that the only output is a paper teletype, displaying it would be a problem
You are in a maze of twisty passages, all alike. A cacodaemon floats by, hissing.
I wonder which would be faster: computing a frame, or printing it? If you could print one frame at a time, you could make a flip-book animation.
And given the NES emulator example, take half an hour per frame.
Feels kind of like when Usagi Eletric got "Doom" running on a vacuum tube computer with a teletype interface without support for even ASCII, but it was just an imitation of the background music.
Anything for the thumbnail.
"What's My Line" had in-show advertisements for the UNIVAC computer.
https://www.youtube.com/watch?v=rEQlOrPs6fw
Favourite article I've read in a while, what a delight. I wonder what kind of performance you could get if someone hand wrote a dedicated, modern C compiler for it.
According to the article, it takes 40 univac instructions to run a single risc-v instruction, so potentially up to 40x the current performance. Though you'd probably need more instructions to do things than a single one, so probably less than that, say 10-20x? Especially if you made a custom compiler that made the best use of the hardware you could, since it's weird
RISCV is a VEEEEERY poor emulation target - the piecemeal scattering of immediates all over the instr makes it very slow to assemble them (lots of ANDs, shifts, and ORs) . Re-encoding them is one solution, yeah, but then this is a mandatory messy post-compilation step that also needs to know what is code and what is data. It is almost a pessimal setup. MIPS is much simpler to emulate
Hey, wait a minute, you're the guy who got Linux to run on a 4004 by writing a MIPS emulator[1]! If there's anyone who's been down a similar path before it'd have to be you.
[1] - https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004
Yup. And that one of the reasons why not RISCV
> it takes 40 univac instructions to run a single risc-v instruction
Which is wild, given:
> The computer’s original purpose was to be used by the Navy to read in radar signals and direct artillery
I'd really be fascinated to see how that was done on such a primitive machine, shame that's probably been lost.
The radar "reading" was done by first plotting analog radar signals to the antique rotary radar displays. Then there would be human operators with a light pen, marking each radar signature on each radar turn.
So the Univac would receive input coordinates for each target and track those in memory each turn.
Hah, I heard about this at VCF East this year, but didn't get to check out the exhibit. There was another MC server demo running on old Macs IIRC. Shame the event was cut short due to a bomb threat.
Yeah, I was there on Saturday and could not imagine how it would end the next day. Got to see the Univac powered up but not spitting out those awesome outputs at the time.
Give me access to the machine and i'll have linux up on it in a few weeks ;) For real, not just the login prompt
Does anyone know why the jal RISC-V instruction scrambles it bits in this way?
https://msyksphinz-self.github.io/riscv-isadoc/html/rvi.html...
RISC-V's instruction encoding is designed to keep the bits of literals in common positions between different instruction types. I believe this is to simplify/speed up instruction decoding. The MSB of the literal is always the MSB of the instruction, which makes sign extension consistent. Most of the other bits in the J-type encoding line up nicely with the I-type or U-type encodings.
Port Scoundrel/Donsol:
https://codeberg.org/luxferre/scoundrel-ports
Rules:
gopher://hoi.st/0/posts/2026-01-05-discovered-new-game.txt
Related: https://github.com/TheScienceElf/UNIVAC-1219 https://youtu.be/rU8sCbwB8XU
I watched the video when it came out, I've been a fan of his stuff for a while. It'd been a while since he uploaded and I was rewatching some of his videos the night before this was uploaded!
On '18 bit words'... if you know some experts on the PDP10, these might help you, they already created new software for ITS and Tops20.
"Claude Code can’t write UNIVAC assembly yet" Who knew. It's hard just to look for data on the internet(besides wikipedia).
Stupid question, would a quick&dirty LLVM backend for univac be possible to write, or are there inherent incompatibilities due to its weird architecture?
I'm not sure if LLVM would support ones-compliment (does GCC even support that any more?)
I would like to see this code instead compiled native instead of via the RISC-V interpreter.
Incredibly cool project and fantastic write up!
beautiful, thank you