The way it was implemented in the ICBM world was that you had six fellows sitting around a table designing the mathematical routines and overall architecture, the program components detailed coding, and the computer hardware all at the same time. Five lines of code per day was considered a good day's work. Most of the time was spent arguing about whether to do something with hardware or software. Integrated circuits had advanced to the point of four-bit registers being available. They were used for the cpu's two registers.

There was no addressable memory in the system I worked on. Just a disk with a bunch of fixed heads. The code was clocked to the disk. There was an upper and lower bus and two registers of one word length, but it was a big word.

There ended up being four programs that could be swapped using remote data change. Only one was for flight, the others were ground programs.

Hardware did most of the work, things like 3 x 3 matrix math were done with a few microcode instructions that resulted in a new matrix replacing an old one in the same location on the disk.

The cpu often had areas that weren't being used during these longer intructions, so they could sneak little additions/subtractions/multiplications/divisions in the middle. These intructions only switched small pieces of the cpu, and there were LOTS of instructions available. You just had to make sure everything was in the right place on the disk so that it was available when there was a bit of free time. They had five different instructions for dividing two numbers, differing only in the route and timing of the process within cpu to avoid colliding with other ongoing computations. A lot of the bookkeeping functions got done this way.

The really fun part was that you could start a long instruction before you had all the numbers to complete it. While it was grinding on the front end, you could initiate an addition operation and leave it in a register for the long instruction to find later. You might even be able to write it to the disk. These were a real joy to trace and debug.

The nav computer had to drive three output signals to steer the rocket. It knew nothing about staging or anything else. It had a table that said it should see accelerometer counts of x,y,z at time t (accumulated pulses equaled accelerometer axis velocity). It compared the actual counts to the preprogrammed table and calculated new steering signals.

The bottom line is that the programmers had a pretty limited goal and had a complete map of the cpu in their head and could follow the entire cpu operation in their head as the program components were executed.

I wasn't in on the design phase, but was trained on the cpu and microcode by one of the guys that sat at the table.

The way it was implemented in the ICBM world was that you had six fellows sitting around a table designing the mathematical routines and overall architecture, the program component's detailed coding, and the computer hardware all at the same time. Five lines of code per day was considered a good day's work. Most of the time was spent arguing about whether to do something with hardware or software. Integrated circuits had advanced to the point of four-bit registers being available. They were used for the cpu's two registers.

There was no addressable memory in the system I worked on. Just a disk with a bunch of fixed heads. The code was clocked to the disk. There was an upper and lower bus and two registers of one word length, but it was a big word.

There ended up being four programs that could be swapped using remote data change. Only one was for flight, the others were ground programs.

Hardware did most of the work, things like 3 x 3 matrix math were done with a few microcode instructions that resulted in a new matrix replacing an old one in the same location on the disk.

The cpu often had areas that weren't being used during these longer intructions, so they could sneak little additions/subtractions/multiplications/divisions in the middle. These intructions only switched small pieces of the cpu, and there were LOTS of instructions available. You just had to make sure everything was in the right place on the disk so that it was available when there was a bit of free time. They had five different instructions for dividing two numbers, differing only in the route and timing of the process within cpu to avoid colliding with other ongoing computations. A lot of the bookkeeping functions got done this way.

The really fun part was that you could start a long instruction before you had all the numbers to complete it. While it was grinding on the front end, you could initiate an addition operation and leave it in a register for the long instruction to find later. You might even be able to write it to the disk. These were a real joy to trace and debug.

The nav computer had to drive three output signals to steer the rocket. It knew nothing about staging or anything else. It had a table that said it should see accelerometer counts of x,y,z at time t (accumulated pulses equaled accelerometer axis velocity). It compared the actual counts to the preprogrammed table and calculated new steering signals.

The bottom line is that the programmers had a pretty limited goal and had a complete map of the cpu in their head and could follow the entire cpu operation in their head as the program components were executed.

I wasn't in on the design phase, but was trained on the cpu and microcode by one of the guys that sat at the table.