Manchester Baby
The Manchester Baby was the world’s first real computer. Mike Bedford introduces this pioneering machine and shows you how to write code for it.
The Manchester Baby was the world’s first real computer. Mike Bedford introduces this pioneering machine and explains how to write code for it.
Were we to conduct a poll, asking for the identity of the first ever electronic computer, we’d get a diverse range of responses. Colossus, as created for code-breaking at Bletchley Park in England, would surely get a look-in. It probably was the world’s first programmable electronic computer, but it wasn’t universal since it was designed for specific tasks. On the other side of the pond, ENIAC, which was developed at the University of Pennsylvania, is another strong contender. Unlike Colossus, it was universal, but it was programmed by switches, dials and patch leads.
While both of these pioneering machines were firsts in their own ways, there’s little doubt about the identity of the machine that paved the way for the information revolution that took place during the second half of the 20th century and continues apace today. That was the so-called Small Scale Experimental Machine (SSEM), that was developed at the University of Manchester, and which has been nicknamed the Manchester Baby.
What made it so ground-breaking is that it was the first stored program electronic computer, meaning that it stored its program in its own memory, as do all today’s mainstream computers . It ran its first program – to calculate the highest proper factor of a number – on 21 June 1948, and the world hasn’t been the same since.
Baby be mine!
We’re going to be delving into how the Manchester Baby was programmed – and how you can do so today using a simulator – but first let’s take a look at this innovative machine. We’ll be painting a picture of a computer that appears under-powered compared to even the simplest of today’s computers, but it’s important not to lose sight of what an amazing achievement this was.
The first thing to remember is that it would be more than a decade before integrated circuits would come to fruition, and it would be another decade before largescale integration – as required for microprocessors – would become viable. Even the transistor, on which integrated circuits are based, were still in the development labs – it would be patented just a few days after the Manchester Baby first showed its colours.
At this time, the only option for electronic circuitry was the valve, otherwise known as the tube. But these components weren’t cheap: they were power-hungry, and they weren’t anywhere nearly as reliable as transistors would become. What’s more, these 60-80mm tall glass bottles had to be soldered together by hand. The upshot of all this is that the SSEM had to be designed to be as simple as possible. Despite its minimalistic specification, though, it was built from no fewer than 550 valves (compare that to a few billion transistors in today’s microprocessors), it occupied a whole room, being housed in seven racks each 580mm wide by about two meres tall, it weighed almost a tonne, and it consumed 3.5kw of power (‘tis but a bar fire – Ed).
So now we know something of the enormous engineering challenge of building the Baby, let’s turn our attention to its rather pedestrian specification. Surprisingly, the word length wasn’t as basic as we might have assumed. While the first-ever microprocessor – the 1971 Intel 4004 – had a four-bit architecture, and even the processors used in the home computers of the early 1980s only had eight-bit chips, the Manchester Baby boasted a 32-bit architecture.
While this had the effect of increasing the complexity of much of the SSEM’S hardware, it didn’t complicate the memory because it wasn’t made of valves, in the same way that today’s memory is transistor-based. Instead, the memory was based on CRTS that were used in TVS and monitors before LCD panels appeared on the scene. The CRTS used in the Baby were of the type intended for use in radar equipment.
While not getting into the complexities of this bizarre form of memory, it transpires that if you write to the
screen an image comprising rows of dots and dashes, which correspond to binary zeros and ones, that data can be read back using a metal foil placed on the front of the CRT. Like today’s dynamic memory, data in CRT memory soon died away so it had to be continually refreshed by reading and re-writing each bit.
The Baby’s main tube was used as RAM, which was called the store, and it had a capacity of 32 32-bit words. A second CRT was used for the accumulator, A – the internal register in which arithmetic operations are performed, and a third for the control instruction, CI (the program counter in today’s terms) – the internal register which stores the address of the current instruction in memory – and the present instruction, PI (the instruction register in today’s terms) – the internal register that contains a copy of the current instruction. And finally, because data on the main three tubes could not be read visibly, their screens being obstructed by their metal foils, a fourth tube, the display tube, was provided, and which could be switched to parallel any of the main tubes, to allow data to be read by eye.
When we move to aspects other than the data width, we do find a modest design. For example, it operated at a speed of just 1,100 instruction per seconds. However, the area in which the Baby differed from most of the computers that followed it is in its instruction set. That’s the number of different instructions it could execute. Let’s cut to the chase, therefore, and state that the SSEM had a repertoire of just seven instructions. To put that into context, the first-ever microprocessor had 46 instructions, and for today’s latest and greatest, this number increases to several thousand.
SSEM instructions
To program any computer in its internal low-level language – and that was the only option with the SSEM – we need to understand what each of its instructions does. First of all, therefore, let’s take a look at the Manchester Baby’s seven instructions. These instructions would have been entered as their opcodes. That’s the associated binary numbers that are stored in memory, but we’ll also refer to them by typical modern mnemonics. Although mnemonics weren’t used when programming the Baby, they are now used when programming in assembler language – a simple language in which each assembler instruction translates directly to a single opcode – indeed we’ll present an assembler language program for the Baby later on.
In the following descriptions, remember that instructions comprise 32 bits of which bits 13 – 15 are the opcode, bits 0 – 4 are the so-called line number, that’s the address in memory of the data the instruction works on, and the other bits aren’t used. The other thing you need to know is that, unusually in today’s terms, the least significant bit is on the left and the most significant bit is on the right when viewed on the CRT, so that’s also the way we’ll show them here.
JMP instruction (jump) has the opcode 000. It copies the data from the specified line number in the store to the CI, therefore causing execution to deviate from simply progressing to the next instruction in memory. However, it’s important to note that the CI is always incremented immediately before executing a new instruction, so the line number should be one less than the address of the instruction to jump to.
JRP instruction (relative jump) has the opcode 100. It adds the content of the specified line number in the store to the CI, again causing execution to deviate from progressing to the next instruction in memory. Because it’s a relative jump, it can be thought of as causing execution to skip the number of instructions.
LDN instruction (load negated) has the opcode 010. It writes the negated content of the specified line number in the store to the accumulator.
STO instruction (store) has the opcode 110. It copies the content of the accumulator to the specified line number in the store.
SUB instruction (subtract) has the opcode 001 or 101. It subtracts the content of the specified line number in the store from the value in the accumulator.
CMP instruction (compare) has the opcode 011. It skips the next instruction if the value in the accumulator is negative.
STP instruction (stop) has the opcode 111. It terminates execution.
The limited instruction set might be an eye-opener, yet it is Turning Complete so it allows universal computation. One obvious drop-off is addition, but it’s not hard to devise a program that can add two numbers together. It should be obvious that the following program would add together the values in lines 10 and 11 in the store, storing the result to line number 12 in the store.
In the program listing, the first number is the line number in the store at which the instruction is stored, then we see the instruction in assembler format, and finally we have the binary representation which is what has to be entered via the front panel switches. The binary numbers have spaces inserted, but that’s just to make it more readable, because the opcodes and line numbers are easily identifiable. Note also that, because the CI is initialised with the value 0 before a program is executed, but this is immediately incremented, all programs should start at address 1.
01 LDN 10 01010 00000000 010 00000000000000000
02 SUB 11 11010 00000000 001 00000000000000000
03 STO 12 00110 00000000 110 00000000000000000
04 LDN 12 00110 00000000 010 00000000000000000
05 STO 12 00110 00000000 110 00000000000000000 06 STP 00000 00000000 111 00000000000000000
SSEM simulator
Various simulators have been produced over the years, but the one we’ve chosen enables you to operate the SSEM by clicking switches on a photorealistic representation of its front panels, and to see the program and results on something that appears identical to the actual CRT. It’s a Java application that you can download from www.davidsharp.com/baby and, of course, you need to have the Java Runtime Environment installed. You must configure your PC for a vertical screen resolution of at least 900 pixels.
The main display is of the front panel switches and the display CRT. The emulator starts up with a program already loaded so just click the switch marked STOP RUN, which appears in the bottom-left corner. This will cause it to toggle from its initial up position (STOP) to the bottom position (RUN) and, in so doing, cause the program to execute. The purpose of the program is to solve a differential equation, storing the result in a form that will enable it to appear as a graph when viewed on the store CRT. Although this program would execute almost instantaneously on a modern PC, the simulator operates at the speed of the original SSEM so, over a period of over a period of a few seconds, you’ll see a parabola drawn on the CRT and, when it terminates, the red light to the top left of the CRT will illuminate.
It all adds up…
For something a bit more challenging, but also more informative, we suggest trying out our simple addition program. So, here’s how to enter and execute the program and see the result. First of all, make sure that the STOP RUN switch is in its up position (STOP). Also, ensure that the MAN AUTO switch, which is towards the right of the middle panel, is in its down position (AUTO), and the WRITE ERASE switch, which is at the bottomright, is in its up position (WRITE). Also, make sure that the CRT is displaying the store by clicking the red ‘Sc’ button, which is near the bottom left.
Next, we’ll use the various buttons on the black panel at the bottom, which are used to clear the store or part of it, and the various internal registers. Note that, unlike the other switches we’ve used so far, these aren’t toggle switches: they don’t latch mechanically, but immediately return to their normal position after you’ve clicked them. So, click KSC to clear the store, and you’ll see that the CRT will change to showing just dots, which represent zeros. If the stop light is illuminated, click CK to extinguish it. Next click KCC, which clears the
accumulator, the control instruction and the present instruction registers.
With all this preparatory work complete, we can enter the first line of the addition program. First of all, therefore, we’ll select the line number in the store using the switches labelled 0, 1, 2, 3 and 4 which represent a five-bit binary number. The first line of our program is at address 1 so ensure that all these switches are up (zero), except for the 0 switch, which should be down (one). Now, we define the data to be written to that address using the 8 x 5 array of red buttons which represent the 32 binary digits, starting with 0 at the top left and progressing down each column.
We want to enter the value 0101 0000 0000 0010 0000 0000 0000 0000 0, so click the buttons for bits 1, 3 and 14. Like the clear buttons, these buttons will return to their initial positions after you’ve clicked them, and you’ll see specified dot on the CRT change to a dash. If you make a mistake, the easiest way to correct it is to click the KLC switch, to clear only the current line in the store and try again. Then enter the other five instructions in the program and also enter the two values to be added together at line numbers 10 and 11, remembering that the least-significant bit is at the left. Finally, ensure that all the five switches labelled 0 to 4 are in the down position. It’s not clear why this is necessary, but programs won’t run properly otherwise. Now, to see the program in action, move the STOP RUN switch to its down position (run). So long as you entered the program correctly, you’ll see the result appear at line number 12 and the red light will illuminate.
If your program didn’t work correctly, compare your program with the image of the store CRT with this program in the store, that we’ve provided. We’ve used the data values of 123 and 48 in line numbers 10 and 11 and, because the program has already run, the answer of 171 appears in line number 12.
Another way of debugging the program is to use the simulator’s disassembler. In fact, it would be a good idea to do this, even if the program did work. So, in the simulator’s View menu, select Disassembler. The disassembler window will appear, showing for each line,
the line number, followed by the disassembled instruction and then, after the ; the equivalent data, which is in decimal rather than binary. This makes it easy for you to compare the data in the store with the program you intended to enter. It also provides you with a way of editing or entering code in a much easier way than was available to the SSEM’S creators. If you edit the assembler representation of an instruction in the disassembler window and then click the window’s “Save to store” button, the new instruction will be written to the store. The decimal representation in the window won’t change immediately so, to see this reflect your edit, click the window’s “Load from store” button.
Having seen how the Manchester Baby was programmed using its panel switches, we suggest that you cheat by using the simulator’s assembler functionality. The easiest way is probably to create your programs in a text editor and then load them into the SSEM using the “Load snapshot/assembly” option in the File menu. That file should have a first line that contains the number of lines to be written to the store, followed by that number of lines, each with either an instruction mnemonic, such as LDN 10, or a data value, which should be prefixed with NUM, for example NUM 15.
We’ll leave you to write some SSEM programs. You can be as adventurous as you like, although you’re limited by the fact that a program and all its data can occupy no more than 32 lines in the store. Looking at programs written by others is a good way of learning and the SSEM has some sample programs that you can load from the Examples menu and study. You’ll need to understand what they’re supposed to do and your download will include a file called README which provides details of each of the example programs.