Assembly Code That Took America to the Moon Now Published On GitHub (qz.com)

An anonymous Slashdot reader writes: "The code that took America to the moon was just published to GitHub, and it's like a 1960s time capsule," reports Quartz. Two lines of code include the comment "# TEMPORARY, I HOPE HOPE HOPE," and there's also a quote from Shakespeare's play Henry VI. In addition, the keyboard and display system program is named PINBALL_GAME_BUTTONS_AND_LIGHT, and "There's also code that appears to instruct an astronaut to 'crank the silly thing around.'"

A former NASA intern uploaded the thousands of lines of assembly code to GitHub, working from a 2003 transcription made from scans inherited by MIT from a Colorado airplane pilot, and developers are already using GitHub to submit funny issue tickets for the 40-year-old code -- for example, "Extension pack for picking up Matt Damon". Another issue complains that "A customer has had a fairly serious problem with stirring the cryogenic tanks with a circuit fault present." Because this issue succinctly describes the Apollo 13 mission in 1970, the issue has been marked "closed".

Comments

development environment?

[4wdloop]

What did they use to develop the software? And even more interesting how did they test it? The must have had some simulators, probably both software and hardware based?

Re:development environment?

[angel'o'sphere]

They did not even have version controll at that time!

The main reason to develop source code control software came from the fact that the Apollo developers fucked up so often. No pun intended. They worked with back ups etc. and often stuff got lossed or mixed together wrongly.

Re:development environment?

[batkiwi]

I think you have the terminology 100% backwards.

You are not really a LOW level programmer if you freak out with no IDE or libraries. If you're writing the sort of code presented here I'd say you can easily call yourself a Systems Engineer or Software Engineer (unlike 99% of the people who call themselves a Software Engineer).

However, if you feel the need to write assembly, use code quirks to eek out 1% more performance, and write your own libraries then you have no place in modern high level software development, excepting if you're writing drivers, video games, or embedded code. Anyone doing that sort of BS is likely very smart, but is also a liability to any non-toy project.

Re:development environment?

[thinkwaitfast]

It's not always about 1% more performance. For a lot of specialized MCU's, there is no other language. Assembly is not that difficult and for control systems, I've never seen complex code. It's always:

start: ;; start of frame

if overrun == 1 ; check for frame overrun

goto frame_err

overrun = 1

read value1 ; read all data at start of 10ms frame

read value 2

...

read valuen

output1 = 2*value1

...

outputn = 4.17*valuen

write output1, output2, ..., outputn

wait for interrupt

read radaltswitch

if radaltswitch == 1

call procradalt

overrun = 0 ; clear frame dirty bit

for(;;) ; wait for interrupt to return to start:

Not much optimization to be done. Not a difficult piece of software, even in assembly

Idiots. Idiots everywhere.

[Anonymous Coward]

Unfortunately, with the amount of coverage that this is getting in the geek sphere, the Dunning-Kruger Effect is in full force. So far, just today, I've seen:

- Someone trying to look into the code who had apparently never encountered a .s file before, and
- Some (judging by his name) Indian guy who had apparently never heard of the term "attitude" in relation to flight control, and submitted a pull request to change it to "altitude".

Idiots. Idiots everywhere.

Re:Idiots. Idiots everywhere.

[theurge14]

We'll never get into space with that kind of attitude!

Re:Idiots. Idiots everywhere.

[thinkwaitfast]

This code has been available for a long time. I downloaded it and got it to run in the simulator about ten years ago. I think I probably even read about it first here on slashdot. It was on some guy's website. He even built a copy of the original hardware.

good code too

[phantomfive]

The mathematical sections tend to be better, well defined, well commented, and well-written code.

Re:good code too

[Lumpy]

And remember they did ALL OF THIS with integer only math and NO freaking math libraries.

Want to drive a fre grad programmer nuts? have him convert celcius to Farenheit and Kelvin with 4 decimal places of accuracy using only integer math on an 8 bit micro, no you can not use ANY libraries at all, and you need to do it in less than 6 lines of code.

Most shit themselves.

Re:good code too

[angel'o'sphere]

Actually likely not 'integer' but fixed point math.

The first time I saw one creating a table with 360 entries one byte big and storing precalculated sinues values in that table (remember: 1 byte big, so 127 means '1' and 128 means '-1' and the other values are 'fractions' between -1 and +1) I told myself: WTF! That was on an 6502 around 1985 in a small math library used in a game.

Re:good code too

[phantomfive]

and you need to do it in less than 6 lines of code.

Is that possible?

Re:good code too

[Anonymous Coward]

That is, indeed, a WTF; you only need to store 45 degrees, the rest can be trivially calculated from that. Also, this means you could store the precalculated table as 16-bit (or even 32-bit) integers, yielding much more accurate results, and still save space.

This isn't really uncommon in embedded systems.

Re: good code too

[batkiwi]

A lookup table is the solution I'd use for that sort of problem, but if you're counting the lookup table as 1 line of code then you're sort of going against the spirit of the challenge.

Re:good code too

[ncc74656]

Want to drive a fre grad programmer nuts? have him convert celcius to Farenheit and Kelvin with 4 decimal places of accuracy using only integer math on an 8 bit micro, no you can not use ANY libraries at all, and you need to do it in less than 6 lines of code.

Depends on the architecture. Try doing that in less than 6 lines when you don't have multiply or divide instructions in the CPU. You might not necessarily need to code up general-purpose multiply and divide routines (especially if you're dealing with constants...multiply by 9 with three left shifts and an add, for instance), but I suspect there are few (if any) 8-bit architectures that will do what you want within your constraints. The 6502 certainly won't.

Re:good code too

[Anonymous Coward]

Lame. A full circle is 256 entries, not 360.
Allows you to add angles together without boundary check and you can easily mirror angles.
There is no real reason to stick with 360 degrees circles, if necessary you can step up to 512.

Re:good code too

[thinkwaitfast]

It's commonly called scaled integer. Except with angles, then it's SAF, for scaled angle format. Wraparound @360 is handled very cleanly.

Re:good code too

[thinkwaitfast]

I worked on a system with about a dozen different angle formats, depending on who was using the data...SAF8, SAF11, SAF13,...

Related: Lunar Module paper source listing

[jbdigriz]

Don Eyles walks us through the Lunar Module source code