Don Eyles Walks Us Through the Lunar Module Source Code
1–10 of 52 posts
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#2There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#3There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.
Thats line printer output. Dot Matrix was only invented in the late 60s and in any case was too slow, being character at a time.
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#4There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.
Kids, today! You have no idea how lucky you are. At the time of writing this code, there were no 32" color monitors, IDEs, code text editors, or source code management systems. Code was first written out by hand and then typed onto punch cards or paper tape. These were fed into a mainframe computer for assembly. If you made a mistake, you had to find cards (by hand), remove and replace them with corrected cards. Get the cards out of order, you were toast. In general, the only way to gain a big picture of the code was to print it out, often over and over. Needless to say, paper was in huge demand.
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#5There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.
>with no hope of doing an update
To be fair, space probes occasionally do get software updates, eg http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-...
In the case of the Curiosity Rover, it didn't even "ship" with the software of what it was supposed to do on Mars until it had landed there http://www.space.com/17034-mars-rover-curiosity-software-upg...
Edit: I'm not saying this was possible in 1969. I posted this because I was genuinely curious if it was ever done.
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#6There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.
>with no hope of doing an update To be fair, space probes occasionally do get software updates, eg http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-... In the case of the Curiosity Rover, it didn't even "ship" with the software of what it was supposed to do on Mars until it had landed there http://www.space.com/17034-mars-rover-curiosity-software-upg... Edit: I'm not saying this was possible in 1969. I pos…
Yeah, I know the modern era machines have in-the-field updates, but I assume that wasn't a feature on the Lunar Module. You need a device capable of self-programming and with the state and cost of memory at the time I would think that an impossibility at the time.
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#7Earlier quoted context omitted.
>with no hope of doing an update To be fair, space probes occasionally do get software updates, eg http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-... In the case of the Curiosity Rover, it didn't even "ship" with the software of what it was supposed to do on Mars until it had landed there http://www.space.com/17034-mars-rover-curiosity-software-upg... Edit: I'm not saying this was possible in 1969. I pos…
Yeah, I know the modern era machines have in-the-field updates, but I assume that wasn't a feature on the Lunar Module. You need a device capable of self-programming and with the state and cost of memory at the time I would think that an impossibility at the time.
We'll just include a little robot that can rethread the core rope memory!
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#8There's a link to the source code on GitHub[0], is that not the full source though? Just searching for a comment like 'hello there' from the photo[1] doesn't seem to exist in the repo.
[0] https://github.com/chrislgarry/Apollo-11
[1] https://hackadaycom.files.wordpress.com/2016/07/apollo-sourc...
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#9There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.
>with no hope of doing an update To be fair, space probes occasionally do get software updates, eg http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-... In the case of the Curiosity Rover, it didn't even "ship" with the software of what it was supposed to do on Mars until it had landed there http://www.space.com/17034-mars-rover-curiosity-software-upg... Edit: I'm not saying this was possible in 1969. I pos…
> space probes occasionally do get software updates
Sure. In 2014. Not in 1969.
I once had the very interesting experience of developing an in-place update for a mid-1980s-vintage spacecraft instrument: the magnetometer on the Galileo spacecraft. It used an 1802 processor with 2k bytes of memory and was programmed in Forth. The development system ran on an Apple II. The instrument developed a bad byte of RAM and so a patch had to be developed, but the Apple II that ran the Forth compiler had long since been decommissioned. (It was nine years between when the spacecraft was completed and when it arrived at Jupiter, three of which were a delay caused by the Challenger explosion.)
I ended up writing a complete 1802 emulator and new Forth development environment that was able to compile the original source code and reproduce what was then running on the instrument. That code ran in Common Lisp on a Macintosh II. Using that new development system, I produced a patch, which was only about a dozen bytes long. It was quite an inexpensive project by NASA standards (took about three months from start to finish with just me working on it) but the cost per byte of output code was pretty staggering :-)
Re: Don Eyles Walks Us Through the Lunar Module Source Code
#10There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.
Kids, today! You have no idea how lucky you are. At the time of writing this code, there were no 32" color monitors, IDEs, code text editors, or source code management systems. Code was first written out by hand and then typed onto punch cards or paper tape. These were fed into a mainframe computer for assembly. If you made a mistake, you had to find cards (by hand), remove and replace them with corrected cards. Get…
Also, for all but the richest programmers who had direct access to the computer, the typical experience was that you submitted your stack of cards at the end of the day and got a printout in the morning... Probably why my old programming teacher scorned our iterative approach to repeatedly stumbling upon syntax errors by hitting the 'compile' key and adding the missing commas.