MacBaby: An Emulator for the World's First Von Neumann Computer

[Snial]

There's an article on Hackaday right now, celebrating the world's first Von Neumann computer, Manchester University's SSEM (known as "The Baby"); which ran its first program in June 1948.

So, many members might think ENIAC or perhaps even Cambridge's EDSAC, the Harvard Mark I (or IV), or Zuse's machines were the first Von Neumann computers, but this isn't really correct. ENIAC hard to be programmed by jack plugs and sometimes hardware mods; EDSAC was a year later; the Harvard Mark x's weren't Von Neumann and the Zuse machines weren't known to be Turing-complete until decades later (and probably didn't run programs from memory either).

So, suprisingly, this is it. Back in 1998 Manchester Uni were developing a replica, and so I decided to write an emulator for it. In some ways its a more authentic emulator than most, because it copies the display the way it was actually shown (every digit was lit up, 1's were just longer); the "Typewriter" was a set of buttons in a rectangular grid; the toggle switches behave like the real machine.


You might wonder why the Manchester Baby looked so crude. It's because the purpose of the project was to test the phosphor on CRTs as memory for Cambridge and they figured the best way to test it was to wrap a computer around it (sneaky)! Hence, they beat Cambridge, but Cambridge rejected these Williams-Kilburn tubes because the memory density was so poor, compared with the mercury delay lines they eventually used.

My version, written in THINK C could run on a Mac Plus at full speed (700 IPS), but what I didn't know until today was whether it could run on a Mac 128K. And it does (under system 1.1).



There are a few errors though, for some reason labels F1, F0 and L4 to L0 aren't displayed; nor are LC, 'WE', 'MAN', 'SP', 'CC' or 'STOP'. But we can still play with it! And this short guide will help you go through the tortuous process of programming the world's first computer, as it was programmed!

1. Unzip mfsMacBaby.dsk.zip (it's a 400kB MFS-formatted disk image).
2. Click on InfiniteMac, https://infinitemac.org/1984/System 1.1?infinite_hd=false&saved_hd=false
3. Drag mfsMacBaby.dsk to the emulator. You should see a second disk appear on its desktop.
4. Open the mfsMacBaby (marked "Untitled"), then double-click on the MacBaby app. Its emulator window should appear. It's showing my default set up: the numbers 0 to 31. So, note, the SSEM showed all the numbers in reverse order, where the address comes first with least significant digit on the left and the most on the right. Then comes the opcode for the instruction, again with the least significant digit on the left.
5. To clear all the numbers toggle the SC toggle button.
6. You'll need to clear the program counter. Click just to the right of where it says: "C" and a separate image will appear. This is close to how it worked on the real Manchester Baby. There was one CRT display, but it could be made to select one of 3 storage units: the program, the accumulator ('A') and the program counter ('C').
7. Clear the program counter by toggling the CC button, it's not shown in System 1.1, but it can be seen in the first image above. The default Program Counter value should clear.
8. Now go back to the program by clicking on the "Store" button near the bottom-left. It won't show any change, because both stores are now clear.
9. You can now toggle in the program. I suggest trying incrementer, below.
   1. Toggle the "WE" (Write/Erase) switch, down = Write.
   2. Set L4 to L0 toggle switches all 'up', this is line 0. You can see which is the current line as it's the thicker one. The SSEM pre-increments the program counter so you can't use line 0 for code. Click on L0 to make it line 1.
   3. Now click on Typewriter buttons '0', '3', '14'. This sets bits 0, 3 and 14 to enter the LDN (load negative) instruction. If you make a mistake, you can hit the 'LC' toggle button (on the right of 'SC') which will clear the current line.
   4. Adjust the L4 to L0 toggle switches for each successive line; and click on the Typewriter buttons until they show each successive instruction.
   5. When you've finished it should look like:
   6. Set L4 to L0 to 0.
10. Now you can run the program, toggle the 'run' button! The image updates at about 60Hz max, though the calculations are at full speed.

The simplest program is incrementer. It's:

Loop:
    LDN x    ;1001000000000010
    STO z    ;0101000000000110
    LDN z    ;0101000000000010
    SUB y    ;0001000000000001
    STO x    ;1001000000000110
    JMP Loop;1110000000000100 (address Mem[7]+1)
    0        ;0000000000000000

y EQU 8
   -1 ;11111111111111111111111111111111
x EQU 9
    0 ;
z EQU 10;

There are many strange things about the instruction set. You can't load a positive number, only a negative one (which means you need to re-negate). You can't add, only subtract; Jumps are indirect.

MacBaby 1.03 has at least one other issue on a Mac 128K under System 1.1. Trying to save a program will crash the Mac!



In a little while, I hope to upload the source code, but you can find the project here: https://web.archive.org/web/20070205070856/http://www.p-skids.freeserve.co.uk/

You can read more about the SSEM on Wikipedia.

 

[cheesestraws]

Cambridge rejected these Williams-Kilburn tubes because the memory density was so poor, compared with the mercury delay lines they eventually used

This is really interesting, because I'd have expected the CRT to have higher density than the mercury tubes (presumably, using phonons to store data using speed-of-sound?). That would suggest a mandatory minimum size for the mercury tubes, while the CRT's density would be limited by how good your light isolation/sensing was, which even at that time feels like it ought to have been smaller. Any idea what I'm missing?

 

[adespoton]

Can it play Doom?

Sorry, just had to get that out there.

This is a really neat project; thank you for providing it. I wonder if there's a way to simulate phosphor bloom as a filter?

 

[Snial]

This is really interesting, because I'd have expected the CRT to have higher density than the mercury tubes (presumably, using phonons to store data using speed-of-sound?). That would suggest a mandatory minimum size for the mercury tubes, while the CRT's density would be limited by how good your light isolation/sensing was, which even at that time feels like it ought to have been smaller. Any idea what I'm missing?

The bit that puzzles me is the refresh mechanism. Basically, the tube is DRAM. The image is scanned at 50Hz (I think) and the phosphor reading is fed back into the display, re-amplified. But in my mind it ought to drift right, because it can't refresh until it's been read. Maybe it makes use of phosphor bloom as @adespoton mentioned. If the read threshold is met before the peak, then when the feedback circuit causes the electron gun to excite the phosphor, the bloom is wide & persistent enough to enable the read circuit to read the signal in the same place on the next frame.

Or maybe the refresh circuitry always just generates a screen of 0s, so it's always synchronised; then the '1's, being longer, are also timed and make use of the delay. For example, if the scan is 64µs, then each bit is 2µs. So, a '1' gets detected some way into the pulse, while the 0 is still being output, so the signal can be turned off at the right point and it doesn't drift.

The Manchester Baby of course, had a 1-bit, single function ALU: subtract with carry.

But you seem to have a reasonable analysis, I thought it was a reliability issue that limited data density. Mercury tubes weren't much better though. Ironically, EDSAC used a CRT to observe its RAM, (which is also DRAM of course) but here it'd be that the bits read out from the tube get fed in real-time to the CRT.

Can it play Doom?
Sorry, just had to get that out there.

Funny you should say that. They tried: the program "Tom Kilburn's 1948 Nightmare" is the closest ;-) !

The baby chases Tom forever!!! He's Doomed!

This is a really neat project; thank you for providing it. I wonder if there's a way to simulate phosphor bloom as a filter?

I wrote a version which had display green when run in colour, but the attached version isn't it. However, as promised, here's a version with source code (compiles for CodeWarrior 68K).


Bonus Page
On that web page you can click on iBase, which I wrote in 2002. It's basically me hypothesising about an iPad about 8 years early. So, my meanderings about M88K and the Color Personal Macs are nothing new. Feel free to check it out. The wayback machine didn't scrape the photos for some reason. In fact it's a photo of an Apple 15" LCD monitor from the day with my iBook screenshot superimposed, and the second image is of the black pro-keyboard inverted to white and minus a numeric keypad (which Apple did produce for the iMac around then).

iBase

iBae is surprisingly close to an iPad. The basic concept is the same: getting people to buy a device that can mostly function as a computer, but is as cut down as possible. Things I got wrong:

• iBase props up by itself (as you could have seen on the photo at the time), but an iPad relies on a fold-out stand.
• iBase has two interfaces: USB and Firewire. In fact the iPad (in 2010) only had Universal, which is USB-based AFAIK.
• iBase has a G3 CPU at 500MHz or 450MHz, the iPad in 2010 ran at 1GHz and was an ARM A8.
• iBase had 128MB of RAM, iPad had 256MB.
• iBase had an 800x600 display, iPad was 1024 x 768.
• iBase was landscape - iPad mostly functioned portrait.
• I didn't guess swivelling.
• iBase had a spinning hard drive, but iPad was SSD from the start.
• iBase had a keyboard and mouse, but iPad was touch-screen.

You can see it's close to my M88K, R41 concept. The last one is my biggest mistake. Having worked on a Nokia web tablet project (Joshua) in 2000-2002; I should have assumed it was a touch-screen.

The price was spot on though. I guess $500, actual price $499!