There was not much to fix in this part of the code except for a few comment fixes. But I am unsure as to whether the [subroutine calls on page 36](http://www.ibiblio.org/apollo/ScansForConversion/Comanche055/0036.jpg) were left out intentionally or are just missing. Should they be added?
EDIT: Also, this closes#263
The images (with suitable reduction in storage size and consequent reduction in image quality as well) are available online at www.ibiblio.org/apollo. If for some reason you find that the images are illegible, contact me at info@sandroid.org about getting access to the (much) higher-quality images which Paul actually created.
Background
For organizatinal purposes RSB split the huge monolithic source code into smaller, more manageable chunks--i.e., into individual source
files. Those files are rejoined as "includes". The code chunks correspond to natural divisions into sub-programs. In fact, these divisions are more-or-less specified by the source code itself. Refer to the "SUBROUTINE CALLS" at the very beginning of ASSEMBLY_AND_OPERATION_INFORMATION.agc.
It may be reasonably asked why tens of thousands of lines of source are joined by means of inclusion, rather than simply assembling the source files individually and then linking them to form the executable. The answer is that the original development team had no linker. The builds were monolithic just like this.
There was a big emphasis on reusability of the code in the original project, apparently, but this reusability took the form of inserting your deck of punch-cards at the appropriate position in somebody else's deck of punch-cards. (Actually, I think the card-decks were turned into tape libraries, and the modules were mixed-and-matched from the tape libraries, but the principle is the same.) So, indeed, the method of file-inclusion is a very fair representation of the methods used in the original development...with the improvement, of course,
that you no longer have to worry about dropping the card deck. On the other hand, I (RSB) wasn't there at the time, so I may have no idea what I'm talking about.
Finally, note that the original Apollo AGC assembler (called YUL) is no longer available (as far as I can tell). Actually, it had already been replaced by another assembler (called GAP) by the time of Apollo 11, but GAP isn't available either. The replacement assembler yaYUL accepts a slightly different format for the source code from what YUL or GAP accepted, so the source code has been targeted for assembly with yaYUL.
What follows is simply a bunch of file-includes for the individual code chunks. The page numbers have been marked to make proof-reading easier. The page images also contain a lot of interesting tables (cross-referenced to page numbers) created by GAP, but not duplicated by yaYUL, so it's still valuable even if the source-files listed below are in hand.
c3f93c3ccf
