The basic machine had 4 Kbytes of core memory - the memory modules were 4K x 40 bits, of which one bit was used as a parity check. Core memory was pretty reliable, but the occasional bit did drop, so it was wise to know if it happened in your program! You could purchase an upgrade to 8 Kbytes, which many customers did. There were other upgrades, which I'll come to later.
The programmer saw a memory of 4K or 8K 39-bit words of memory. If you only had 4K, addressing above 4095 would wrap around!
The first 4 words of memory were not accessible to the programmer. If you wrote to them, nothingn happened, if you read them, you got zeros. If, however, you tried to execute them, you got the basic program loader instructions! This was the way that you started things off. Set the address to zero, and run! I'll go into the loader later for those who want to know more....
The 39 bits of a words allowed you to store integers between -274877906944 and +274877906943, floating point numbers ranged from approx -5.79x10^76 to +5.79x10^76, with the smallest absolute value of about 2^-257. This was considered to be sufficient for any calculations and there was no provision for double precision working. The floating point instructions were another optional extra. If you didn't have the FP Option installed, the instructions just acted as a no-op.
A word was also used to store two instructions. This might seem strange as there are an odd number of bits. Each instruction took 19 bits, and the odd bit (in the middle of the word) was reserved for a special function and was referred to as the B-bit. Each instruction consisted of an opcode (6 bits) and an address (13 bits). With 13 bits in the address, this imposed the upper limit of 8K (8192) words of memory.
The 64 opcodes divided up nicely into groups of 8 and were referred to by the octal number defined by then 6 bits. The 8 groups were referred to as Group 0 opcodes, Group 1 opcodes, etc. Groups 0 to 3 are integer operations involving a memory location and the accumulator. Group 4 are the branch or jump instructions, Group 5 are the extended integer instructions, such as shift, multiply and divide, Group 6 are Floating Point instructions and Group 7 are the I/O instructions. These opcodes are described in some detail here.
Execution of the instructions proceeded in a fairly straightforward manner. The first instruction, the one at the most significant end, in a word was executed first, then the second instruction. The machine then moved on to the next word. There were two exceptions to this: if an instruction from group 4 was executed, and the relevant condition was satisfied, then the next instruction would be taken from the location specified by that instruction. Group 4 instructions are what are usually referred to as jump or branch instructions. The only other possibility was if an interrupt occurred. In a normal 803B this never did occur, so I'll not go into details, but this was used by the film handler to signal that an operation had completed, and could, in theory be used by other non-standard devices if the need arose.
The I/O instructions were strictly deterministic, as was usual at the time. If an I/O operation was executed and the device was not ready, the whole system would hang until it was ready. If the device could not be made ready, the only way out was a hard reset, and start again!
Unlike other machines, in which index registers are used, the modification affects both the address and the opcode. This can be quite useful, once you understand what you are doing, but must be treated with respect as many a novice programmer discovered to his cost! It is important to realise that you must never branch to the second instruction in a word with the B-bit set. I've never managed to figure out exactly what does happen, but it's usually catastrophic from the programming point of view. You must always execute the first instruction in the word, as the result of that instruction is kept internally to effect the modification.
When I get a few more spare minutes, I'll add some details of the boot loader which should provide an interesting example of the devious machine code employed by the 803.
Last modified: 17/07/2003