Colossus 237: Apollo 8 Flight Software(github.com)
github.com
Colossus 237: Apollo 8 Flight Software
https://github.com/virtualagc/virtualagc/tree/master/Colossus237
8 comments
Serious question: how can we go about making archaic programming languages and dialects of assembly more accessible?
There are all these cool, historically significant programs that are open-sourcing: DOS, this, etc. Is there any way to expose the general program structure and algorithms so that they're easier to analyze without learning the specific language they're written in?
There are all these cool, historically significant programs that are open-sourcing: DOS, this, etc. Is there any way to expose the general program structure and algorithms so that they're easier to analyze without learning the specific language they're written in?
"Is there any way to expose the general program structure and algorithms so that they're easier to analyze without learning the specific language they're written in?"
No. They are full of crazy shit. Like loading an instruction to a CPU register, and then executing and modifying that register (to speed up IO-operation perhaps?).
No. They are full of crazy shit. Like loading an instruction to a CPU register, and then executing and modifying that register (to speed up IO-operation perhaps?).
Long shot, but any sources which accounts the "crazy shit" engineers used to do back then?
Well the Apollo Guidance Computer for example had "magic numbers" aka memory addresses where CPU registers were visible. Probably easy task to find jumps to those addresses, if any.
Anyways they would have been much faster to execute than "rope memory", good for IO-intense operations like Moon Landings.
Anyways they would have been much faster to execute than "rope memory", good for IO-intense operations like Moon Landings.
"magic numbers" aka memory addresses where CPU registers were visible
Anyone who has done some amount of programming with microcontrollers like the 8051 or the Microchip PIC will not find such things unusual; when everything is integrated into one unit, the difference between a register and a memory location decreases.
Of course, if all you've ever known of are the bland RISCs they love to teach in CS courses, then all this is very weird and foreign to you... but it's just a natural consequence of how the hardware was designed.
As such, I do recommend glancing around the documentation for actual computers, from 4-bit microcontrollers to 50s and 60s mainframes, to familiarise yourself with the overwhelming diversity of existent computing devices.
Anyone who has done some amount of programming with microcontrollers like the 8051 or the Microchip PIC will not find such things unusual; when everything is integrated into one unit, the difference between a register and a memory location decreases.
Of course, if all you've ever known of are the bland RISCs they love to teach in CS courses, then all this is very weird and foreign to you... but it's just a natural consequence of how the hardware was designed.
As such, I do recommend glancing around the documentation for actual computers, from 4-bit microcontrollers to 50s and 60s mainframes, to familiarise yourself with the overwhelming diversity of existent computing devices.
That's a pretty advanced assembler for the day. Float constants and all.
(The issues are for the virtualagc simulator, and include such wonders as correctly emulating processor loads so that you too can have program alarms flash up when you're trying not to crash into the moon)
Also, if you liked type-in programming in the 1980s... :D