Comment by jonstewart
14 hours ago
The Apollo Guidance Computer had 4KB of RAM and 16KB of ROM. Can you write a scheduler that would execute 8 programs related to landing on the moon in 4KB?
14 hours ago
The Apollo Guidance Computer had 4KB of RAM and 16KB of ROM. Can you write a scheduler that would execute 8 programs related to landing on the moon in 4KB?
An asynchronous scheduler with task priority, interrupts, and real-time response. That goes on a spaceship with less than 70 Watts of power available for the computer. That weighed about 70 pounds. When there has never been that sort of a multi-tasking computer controlled avionics before.
At a time when the contemporary computer systems that used asynchronous, priority-scheduled multitasking operating systems were things like IBM OS/360 mainframes and DEC PDP-6/PDP-10 minicomputers.
It was like having an Apple II in mid 1960s with double the word size.
I used san RTOS written in assembly for the Atmel AVR. AvrX (by John Barello)
You can look at the code here.
https://github.com/kororos/AvrX
Compiles down under 2k.
The thing is while actually doing that isn't crazy hard, they did that with hardly any existing examples to go by. And without modern tools.
And with a ROM that had to be hand sewn. No flash updates, just "little old ladies" working in a former bra factory for a defense contractor (and huge tax payer expense if any mistakes needed to be debugged).
Yes.
Every 1970s videogame has some sort of scheduler that moves actors, draws the screen, and play sound. Depending on the computer, it might be very easy (some could interrupt when the VDP got to a specific spot) or require you to count cycles. If, for instance, your game is for an Apple II and you have background music, you need to hit the speaker at the frequency of the currently playing note WHILE you move things, do physics, and redraw the screen. And you need to count cycles, because there is no reliable counter you could use (I remember how awesome it'd be if I could write 0 to a memory location and read it later to know how many clock cycled passed, or one I could read to get which scan line of the image the video hardware was outputting).
And it ran at 0.043 MIPS. Each task would get maybe 5000 instructions per second, minus scheduler overhead.
I mean, the implementation can be incomprehensibly impressive, but as an example of “man-rated” — being sufficiently robust — rejecting the request would be sufficient and I suspect this was an obvious place to have some kind of handling for. If there were no handler of any kind in this position, it’d be unforgivable in modern, far less robust software.
The kind of example for man-rated I was expecting would be dealing with really nutty edge cases (perhaps like correctly operating under arbitrary bitflips) or the LISP recovery system from Deep Space 1.
Handling an expected error condition under normal operation is not, in my mind, a good example of man-rated robustness. It might be a good example of other things.
You make it robust by making it simple. Simple to implement, simple to reason about, and simple to debug. They were not only programming an existing computer, they were also more or less defining the computer and this allows some hardware-software co-evolution. In cases like these, the hardware is frozen well before the software is close to ready, so you might need to do some workarounds.
> Handling an expected error condition under normal operation
Nothing in the Apollo program was "normal operation" by any standard. The thing is the alarm elegantly - and correctly - handled a situation that should never have happened in the operation, that only happened because the simulators the procedures were developed against did not accurately account for the workload of having both docking and landing radars on at the same time (IIRC, this was the issue).
This kind of robustness in the face of unexpected misuse is required if you want to qualify your hardware as "man-rated".
That’s the missing bit in the original post; if exactly 7 tasks was intended to ever be possible to run (as in, it logically doesn’t make sense for an 8th to exist), and they tossed in a scheduler anyways, then that’s man-rated thinking.
I had read the setup as the 8th task being user error (you have 20 things to do, I can only run 7 at a time, and it’s an user error to submit the 8th task while the 7 are running)