The Manchester Mark 1 was developed over a period of a year and a half (November 1947 to June 1949). The version being reconstructed, and which you are invited to program, is the version which ran The First Program on June 21st 1948. This was known as the "baby" machine, or more officially the Small Scale Experimental Machine (SSEM).

Readers who are familiar with early computers may wish to go directly to the details in the Programmers Reference Manual (in Word format or HTML) or even to the definitive paper (in Word format or HTML) Here we attempt to give a gentler introduction.

Firstly it's important to understand the similarities and differences between the Baby and a modern computer. It's rather like comparing the Wright bothers' original 1903 'Flyer' with the latest model Boeing 747. There are many differences of scale, technology, and detail, but the basic essentials of controlled, powered, flight were all there in 1903. The differences in scale are much greater in our case, though. The 747 is no more than 20 times faster than the Flyer, although it weighs around 1000 times more. On the other hand, the P100 machine on which I'm writing this is about 100,000 times faster than the Baby, and has 256,000 times more main memory.

Similarities

Before the Mark 1, computing machines were "programmed" by changing the physical hardware configuration. Imagine programming your PC by moving wires around! The Mark 1 was the first machine to store the program electronically. In other words, it had software. This made programming much easier, and the instructions comprising a program were fundamentally the same as those of today.

Another important similarity is that instructions and data are held in the same memory. The store is basically a collection of bits, which can be interpreted as instructions or data (or both) as required.

Differences

Obviously the machine was much slower than current ones, about 700 instructions per second. The rules of the competition require the program to terminate (or go through a complete cycle of whatever it does if it doesn't terminate) in no more than 5 minutes, or about 200K instructions.

However, the real challenge in programming the Baby is the memory size. There is only one tube for memory, i.e. 1K bits total. The memory is organised as 32 words of 32 bits, i.e. a word is a line on the tube. An instruction occupies a whole word, so you get a maximum of 32 instructions.

At this point, you may be wondering whether it's possible to write an "interesting" program for a machine so tiny. It turns out that it is possible, but it requires a great deal of ingenuity - techniques such as modifying instructions on the fly, and using the spare space within instructions to hold data, are not only allowed but probably essential. However, even if you can't work out how to make it do more than simple sums, have a go anyway - find out what programming was like back in the early days.

The machine has a single general-purpose register, called the Accumulator. Another register, called the "control instruction" or CI performs the role of program counter. However, the CI is incremented just before the next instruction is fetched, so the target of a jump, for instance, has to be one less than the desired instruction.

An instruction consists of an opcode and, in most cases, a line number (i.e. the number of one of the 32 words) on which the instruction operates. The instructions are as follows:

STO

Store the contents of the Accumulator in the store line.

SUB

Subtract the content of the store line from the Accumulator. There is no ADD: addition is done indirectly by combining SUB and:

LDN

Copy the contents of the store line, negated, to the accumulator.

JMP

Copy the content of the store line to the CI (so the store line holds the number of the line one before we want to jump to). In modern terms, this an indirect jump, which uses up an extra store line compared to a direct jump and adds to the challenge.

JRP

Add the content of the store line to the CI. This seems odd at first sight, but it shows that they were already looking forward to larger machines, where it would be important to be able to load the same code in different places, and hence would need relative jumps.

CMP

Skip the next instruction if the content of the Accumulator is negative, i.e. a conditional branch.

STOP

Stop the machine and turn the red light on

For example, the following program finds the highest common factor of two numbers (i.e. the largest number which divides both of them):

22
0000 NUM 0
0001 LDN 30
0002 STO 29
0003 LDN 31
0004 STO 31
0005 LDN 31
0006 STO 30
0007 LDN 29
0008 SUB 30
0009 CMP
0010 JRP 27
0011 SUB 31
0012 STO 31
0013 SUB 28
0014 CMP
0015 JMP 00
0016 STP
0027 NUM -3
0028 NUM 2
0029 NUM 0
0030 NUM 3141593
0031 NUM 5214

Lines which contain data only are indicated by NUM. The numbers whose HCF we are calculating are in lines 30 and 31. Enjoy figuring out how it works!

In the binary version, the opcode is contained in bits 13-15 (the "function bits") and the line number in bits 0-4. The other 75% of each line is unused, and ignored by the instructions, so you might want to think about creative ways of using this space...

Information on how to download and set up the assembler and simulator is here

Hint: Since the simulator runs in full-screen mode at the moment, you may find it useful to take a hardcopy of this section at least. You will probably also find it easier to work from a DOS window within Windows rather than just using the Windows 'run' menu option.

The assembler takes an assembler program and turns it into a "snapshot" file, i.e. a bit pattern to load into the simulator, via a command such as:

assem -i hcf.asm -o hcf.snp

(hcf.asm is the example shown above, and is packaged with the simulator). For instance, the snapshot file in this case is:

22
0000:00000000000000000000000000000000
0001:01111000000000100000000000000000
0002:10111000000001100000000000000000
0003:11111000000000100000000000000000
0004:11111000000001100000000000000000
0005:11111000000000100000000000000000
0006:01111000000001100000000000000000
0007:10111000000000100000000000000000
0008:01111000000000010000000000000000
0009:00000000000000110000000000000000
0010:11011000000001000000000000000000
0011:11111000000000010000000000000000
0012:11111000000001100000000000000000
0013:00111000000000010000000000000000
0014:00000000000000110000000000000000
0015:00000000000000000000000000000000
0016:00000000000001110000000000000000
0027:10111111111111111111111111111111
0028:01000000000000000000000000000000
0029:00000000000000000000000000000000
0030:10011011111101111111010000000000
0031:01111010001010000000000000000000

If you then type

m1sim hcf.snp

the simulator should appear, ready to execute the program (if it doesn't, consult the README file which came with it to see if you need do something else to set it up properly)

The grid of green dashes on the left is the memory/display. The bright dashes are the bits which are set. NB: The most significant bit of each line is on the right hand end.

Most of the buttons on the right are to do with manually entering instructions/data into the store. To run the program, all you need to do is to click the switch marked "prepulse" and the program will run. In the twinkling of an eye it produces the correct answer (79) in line 30, and illuminates the "stop" light. (At least that's what should happen!) Currently, the simulator provides no mechanism to interact with a running program (effectively, anything you do just stops the program).

To change the contents of the store, you do the following.

1. Set the 'man/auto' switch to 'man' (i.e. manual).
2. To set (turn on) bits, set the 'write/erase' switch to 'write'. To reset them, turn it to 'erase'.
3. To select which line to operate on, use the 'line' switches. Remember the MSB is on the right, e.g. 00001 selects line 16.
4. Turn bits on (or off in erase mode) using the "typewriter" buttons at the top. (There are 40 of these because the machine was originally intended to have 40 bit words. The top 8 don't do anything.)
5. When the bits are what you want, go back to 'auto', followed by 'prepulse' to run the program.

The KLC switch clears the current line, and KSC wipes the whole store. The action of the switches is described in more detail in the programmers reference manual.

As an example, you could try changing the numbers in lines 30 and 31 of the hcf program, and checking that it gets the right answers with these different numbers.

Note. Currently, there is no way to save a file from the simulator, so in many cases it may be easier to simply edit the .snp file. Various other deficiencies of the user interface are being worked on - in particular at the moment it has no "quit" button, so to break out use the escape (ESC) key.

However, if you intend to have a serious shot at the competition, there are a number of further details which you will probably need to know. In this case, the programmers reference manual is your next stop.

The translation was initiated by John Sargeant on Mon Sep 29 18:29:19 BST 1997