Contents

• What is the Launch Vehicle Digital Computer (LVDC)?
• Peripheral Devices
• Saturn Interaction with the AGC
  
• LVDC Documentation
• LVDC Software
• Overall Structure
• Preflight Program
• Executive Control Program
• Flight Program in General
  
• AS-206RAM Flight Program Specifically
  
• Architecture of the LVDC
• References
• General Characteristics of the Computer
• Layout of Memory Words
• CPU Instructions
• I/O Ports (for PIO Instructions)
• Subroutine Linkage
  
• Interrupts
• Telemetry
• Up-data
  
• LVDC Assembly Language
• Basic Factoids
• Preprocessor Pass
• Assembly Pass
• Program Structure
  
• MIT Instrumentation Laboratory vs IBM Federal Systems Division
• yaLVDC, the LVDC CPU Emulation
• yaASM.py, the LVDC Cross-Assembler
• Plea for Data
• Homage
  

What is the Launch Vehicle Digital Computer (LVDC)?

Peripheral Devices

• The Launch Vehicle Data Adapter (LVDA) interfaced the LVDC's digital signals to the analog world of the Instrument Unit's sensors.  Actually, the LVDA is so closely coupled to the LVDC that it may make more sense to consider them as forming a single unit, though packaged separately.
  
• The ST-124-M Inertial Platform Assembly—catchy name!—was an inertial measuring unit that supplied the LVDC with information about the rocket's orientation and acceleration.  It had 3 integrating accelerometers that measured acceleration with respect to the stable (space-fixed as opposed to rocket-fixed) platform, as well as angular sensors to measure the orientation of the stable platform with respect to the rocket.  Like the AGC IMU, it was a 3-gimbal system and therefore theoretically subject to "gimbal lock", but because the range of motion of the rocket during the burn phase, I suppose that avoidance of gimbal lock must have been somewhat easier than in the CM or LM.
  
• The "Control Computer" or "Flight Control Computer" was an analog computer that translated attitude-correction commands, angular change, and vehicle lateral acceleration information into propulsion-system thruster nozzle and/or engine actuator positioning commands.  As such, it is of little interest in simulation of the LVDC (which is our primary concern at Virtual AGC).   If the naming of this device seems odd, note that it follows the general convention of the word "control" being defined to mean the execution of an action that has been decided upon elsewhere, and not the act of decision-making.
  
• The Control-EDS Rate Gyros.
• The Control Accelerometers (Saturn IB only).
• The propulsion engine actuators.
• The auxiliary propulsion system.  This was a set of 6 nozzles mounted on the aft end of the S-IVB stage which were used to provide attitude control in coasting (non-burn) periods.  I believe that it may also have provided roll control during the S-IVB turn during boost.  (The engines of the S-IC and S-II stages could provide complete pitch/yaw/roll control, but the engine of the S-IVB state could only control pitch and yaw, and therefore needed to be supplemented to provide control of roll.)  The auxiliary propulsion system was directly controlled by the Flight Control Computer, but the Flight Control Computer was commanded by the LVDC.
• Telemetry downlink.
• Command uplink.
  

and for the Saturn V:

Saturn Interaction with the AGC

The LVDC and the AGC did not actually have any direct interaction, so we may as well talk about how the AGC interacted with the Saturn before immersing ourselves in too much detail about the LVDC.

If you look at either of the graphics at the end of the preceding section, you'll see the four ways that the Instrumentation Unit (IU) in the Saturn IVB and the Spacecraft (i.e, the Command Module) — which are separated by a horizontal dotted line near the tops of the two graphics — interacted:

1. The Abort Decision signal.
2. The Status signal.
3. The Mode Command signal.
4. The Alternate Steering Commands signals.

The Saturn was always steered by the so-called Flight Control Computer (depicted in the picture at the right), an analog computer whose salient characteristic for our purposes is that it was not the LVDC.  However, the flight-control computer did not operate on its own, and thus itself needed to be supervised.  Normally, that supervision was performed, by default, by the LVDC, indirectly through the LVDA, the Launch Vehicle Data Adapter.

However, it was also possible for the spacecraft to send the flight control computer a signal, the Mode Command, which instructed it to accept Alternate Steering Commands from the AGC rather than the default steering commands from the LVDC/LVDA.  Thus, the AGC could steer the Saturn IVB (but not some of the other Saturn stages) by this mechanism.

Of course, it was also desirable for the spacecraft to be able to monitor the activity of the Saturn, even under normal conditions when the LVDC was controlling the rocket.  Since the spacecraft had its own Inertial Measurement Unit (IMU), it knew its own orientation and acceleration — and hence the Saturn's — at all times, and the AGC could integrate these quantities to know the velocity and position at all times.  Thus it was not necessary for the IU to communicate that information to the spacecraft in order for the AGC to monitor the physical motion of the rocket and to display it for the astronauts on the DSKY.

I actually have an interesting graphic of the monitoring process to show you.  This graphic is not from physical system.  Rather, Riley Rainey has used the "equation defining document" which specified how the Instrumentation Unit (IU) was supposed to behave, to model the physical behavior of the rocket and the spacecraft's IMU, allowing Virtual AGC to monitor the launch behavior on a simulated DSKY.  Here's a short movie he has created of that simulation.  It's admittedly a little fuzzy, since I blew it up by about 2×, but perhaps we'll be able to get a better one sometime in the future:

Of course, at the left in the video, you can see the simulated FDAI and DSKY.  At the right, you can see telemetry from the AGC.  You'll notice that at the beginning of the movie, the DSKY's UPLINK indicator is on.  That's apparently because Riley's simulated DSKY (which is his own, and not the simulated DSKY we provide) isn't fully functional in the sense of accepting keypad input, so Riley is instead feeding the AGC commands via the digital uplink.

LVDC Documentation

LVDC Software

Overall Structure

Describing the overall structure of the software loaded into the LVDC is a bit tricky at the present time.  That's because documentation is scarce, our cache of original LVDC software is sparse, and the original development process seemed quite compartmentalized.  By the latter, I mean that programmers concentrated on the specific areas to which they were assigned, and often seem to have had little cognizance of even the most basic features of the software when those features happened to be outside their narrow specialization.  Plus the set of LVDC programmers available to me is limited, so I don't have representatives of all of those specializations to consult with.

In short, important aspects of my descriptions in these sections concerning the gross structure of  the software are based on my own inferences and on the recollections of developers unfamiliar with the details.  So my comments about the program structure with a large grain of salt.

With that said, let's contrast the overall structure of the LVDC code vs the software source code for the Apollo Guidance Computer (the programs COLOSSUS, LUMINARY, and so on) and for the Abort Guidance System.  All of these non-LVDC programs were monolithic in nature.  What I mean by that is that although the AGC and AGS software was structured into various semi-independent sections, for which the development of each was presided over by specialists in those specific areas, the source code for them was nevertheless presented to the programmers in a single large chunk — i.e., a single, unified program listing.  Every AGC or AGS developer saw the entire source code, regardless of whether it pertained to them or not.  The natural result was that it was possible (and even likely) for an AGC or AGS developer to have some grasp of the large-scale structure of the software, beyond his or her own narrow area of specialization.  Similarly, every word stored in the AGC or AGS core memory came from that source code.  In that sense, each AGC or AGS program listing was entirely self-contained.  If you were able to assemble those program listings, then you obtained a rope image that could be loaded into the computer and run.  Conversely, every word in core-memory either came directly from the associate program listing or from some action taken by the code in that program listing.  When you look at a program listing for (say) LUMINARY, you see the entire contents of the Lunar Module's AGC's core memory.

The overall structure of the LVDC software, however, is fundamentally different.  Simultaneously loaded into the LVDC core memory were several different logically-distinct "programs", each with different sets of source code, assembled separately from each other, and having different areas of specialization.  Thus assembly of any given one of these programs did not produce a full core-rope image: merely a partial rope image.  A full rope image could be obtained only by merging all of the partial core-rope images from the different assemblies of the several sets of source code.  The separate programs I'm aware of are discussed individually in the sections that follow, but in brief, they were:

• The Preflight Program
• The Executive Control Program
• The Flight Program
  

A similar situation arises in modern computer systems, where you typically have an "operating system" program and "application programs" running in the computer at the same time.  The application programs rely on the operating system for certain functionality, but have no understanding of how the operating system provides that functionality.  All the application program needs to know is the exact method for requesting the desired function from the operating system.  Similarly, the operation system stands ready to provide the desired functionality, but has no knowledge of the internal workings of the application program requesting service.

In the LVDC, the method by which interaction between independent but simultaneously-loaded programs worked was for there to be an agreed-upon set of specific memory addresses hard coded into the programs.  For example, one program would know that to obtain a certain type of service, it had to call a routine at a certain fixed address in memory.  Another program would know that it had to put code providing certain types of services at certain fixed addresses, but have no other knowledge of the program(s) utilizing that functionality.

Because of this much higher degree of compartmentalization, programmers working on (say) the Flight Program might have no cognizance at all of the Preflight Program, the developers of which might have no cognizance of the Executive Control Program, and so on.  And unfortunately, that means that we don't, either.

Preflight Program

I don't know anything at all about the Preflight Program at present.  I.e., there is no surviving documentation or source code for it as far as I know.  I will provide information about it if/when it becomes available.

As it relates to the AS-206RAM Flight Program, however, I do have a couple of reasons to believe that the AS-206RAM Flight Program would have been used in conjunction with a Preflight Program:

1. In the AS-206RAM Flight Program (1967), there are jumps to various memory locations in regions of core memory at which AS-206RAM itself does not define any code or variables.  It stands to reason that something is stored there.  This is discussed in more detail below.
   
2. One of the original LVDC software developers (thanks, Pat Woods!) tells me that he believes that the Flight Program shared memory with a Preflight Program that ran before liftoff.

Executive Control Program

Original LVDC software developer Pat Woods tells me that there was no Executive Control Program (ECP) in use until the Apollo 12 mission.  This anecdotal information is backed up by the fact that the Saturn Launch Vehicle Astrionics Systems Handbook has 14 pages of descriptive material about the ECP in its November 15 1969 release (see section 11.2.1 in particular), but does not even mention the ECP at all in its November 1 1968 release.

I won't describe the ECP further here, since we have no source code for it, but if you are interested you should consult the later release of the Astrionics Systems Handbook mentioned above.

It is unfortunately not clear from the description whether the ECP constituted a program separate from the Flight Program with which it was used — i.e., whether it had a separate set of source code that was assembled separately from the Flight Program — or whether the two had an integrated code base that was assembled as a single operation.

Flight Program in General

The software was apparently known simply as the Flight Program, and didn't have a catchy name such as "Luminary".

You may also see references to the Generalized Flight Program (GFP) or generalized Flight Program System, in use from Apollo 12 onward.  You may recall from the preceding section that the Executive Control Program also came into use from Apollo 12 onward.  My supposition would be that this simply means that

GFP = ECP + FP

AS-206RAM Flight Program

The basic purpose of the Apollo Saturn 206 S-IVB Restart Alternate Mission is to place the S-IVB stage into orbit and test its restart capability, simulating the AS-501 mission profile. In the event S-IVB restart problems occur in the early Saturn V flights, this mission will be flown to help correct or solve the problems. The primary objective of the SA-206 Launch Vehicle is to insert the S-IVB/IU/Payload configuration into a near earth 100 nautical mile circular orbit. The payload consists of a Spacecraft LM Adapter (SLA) and a 25° Nose Cone (NC #2).

As it happens, the source code from the assembly-listing printout has been entirely transcribed into machine readable form.  That's a lot more convenient to deal with that scanned page images, since you can do things like text searches on it, or even assemble it using the nifty new LVDC assembler I've written (see below).  The problem, of course, is that the transcribed source code is just as much subject (or hopefully, it will eventually turn out, not subject) to ITAR export restrictions as the scanned images are, so this LVDC source code is not presently available in our software repository.

     

   

   

The middle group of pages above shows a few auxiliary subroutines for computing the sine, cosine, arctangent, and spare root functions, plus a 3×3 matrix-multiply routine.  Note that these are some of the very algorithms described in section 13 of the EDD (LVDC Equation Defining Document), so the source code can actually be compared to the defining documentation if one so desired.  The two images at the top show an area of the program where some constants are defined, while the two at the bottom show a portion of the assembly listing's cross-reference table. 

• ... prior? ...
  
• AS-501 (Apollo 4)
  
• AS-502 (Apollo 6)
  
• AS-503 (Apollo 8)
  
• AS-504 (Apollo 9)
  
• AS-505 and 506 (Apollo 10-11)
  

Regarding preloaded constants for LVDC memory, all missions (I think!) were associated with a report called the "launch vehicle operational flight trajectory", and these documents (among other things) listed the LVDC preload settings.  Unfortunately, most of these reports are presently unavailable, though we do have a few of them.  For example, the AS-202 report says that "LVDC symbol" T_1i, the time-to-go for first IGM stage, is preloaded with 299.25 sec, while Vex₁, the J2 exhaust velocity for first IGM stage, is loaded with 4165.45 m/sec, and so on.

Finally, I claimed earlier that the AS-206RAM Flight Program is not, of itself, a complete program.  In that assessment, I'm not referring to the fact that when you try to assemble it you find that there are a few missing symbols, associated with variables that haven't been allocated.  That problem is simply due to the fact that the listing we have is an engineering version of the code that had never been debugged to the point of being released.  It's quite easy, I think, to fix up the assembly-time errors and warnings in the AS-206RAM so that it assembles error-free, and is entirely self-contained in that sense.  But it is still not complete in the larger sense I mean.

Rather, when I say that AS-206RAM is incomplete, I mean that it references code at specific hard-coded addresses which are not defined by the AS-206RAM program.  Indeed, there are large areas of core memory left undefined by the program.  Even the location in memory at which the power-up entry point should be stored is left undefined.  But for example, consider the concrete example of the code necessary for processing commands uploaded to the LVDC from mission control, as described in the Up-data section of this web-page.  When such a command is uploaded to the LVDC, an interrupt occurs.  The software then looks in an interrupt-vector table, which appears on p. 207 of the program listing, and looks like the following:

In other words, the interrupt-service routine for a command-upload is in memory module 4, sector 17, and its entry point is syllable 1 of location 267.  Similarly, the data-memory environment associated with that interrupt-service routine is module 4, sector 17.

And yet ... the source code contains no code in module 4, sector 17.  Indeed, module 4 sector 17 does not even appear at all in the octal listing of the assembled AS-206RAM code.  Some initialization routines do actually dynamically initialize a handful of constants in that sector, but they certainly do not seem to put any code at those locations. 

Thus if a command-upload interrupt were to occur, the result would be that the software jumped into the middle of a no-man's land of uninitialized memory.  And it's not just the command-upload interrupt, you can see from the image above that other no-man's-land jumps could occur as well:  to the self-test program, to the hardware evaluation program, or upon telemetry-station acquisition.

My inference from all that is that there is a separately assembled program which provides the code in those locations, and as discussed earlier, the best candidate for that at the moment is the Preflight Program ... for which we have no source code and no description whatsoever.

That's not to say that AS-206RAM cannot be run.  One workaround for this specific problem is to simply modify the interrupt-vector table to contain a HOP HCIRTN instruction in place of the HOP HCCMDC instruction it contains now.  Another workaround would be to simply disable the command-upload interrupt.  But alas, that's just one example of the potential range of problems the missing Preflight Program might cause.  Until a complete survey of all jumps into no-man's land is made, it's impossible to know yet whether all of them can be worked around so easily.

Architecture of the LVDC

References

1. 1 October 1963:  Apollo Study Report, Volume II, which was part of IBM's feasibility study for using the LVDC in place of the AGC in the LM and CM.
2. 31 October 1963:  IBM's Saturn V Guidance Computer, Semiannual Progress Report.
3. 30 November 1964:  Laboratory Maintenance Instructions: Saturn V Launch Vehicle Digital Computer, Simplex Models, Volume I: General Description and Theory.  This is IBM's documentation for the LVDC "breadboard model II" system.  (I'm not presently aware of any existing documentation of the production "TMR" LVDC.) 
   
4. 1 February 1966:  "The Astrionics System of Saturn Launch Vehicles" by Rudolf Decher.
5. 1 November 1968:  Astrionic System Handbook, Saturn Launch Vehicles, chapters 11 and 15.
6. 1 November 1968:  Saturn Flight Manual, SA-503, chapter VII, particularly data on interrupts and i/o.
7. 30 September 1972:  Skylab Saturn IB Flight Manual, chapter VI, again for data on interrupts and i/o.

General Characteristics of the Computer

The illustration above shows a simplified block diagram of the LVDC.  The device itself was designed and manufactured by IBM Federal Systems Division.  Mechanically, the LVDC had dimensions of about 29.5"×12.5"×10.5", and weighed about 72.5 pounds.  A number of different power supplies were needed:  +6V, -3V, +12V, and +20V, at roughly 150W. 

However, the LVDC and the Launch Vehicle Data Adapter (LVDA) really operated as a pair, and neither is of use without the other, so in considering the mechanical and electrical characteristics of the LVDC one really needs to include those of those of the LVDA into their thinking.  The LVDA had dimensions of about TBD"×TBD"×TBD", and weighed about 214 pounds.  Its electrical budget was about 320W and it accepted +28V power.  The purpose of the LVDA was basically to intermediate between the LVDC and the remainder of the rocket.

In computer terms, LVDC had the following characteristics:

• The computer was triply redundant, with 3 identical circuits conforming to the block diagram shown above.  There was a "voting" circuit not shown, and any two of the 3 sub-systems could outvote the other on every output control signal.
  
• Memory was ferrite core and was entirely RAM.  In other words, there was no ROM memory as there was in the AGC.  This meant that the flight program could theoretically be changed much closer to flight time than could the program of the AGC, but it also meant that the program contained within the computer could be destroyed much more easily than with the AGC.  (But remember, the operating life of the LVDC was very short compared to that of the AGC.)  Actually, reading RAM based on ferrite cores is inherently destructive, so every read must be accompanied by a write-back operation to restore the contents of memory.
  
• Memory words were 28 bits, with 2 of those bits being for parity, and thus the data portion of memory words was only 26 bits.  Memory was accessed serially, at a 512K bits/second rate, though this fact is not relevant as far as software coding is concerned.
• Each memory word was logically subdivided into two 14-bit "syllables" (13 data bits + 1 parity bit), and computer instructions were encoded in 13 bits.  Therefore, each memory word could hold two computer instructions, one in each syllable.  Data, on the other hand, required a complete word.
  
• The total amount of memory varied from mission to mission, I believe.  The LVDC could be populated with up to 8 modules of memory, with each module comprising 16 "sectors" of 256 words each (4096 words), for a maximum of 32768 words.  One word in each block wasn't memory as such but was a mirror of the CPU's Product-Quotient Register (see below), so the usable memory in each block was really only 4095 words. 
  
• Memory could be operated in two different modes, under program control, called "simplex" and "duplex".  In "duplex" mode, the memory was divided into two banks, each of which was an identical mirror of the other in order to improve reliability, whereas in "simplex" mode the memory wasn't redundant in this way (though it was still triply redundant as mentioned above) but the number of memory words was double.  In duplex mode, the odd-numbered modules mirrored the even-numbered modules, so that one would typically used only modules 0, 2, 4, and 6 in duplex mode.  For the AS-206RAM LVDC Flight Program, a simplex model was required.
  
• The basic CPU clock was 2048 KHz, but computer instructions were executed in a "computer cycle" time which was 82.03125μs.  The latter may seem like an unusual number, but where it comes from is that each instruction required reading/writing 3 syllables (1 holding the instruction and 2 holding the data) of 14 bits each, with each bit requiring 4 clocks to process. 3×14×4=168, so the computer cycle was 168/(2.048MHz)=82.03125μs.  Although most instructions took a single computer cycle, some instructions (particularly multiplication and division) took longer.  The longest instruction, MPH, took 5 cycles.  The MPY and DIV instructions (see below) theoretically took only a single cycle, but could only begin their operations in that amount of time, and the results weren't accessible until later (4 cycles total for MPY and 8 cycles total for DIV).
  
• Arithmetic was 2's complement, integer only.
• There were two arithmetic units, one of which could perform addition, subtractions, and logical operations, whilst the other could perform multiplication and division.  The two units could be operated independently, which is significant because multiplications required 4 computer cycles and divisions required 8 computer cycles, and instruction execution could continue while the multiplication or division proceeded.  In other words, one could begin a multiplication or division, proceed to execute some unrelated instructions, and then later fetch the results of completed multiplication or division.
  

• The Accumulator Register.
• The Product-Quotient Register (or just P-Q Register) can be accessed at address 0775 (octal) regardless of which memory modules and sectors were currently selected.  (This happens to be an address in the "residual sector", as described below, so it represents a single address in each memory module rather than an address within each memory sector.)  However, it is used by the MPY and DIV instructions (see below) and therefore cannot be treated as an ordinary memory location.
• The HOP Register, discussed further below.
• ... and various hidden registers not directly relevant to software:  the Transfer Register, the Address Register, the Data Module Register, the Data Sector Register, the Instruction Sector Register, the Operation Code Register, and the Memory Buffer Registers.

• 0400 stores a HOP Register code (see below) for vectoring to interrupts.
  
• 0600, 0640, 0700, 0740 are used for the EXM instruction (see below).
• 0776, 0777 are used for the "HOP save" feature (see below).

Layout of Memory Words

• Bits IM1-IM3 (not contiguous) select the memory module from which instructions are fetched.  (Recall that there are up to 8 memory modules installed in the LVDC.)
• Bit DUPIN selects whether the portion of memory from which instructions are fetched is accessed in duplex mode or in simplex mode.  (Recall that in duplex mode there is only half the addressable memory as in simplex mode, because the memory is dual-redundant and half of the memory mirrors the other half.)
• Bits IS1-IS4 select the 256-word sector within the selected memory module from which instructions are fetched.
• Bits A1-A8 (the Instruction Counter) point to the next instruction word to be fetched from the selected sector in the selected block.
• Bit SYL indicates the next instruction syllable in the next instruction word.
• And similarly, bits DM1-DM3, bit DUPDN, and bits DS1-DS4 serve analogous purposes except for data words rather than instruction words.

CPU Instructions

Mnemonic	A 8	A 9	O P 4	O P 3	O P 2	O P 1	Timing (computer cycles)	Description of the instruction
HOP	X	X	0	0	0	0	1	This instruction combines an unconditional jump instruction with various other configuration options, such as memory-sector selection.  The way it works is that the address A1-A9 points to a memory word that contains a "HOP constant", and the HOP instruction transfers that HOP constant into the HOP register.  Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".  There is no provision for a partial HOP constant, and the full HOP constant needs to be given every time a HOP instruction is used.  See also CDS and TRA. Although the machine instruction requires the address of the HOP constant to be provided as its operand, the assembler is flexible enough to allow the operand to instead be a left-hand symbol for the target location in the code.  When it encounters this situation, the assembler transparently performs a workaround.  For the sake of discussion, imagine assembly-language code something like the following:         HOP     HIGTHR         .         .         . HIGTHR  ... more code ... What the assembler does in a case like this is: If the target address is in the current instruction-memory sector (either in the same or the opposite syllable), transparently replace the HOP instruction by a TRA instruction.  Otherwise, proceed to step 2. Allocate a data word in the current data sector.  Do this by searching upward in the data sector, looking for the first unused location.  The residual sector is searched if there's no room left in the current sector. Create a HOP constant for the target location, and store it in the newly-allocated data word. Use the address of the newly-allocated data word as the operand for the HOP instruction. Whenever such a substitution was performed by the assembler, it noted it in the assembly listing by printing "HOP*" as the name of the instruction rather than "HOP" as what would have been used on the actual punch card.
MPY	X	X	0	0	0	1	1 (results available after 4)	This is a multiplication instruction.  It multiplies two 24-bit numbers to produce a 26-bit product.  The accumulator provides the address of one operand, and the address embedded in the instruction points to the other operand.  Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".  In both cases, the most-significant 24-bits of the operands are used, and the least-significant 2 bits of the operand are ignored.  A partial product (24 bits from the addressed memory times the 12 less-significant bits from the accumulator) can be fetched from the P-Q Register (0775 octal) on the 2nd instruction (or more accurately, two computer cycles) following MPY, though there is no need to do so if that value isn't desired by the program.  The full product is available from the accumulator or from the P-Q Register on the 4th instruction (more accurately, 4 computer cycles) following MPY.  However, the result will remain in the P-Q register until the next MPH, MPY, or DIV.
SUB	X	X	0	0	1	0	1	Subtracts the contents of a word pointed to by the address embedded within the instruction from the accumulator, and puts the result back into the accumulator.  Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".  See also RSU. Regarding borrow from the operation, the CPU provides no direct way of accessing it, and thus no easy way to perform multi-precision subtraction.  Refer to the notes for the ADD instruction for more information.
DIV	X	X	0	0	1	1	1 (results available after 8)	This is the division instruction.  The contents of the accumulator are divided by the operand pointed to by the address A1-A9 embedded within the instruction to produce a 24-bit quotient.  Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".  The quotient is available in the P-Q Register (0775 octal) on the 8th instruction (more accurately, 8 computer cycles) following the DIV.  However, the result will remain in the P-Q register until the next MPH, MPY, or DIV.
TNZ	X	X	0	1	0	0	1	This is a conditional jump instruction, which branches to the address embedded in the instruction if the accumulator is not zero, but simply continues to the next instruction in sequence if the accumulator is zero.  Bits A1-A8 of the embedded address represent the new offset within the currently selected 256-word instruction sector, while bit A9 gives the syllable number within that word.   The "residual sector" cannot be accessed.  See also TMI. As mentioned, the target address for the machine instruction itself had to be within the current sector, because its 8-bit address offset is embedded within the instruction.  However, the assembler would transparently work around this problem, allowing essentially any target address to be used.  For the sake of discussion, imagine an assembly language instruction, TNZ    OINIT in which the target location OINIT is not in the current memory sector.  The workaround procedure used by the assembler was this: Working downward from the top of the current instruction-memory sector, find an unallocated memory location. In that newly-allocated memory location, put a "HOP OINIT" instruction. Use the newly-allocated memory location as the target of the TNZ instruction. In the assembly listing, display the operator as "TNZ*" rather than "TNZ".  (But "TNZ" is nevertheless what actually appeared on the punch cards.) Of course, this workaround preserves the intended logic, at the cost of an extra instruction word and a couple of extra machine cycles.
MPH	X	X	0	1	0	1	5	This is a multiplication instruction.  It is exactly like MPY except that the program "holds" until the multiplication is complete, so that the product is available from the accumulator or from the P-Q Register at the next instruction following MPY.  However, the result will remain in the P-Q register until the next MPH, MPY, or DIV.
AND	X	X	0	1	1	0	1	Logically ANDs the contents of the accumulator with the contents of the address embedded within the instruction and places the result in the accumulator.  Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".
ADD	X	X	0	1	1	1	1	Adds the contents of the accumulator with the contents of the address embedded within the instruction and places the result in the accumulator.  Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector". What about the carry bit?  As far as I can tell, the CPU has no provision for carry bit that's useful at the software level.  If you want to do multi-word precision arithmetic (say, 52-bit addition instead of just 26-bit addition), then you have to find some indirect, software-only way of detecting carry rather than on relying on the CPU to provide you with some easy way of handling it.  It's certainly mathematically possible to do so:  When adding two addends of the same sign using 2's-complement arithmetic, you can detect carry because the sum has the opposite sign of the addends, whereas adding two addends of opposite signs cannot result in carry anyway.  But the coding to exploit this mathematical possibility is obviously going to be cumbersome and inconvenient.  (The low-level adder circuit itself can deal with a carry bit, of course.  The adder performs additions serially, starting with the least-significant bit and moving upward to the most-significant, and at each bit-stage there's a carry bit from the previous stage to worry about.  However, the final carry bit is not accessible to software, and the carry-bit latch is cleared by any CLA instruction, making it very tough to transfer the carry-bit latch's contents from one word-addition to the next.  In theory, if you could figure out a way to do multi-precision arithmetic without using CLA, perhaps you could exploit that hidden carry bit.  But I'm having trouble seeing any way you might do it.  That could just be my failure of imagination, of course.)
TRA	X	X	1	0	0	0	1	TRA is an unconditional jump instruction, which branches to the address embedded in the instruction.  Bits A1-A8 of the embedded address represent the new offset within the currently selected 256-word instruction sector, while bit A9 gives the syllable number within that word.   The "residual sector" cannot be accessed. Note, however, that the assembler transparently worked around the limitation that the target address had to be in the same sector.  The assembler would automatically insert a HOP instruction instead of a TRA whenever it found that it was necessary to do so.  For example, consider the instruction "TRA ETCBTC".  If the target location ETCBTC is within the current instruction sector, the assembler would indeed assemble this exact as expected, using a TRA instruction with opcode 1000.  Actually, the assembler would refuse to directly do a TRA to a target in the same instruction sector under some circumstances, presumably to help guard the programmer from easy-to-make errors.  The condition I've noticed in which this occurs is if the target address has been tagged by the assembler as being in a region with a different setting for the data module or sector, since unlike a HOP instruction, a TRA instruction doesn't alter the DM/DS settings.  Whereas if a CDS instruction (which changes the DM/DS settings in the processor itself) happens to be at the target location, it doesn't trigger a replacement by HOP.  Quite a complicated set of conditions! One wonders if the original programmers actually had much awareness at the time (or cared!) that these substitutions were being made for them. But if the target location (ETCBTC in this example) wasn't within the current instruction sector or failed the DM/DS conditions, then the assembler would instead perform the following complicated maneuver which preserves the expected program logic, at the cost of an extra machine cycle and an extra word of memory: Allocate a data word in the current data sector.  This is done by searching upward through the current data sector (or the residual sector, failing that) until an unallocated word is found. Create a HOP constant for the target location ETCBTC, and store it in the newly-allocated data word. Assemble a HOP instruction with the newly-allocated data word as its operand. Whenever such a substitution was performed by the assembler, it noted it in the assembly listing by replacing "TRA" with "TRA*".  However, I think that "TRA" is always what would have originally been used on the punch card. This in so far as the assembly-language source code is concerned, it seems that one may as well always use TRA rather than HOP, since TRA is more economical than HOP, and the assembler will always substitute HOP anyway whenever some limitation of TRA necessitates it.
XOR	X	X	1	0	0	1	1	Logically exclusive-ORs the contents of the accumulator with the contents of the address embedded within the instruction and places the result in the accumulator. Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".
PIO	X	X	1	0	1	0	1	Reads or writes an i/o port.    Bits A1-A9 select the source and destination of the i/o.   A table of the i/o ports vs. addresses is given in the following section. In so far as assembly-language syntax is concerned, the operand of the instruction is always a literal octal numerical constant.
STO	X	X	1	0	1	1	1	Stores the contents of the accumulator in the word indicated by the address embedded within the instruction.  Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".  The following addresses are special, as described in the documentation of the STO instruction (see p. 2-17): 0775 (octal) stores into the Product-Quotient register rather than to normal memory. 0776 (octal) stores the contents of the multiplicand-divisor register (rather than the accumulator) to address 0776. 0777 (octal) stores the contents of the multiplicand-divisor register (rather than the accumulator) to address 0777. However, the description of 0776 and 0777 above is quite misleading.  For one thing, the way the multiplication and division instructions work, the inputs to those operations (multiplicand, multiplier, dividend, divisor) are all supplied in the accumulator and memory locations anyway, so why would you need an instruction to separately access the multiplicand or divisor?  The answer is that this feature has nothing at all to do with multiplication and division, but is instead crucial to storing return addresses in subroutines and interrupts! The explanation is this:  During the process of executing any given LVDC instruction, a HOP constant for the LVDC instruction at the next successive memory address is formed.  Keep in mind that the next instruction successively in memory is not necessarily the next instruction sequentially executed in time.  Whatever the next instruction executed — unless it happens to be a multiplication or division (MPY, MPH, DIV) — the previously-generated HOP constant is temporarily shoved into multiplicand-divisor register.  Thus if the very next instruction executed is STO 776 or STO 777 (and the previous instruction was not MPY, MPH, or DIV), what ends up getting stored in location 776 or 777 is not a multiplicand or divisor, but rather the HOP constant for the memory address that numerically follows the previously executed instruction.  Which is not useful at all when instructions are simply executing sequentially, but is useful whenever there is a transfer of control because the code to which control has been transferred can use it to access its own return address ... and there is no other painless method provided in the instruction set to do so. In other words, in a subroutine or interrupt-service routine, the very first instruction should be a STO 776 or STO 777 to save the HOP constant for the return address.  Conversely, the instruction for returning from the subroutine or interrupt is a matching HOP 776 or HOP 777 instruction.
TMI	X	X	1	1	0	0	1	This is a conditional jump instruction, which branches to the address embedded in the instruction if the accumulator is less than zero, but simply continues to the next instruction in sequence if the accumulator greater than or equal to zero.  Bits A1-A8 of the embedded address represent the new offset within the currently selected 256-word instruction sector, while bit A9 gives the syllable number within that word.   The "residual sector" cannot be accessed.  See also TNZ. As mentioned, the target address for the machine instruction itself had to be within the current sector, because its 8-bit address offset is embedded within the instruction.  However, the assembler would transparently work around this problem, allowing essentially any target address to be used.  The workaround used by the assembler is that same as that described for the TNZ instruction above.  Instructions for which the workaround have been applied are shown on the assembly listing as "TMI*" rather than "TMI".
RSU	X	X	1	1	0	1	1	Same as SUB, except that the order of the operands in the subtraction is reversed.
CDS or CDSD or CDSS	X	0	1	1	1	0	1	Change the currently-selected 256-word data sector.  For this instruction, A9 forms a part of the instruction itself, so only A1-A8 are significant.  The partially overwrite the HOP Register as follows: See also HOP. In terms of assembly-language syntax, there are the following variations: CDS     SYMBOLNAME CDSD    DM,DS CDSS    DM,DS Thus CDS uses the characteristics of a variable name or a name defined with the DEQD or DEQS pseudo-ops (see below), whereas the module number and sector number are simply supplied with octal numeric literals in CDSD or CDSS.  The difference between CDSD and CDSS is that the former selects duplex memory while the later selects simplex memory. In the usage I've seen, usage of CDSS is confined almost entirely to the context of USE DAT (see below).
SHF	0	1	1	1	1	0	1	Performs a logical shift operation on the accumulator.  For this instruction, bits A8 and A9 form a part of the instruction itself, but of the remaining bits only A1, A2, A5, and A6 are actually used, as follows: A1 A2 A5 A6 Description of operation 0 0 0 0 Clears the accumulator 1 0 0 0 Shift one position towards in the less-significant direction 0 1 0 0 Shift two positions towards in the less-significant direction 0 0 1 0 Shift one position towards in the more-significant direction 0 0 0 1 Shift two positions towards in the more-significant direction In terms of assembly-language syntax, I have never seen SHF itself used.  The only variations actually used are SHL N SHR N where N is a literal decimal numerical constant.  However, N is not limited to just 0, 1, or 2, even those are all that SHF directly supports.  If an operand N>2 is encountered, the assembler transparently replaces it with an appropriates sequence of shift-by-2 and shift-by-1 instructions.
EXM	1	1	1	1	1	0	1	"Execute modified".  This instruction takes an instruction stored at a specified memory location, forms a modified A1-A9 field for that instruction, executes that instruction, and then continues with the next instruction following the EXM (unless the program counter has been modified).  For this instruction, A8 and A9 form a part of the instruction code, so only A1-A7 are significant.  Only 4 different target words are allowed, 0600, 0640, 0700, and 0740, and they are all in the "residual sector".  Many of the bits in A1-A7 represent various types of modifications to the embedded address at the target address rather than being address bits themselves.   Here are the interpretations of bits A1-A7 in the EXM instruction: A1-A4 modify the address embedded in the target instruction as described below. A5 indicates the syllable in which the target instruction resides. A7,A6 selects the target address, as follows: 0,0 for target address 0600 0,1 for target address 0640 1,0 for target address 0700 1,1 for target address 0740 When the target instruction is executed, its A1-A9 bits are formed as follows: A1-A2 come from A1-A2 of the EXM instruction. A3 is the logical OR of the A3 of the target instruction and A3 of the EXM instruction. A4 is the logical OR of the A4 of the target instruction and A4 of the EXM instruction. A5-A8 come from A5-A8 of the target instruction. The data sector used when the target instruction is executed is also changed for the duration of that one instruction, as determined by bits A1, A2, and A9 of the unmodified target instruction, as follows: A2 A1 A9 Data Sector 0 0 0 004 0 0 1 014 0 1 0 005 0 1 1 015 1 0 0 006 1 0 1 016 1 1 0 007 1 1 1 017 ("residual" sector) In baseball terms, this is the "infield fly rule" of the LVDC: it clearly does something, but it's hard to grasp exactly what it does.
CLA	X	X	1	1	1	1	1	Store a value to the accumulator, from the memory word at the address embedded within the instruction.   Recall that A1-A8 select the offset within a 256-word sector, and A9 is the "residual bit" that selects between the current sector and the "residual sector".

I/O Ports (For PIO Instruction)

Address Field from PIO Instruction									Data Source	Data Destination	Specific I/O Ports
A9	A8	A7	A6	A5	A4	A3	A2	A1
X	0	A	A	A	A	A	0	A	LVDC Accumulator Register	LVDA Telemetry Registers	(Note:  Used to output telemetry consisting of the values of variables, typically via the TELEM macro in the LVDC source code.  For definitions of non-standard units of measurement, see the later discussion of that topic.  Page-number references are to the AS-206RAM LVDC source code or to its abridged form.) A9 - A1 (octal) Variable Scale Units Interpretation 000 TASEC ONTAS B15 sec Time elapsed from GRR or time of last orbit navigation 001 CHIZ B0 pirad Yaw guidance command in space-fixed coordinates 004 ACCZ 0.05 m/sec Accelerator optisyn reading 005 CHIX B0 pirad Pitch guidance command in space-fixed coordinates 010 ACCX 0.05 m/sec Accelerator optisyn reading 011 CHIY B0 pirad Roll guidance command in space-fixed coordinates 014 ACCY 0.05 m/sec Accelerator optisyn reading 015 THETZ B0 pirad Whole yaw gimbal angle 021 THETX B0 pirad Whole roll gimbal angle 025 THETY B0 pirad Whole pitch gimbal angle 030 TLTBB B15 sec Biased time elapsed in time base 031 TB B15 sec Time elapsed in current time base 034 ZS ONZN B23 m Component of position in space-fixed coordinates 044 XS ONXN B23 m Component of position in space-fixed coordinates 050 YS ONYN B23 m Component of position in space-fixed coordinates 054 GR10R B-22 m-1 Reciprocal of total radius in space-fixed coordinates 060 GZ B4 m/sec2 Component of gravitational acceleration 064 GX B4 m/sec2 Component of gravitational acceleration 070 GY B4 m/sec2 Component of gravitational acceleration 074 TBA B15 sec Set equal to TBB at the time of a C-band station gain or loss 075 SS Switch selector interrupt 110 ZDS B14 m/sec Component of velocity in space-fixed coordinates 114 XDS B14 m/sec Component of velocity in space-fixed coordinates 120 YDS B14 m/sec Component of velocity in space-fixed coordinates 124 V B14 m/sec Total velocity in space-fixed coordinates 134 ZS B23 m Component of position in space-fixed coordinates 144 XS B23 m Component of position in space-fixed coordinates 150 YS B23 m Component of position in space-fixed coordinates 174 ACCT TLPAST B25 qms Real time clock reading 400 T1I B10 sec First IGM phase time-to-go 414 MC28 Mode code 28 status changes.  Refer to p. 12. 415 MC24 Mode code 24 status changes.  Refer to pp. 4-5. 420 MC27 Mode code 27 status changes.  Refer to pp. 11-12 421 MC25 Mode code 25 status changes.  Refer to p. 5. 425 DORSW Discrete output register contents.  A change indicates a guidance failure. 431 ICR LVDA internal control register contents.  Refer to pp. 5-6. 434 Z4 B23 m Position in target plane coordinates 435 EMRR TLEMR1 Error monitor register contents.  Change indicates ladder failure or redundancy disagreement. 441 INT LLS, OBCO, TLC, or S4BCO interrupt.  Refer to p. 6. 444 X4 B23 m Position in target plane coordinates 450 Y4 B23 m Position in target plane coordinates 460 T3I B10 sec Time-to-go in S4B second burn 461 TLCHPC TLC ("tough luck charlie") HOP constant 465 DIS.IN Discrete inputs.  Refer to p. 6. 471 SQ3 B1 (1-ZSP2)1/2 475 TBBU Time base backup 500 FDBK Switch-selector feedback register, in the event of an error 501 MLCHIZ B0 pirad Minor loop CHIZ 504 ZDDV B4 m/sec2 Component of vent acceleration 505 MLCHIX B0 pirad Minor loop CHIX 510 XDDV B4 m/sec2 Component of vent acceleration 511 MLCHIY B0 pirad Minor loop CHIY 514 YDDV B4 m/sec2 Component of vent acceleration 520 ZDDD B4 m/sec2 Component of drag acceleration 524 XDDD B4 m/sec2 Component of drag acceleration 530 YDDD B4 m/sec2 Component of drag acceleration 534 ALT B4 m Altitude 535 TLEMR8 Minor-loop error code 544 TAUD B10 sec Time-to-go 561 TI B15 sec Time from GRR of time-base change 570 (various) Minor-loop error code.  Refer to pp. 6 and 14. 571 ETC End of telemetry cycle, one per computation cycle 575 BTC Begin telemetry cycle, one per computation cycle
0	1	A	A	A	A	A	0	A	LVDC Main Memory	LVDA Telemetry Registers
1	1	A	A	A	A	A	0	A	LVDC Residual Memory	LVDA Telemetry Registers
X	0	A	A	A	A	A	1	0	LVDC Accumulator Register	LVDA Output Registers	A7 - A1 (octal) Purpose 006 Mode Register 012 Discrete Output Register (Reset).  The LVDC EDD for the Saturn IB Flight Program document, section 7.3, summarizes the discrete outputs as: 016 Discrete Output Register (Set).  See PIO 012 above. 022 Internal Control Register (Set) 026 Internal Control Register (Reset) 032 Interrupt Register Reset 036 Switch Selector Register (Load) 042 Orbital Checkout 052 Switch Selector & Discrete Output Registers (Read) 062 Switch Selector Interrupt Counter 066 COD Error (Read) 072 Inhibit Interrupt 076 Minor Loop Timed Interrupt Counter 146 Ladder No. 1 152 Ladder No. 2 156 Ladder No. 3 162 Ladder No. 4 166 Ladder No. 5
0	1	A	A	A	A	A	1	0	LVDC Main Memory	LVDA Output Registers
1	1	A	A	A	A	A	1	0	LVDC Residual Memory	LVDA Output Registers
X	0	A	A	A	A	A	1	1	LVDA Peripheral Inputs and Errors	LVDC Accumulator	A8 - A1 (octal) Purpose 023 Error Monitor Register 043 Command Receiver or RCA-110 053 Discrete Input Spares.  Refer to the DIS1-DIS8 inputs in the table for PIO 057 below. 057 Discrete Inputs.  The LVDC EDD for the Saturn IB Flight Program document, section 7.4, summarizes the discrete inputs in the table below.  (The DIS1-DIS8 inputs in the table for PIO 053 above.) The Command Decoder OM/D bits mentioned in the table originate in an up-data command word transmitted to the rocket from mission control.  There are two such bits in the transmitted word, but the LVDA combines them into a single bit before passing them to the LVDC — hence, OM/D bits "A" and "B" both appear at the same position in PIO 057.  A value of 1 in the OM/D bit indicates that a "mode" command word has been received (and is accessible via PIO 043), while a value of 0 indicates instead that a "data" command word has been received (in PIO 043). 067 Telemetry Scanner 077 Switch Selector 103 Real Time 107 Accelerometer Processor X 117 Accelerometer Processor Z 127 Accelerometer Processor Y 137 Interrupt Storage
X	1	A	A	A	A	A	1	1	LVDA Resolver Processor Inputs	LVDC Accumulator	A7 - A1 (octal) Purpose 203 Z Gimbal Backup.  (This is not covered by the available documentation, but seems to be implied by the comments in the source code.) 207 Spare No. 6 217 Computer COD Counter Start 223 Fine Gimbal No. 1 233 Coarse Gimbal No. 3 237 Computer COD Counter Start 243 Coarse Gimbal No. 1 247 Horizon Seeker No. 1 257 Spare No. 3 277 Spare No. 4 313 Fine Gimbal No. 4 317 Spare No. 1 323 Horizon Seeker No. 3 327 Horizon Seeker No. 2 333 Coarse Gimbal No. 4 337 Spare No. 5 343 Coarse Gimbal No. 2 353 Fine Gimbal No. 3 357 Spare No. 2 363 Fine Gimbal No. 2 367 Horizon Seeker No. 4

Subroutine Linkage

Interrupts

1. The LVDC automatically masks that particular interrupt from occurring again until explicitly reenabled (at step 9 below).
   
2. The LVDC allows any instruction, multiplication, or division in progress to complete.
3. The LVDC performs a HOP 0400, thus transferring control to an interrupt-service routine—or, as the original documents refer to it, an "input-output subprogram".  Recall that this does not jump to address 0400, rather it loads the HOP Register from the value stored at address 0400, and this can be used to jump to a location, set the current memory module and sector, etc.  (Early non-flight hardware seemingly used a HOP 0776 instead of HOP 0400.)
   
4. The first instruction executed by the interrupt service routine must be either STO 0776 or STO 0777 to store the pre-interrupt value of the HOP Register at either address 0776 or 0777.
5. The interrupt service routine should then save any registers or common memory locations that were going to be altered into local storage.  In almost all cases, one would suppose that the accumulator needed to be stored.  If multiplications or divisions would be used, the P-Q Register would also need to be saved, presumably with a pair of instructions like CLA 0775 followed by STO somewhere.
6. The interrupt service routine should do a PIO from the Interrupt Storage input port to determine which of the 12 interrupt sources are active, so that it can vector to an appropriate service routine for it.
   
7. The interrupt service routine should then do whatever computations it needed to do.
8. The interrupt service routine should restore the registers it had saved (CLA somewhere followed by STO 0775 to restore the P-Q Register, if necessary, followed by a restoration of the accumulator).
9. The interrupt service routine should do a PIO to the Interrupt Register Reset output port, with just the specific bit set corresponding to the interrupt type being processed, to reenable that specific interrupt.  The particular flavor of PIO performed should, of course, take the Data Source from memory rather than from the accumulator, since at this point the accumulator has already been restored to its pre-interrupt condition.
   
10. The return from interrupt is either HOP 0776 or HOP 0777, depending on which location the HOP constant had been stored on entry to the interrupt service routine.

Telemetry

• 26 bits are the data payload.  These bits come directly from the operand of the PIO instruction.
• 9 bits are a tag indicating the specify type of data in the packet.
• Bit A9: TBD
• Bit A8: 1.  (1 for telemetry requested by the LVDC, and 0 for the LVDA.)
• Bits A7-A1.  These apparently come from the i/o address in the PIO instruction.   For example, the instructions CLA =67 / PIO 040 would end up setting A7-A1 of the tag to 040 (octal), while the data payload would be set to 67 (decimal).
  
• 3 bits determine the "mode".  I'm not sure where these bits come from, but perhaps they come from the mode register, which the LVDC software sets via PIO 006.
  
• 1 bit indicates validity of the packet.  The value of the bit is 0 if valid and 1 if invalid, and is present because the LVDC PIO operation can clobber an output already in progress, due to lack of synchronization between the LVDC and LVDA.  At any rate, this bit is manipulated by the LVDA, and is transparent to the LVDC.
  
• 1 bit is parity.  The overall parity of the 40-bit packet is odd.  The parity bit is generated by the LVDA, and is transparent to the LVDC.

Up-data

(A lot of information in this section is abstracted from the Astrionics System Handbook, chapter 6, "Radio Command Systems".)

The term up-data refers to commands transmitted from mission control to the LVDC/LVDA.

As transmitted, the standard command-word format consists of 35 bits:

• 3 bits are referred to as the "X" bits.  They form an address, indicating which vehicle the message is intended for.
  
• 14 bits are also an address, but they identify a specific "command decoder" for processing the message.  A vehicle may have multiple command decoders with different hard-coded addresses.
  
• 18 bits comprise the control and data portions of the message.
  

The latter two sets of bits are interspersed within the message, and thus are not transmitted in the specific order shown above.

However, the as-transmitted format of the data isn't really very relevant to how the LVDC and its software relate to the up-data, since only a portion of the transmitted bits reach the LVDC software — specifically only some of the bits from the final group of 18 — and even then they don't always reach the LVDC in the exact form they are transmitted.  Thus, let's narrow our discussion of the up-data to just the LVDC's perspective.  The 18 control&data bits of the message are further categorized as:

Similarly, there are two transmitted "interrupt bits" (see the image above).  These cause an interrupt to occur in the LVDC, which I believe is designated in the interrupt table given earlier as bit-position 4, Command Receiver Interrupt.

Finally, the 14 remaining bits actually represent just 7 bits of actual information, since each bit appears both in its normal form and in its logically-complemented form for the purpose of error-detection.

Refer to section 6.2 of the Astrionics System Handbook for more detail, but the LVDC software accesses the received command using the following general steps:

• Do unrelated processing until the Command Receiver interrupt occurs.
• Interrogate the OM/D bit of PIO 057 to verify that its value is 1.  This means that the received word is a "mode command word".  (The first word of any sequence of commands will be a mode command word, followed by some number of "data command words".)
  
• Interrogate PIO 043 to get the value of the mode word, and parses it to determine the specific command that has been requested.  Each command type will imply the number of data command words that will be subsequently transmitted and processed.  For the sake of discussion, let's call that number N.
  
• Outputs telemetry (TBD) indicating successful reception of a command word.
• For each of the N data command words that are supposed to be received for this sequence, do the following:
• Do unrelated processing until the Command Receiver interrupt occurs.
• Interrogate the OM/D bit of PIO 057 to verify that its value is 0.  I.e., that the received word is a data command word.
• Get the received word using PIO 043.
• Buffer the received word in memory.
• After all of the N data words are received, perform whatever action is appropriate for the now-completely-received command.

The command word read using PIO 043 has the format shown in the illustration to the right.  As mentioned above, there are 7 actual data bits, but they appear twice each:  Once "normally", and once inverted.  Besides that, there is a "sequence bit" which also appears normally (bit 8) and inverted (bit 1).  This bet helps to make sure the command words have been received in an appropriate order.  The sequence bit is 0 for the mode command word, then 1 for the first data command word (if any), and then it just toggles between 0 and 1 for each subsequent data command word received.  When the next mode command word is received, the sequence bit goes back to 0 and the pattern repeats.

LVDC Assembly Language

Basic Factoids

• Pure octal constants are left-aligned in their memory word.  In other words, a constant of N octal digits would be right-padded by 26-3N bits of 0.
  
• Pure decimal (integer) constants are fully right-aligned.  In other words, a decimal integer encoded as N bits would be sign-extended on the left by 26-N bits.
• Decimal non-integer constants are treated as being in the range -1.0 < constant < 1.0. 

Units of angular measurement:  For most internal purposes, the source code typically measures angles in a unit called a pirad.  I can find no reference to any unit by this name outside of the LVDC source code, nor does the LVDC source code choose to define it in the program comments.  However, from the usage, it seems pretty clear that

1 pirad = 180° = π radians

1° = 1/0.06 ladder units

1° = 2016/5.625 fine units

1° = 2016/180 backup units

1 ms = 1/0.24609375 qms
1 ms ≈  4.063492 qms

• Columns 1-6:  Optional symbol, supplying a name for the memory location of the current line of code.  The original coders called these "left-hand symbols".
• Columns 8-15:  The name of the CPU instruction, pseudo-op, or macro.  Notice that this is not aligned with what is sometimes thought of as the default position of a "tab stop", which would have been at column 9.
• Columns 16-28:  The operand. I'll talk more about these operands below.
  
• 29-75:  Comment, possibly blank.  
• 75-80:  Sequence number, consisting of 6 decimal digits.  These sequence numbers came directly from the original punch cards.  As a convention, the sequence numbers are unique, and are in increasing order from one line to the next ... almost always, the sequence numbers increment by 10 from one line to the next.  Nevertheless, there are chunks of code having no sequence numbers at all.  When that happens, the assembler simply adds 10 to the last sequence number it saw, and then assigns that same number to all subsequent lines until encountering a card with an actual sequence number on it.  (I'm not saying it increments the sequence number by 10 on every unnumbered line; it increments it just once, and then keeps giving line after line the same number.)  Given that fact, it's pretty obvious that the cards were processed in the order they were encountered, rather than being rearranged internally to the assembler in sequence-number order.  I don't believe the original assembler needed to use these sequence numbers other than for reference purposes in the symbol table (see below).

By the way, these observations about columnar alignment don't relate to the new assembler (yaASM.py), which does not enforce or use the columnar alignment in any way, other than to recognize that column 1 is special.  I don't know if the original assembler actually cared about the columnar alignment, or whether the alignment I've observed is simply a convention.

Preprocessor Pass

The LVDC assembler is a macro assembler, meaning that the language it processes has a variety of constructs intended to make coding easier and more manageable but which aren't directly related to the internal characteristics of the LVDC CPU.  These constructs are all resolved and removed from the code by a dedicated preprocessor pass prior to any assembly of actual LVDC instructions or allocation of LVDC memory.  The various preprocessor constructs that appear in LVDC code are described in this section.

The preprocessor itself operates in a single pass, and therefore any symbols or macros it uses must have been defined prior in the source code to such use.

CALL ARG1,ARG2

CLA ARG2
HOP ARG1

CALL ARG1,ARG2,ARG3

CLA ARG3
STO 775
CLA ARG2
HOP ARG1

NAME    MACRO    ARG1,ARG2,...
        ... code using the symbols ARG1, ARG2, and so on ...
        ENDMAC

CALL    MACRO    ARG1,ARG2
        CLA      ARG2
        HOP      ARG1
        ENDMAC

NAME    EQU    (EXPRESSION)

OMEGA   EQU    (.72921141E-4)
RWCP    EQU    (OMEGA*6373377*.87993)

(EXPRESSION)Bn

IF    PSEUDOVARIABLE=(EXPRESSION)
... code ...
ENDIF

Assembly Pass

(Technically, what I'm calling the "assembly pass" here is really implemented in the new assembler, yaASM.py, in two successive passes, known the "discovery pass" and the "assembly pass".  The former associates all program labels and variable names with physical addresses, while the latter performs the actual assembly using the now-resolved addresses.  That detail is totally irrelevant and transparent to the user, but would be necessary information to anybody modifying yaASM.py itself.)

Instruction operands:  Operand formats differ for some CPU instruction types, but most of them require a variable (a word in data memory), and conform to a pattern in which there are several allowed variants for specifying the operand:

1. A literal 3-digit octal number (such as 777 or 776), which is an offset into the DM/DS (Data Module / Data Sector) defined by the current contents of the HOP register.
   
2. The symbolic name of a variable or constant defined elsewhere in the program.  The variable/constant has to be in the current DM/DS, so if the referenced symbol doesn't happen to be located in that particular module or sector, it could be a problem.
3. An arithmetical expression involving symbolic names, such as CBTAB+1 or CBTAB+(4*CBSTNO+1).  For a sufficiently complex expression, since as the latter one in the preceding sentence, the raw form of the instruction will appear in the assembly listing as if it were a comment (like a CALL line), and the fully resolved expression will appear marked with a "+" character as if it were a macro expansion ... which it probably is.  For example, if (4*CBSTNO+1) resolves to 57, then the expanded instruction would be CBTAB+57.  Note that such expressions, depending on what they contain, may resolve either to an address in memory, or else to a constant value.  In the latter case, the numerical constant is treated like the constants described in the following item.
   
4. The character =, prefixed to a literal numerical constant.  Here the assembler allocates an unnamed variable in the current DM/DS, stores the value of the constant at that variable, and then uses the location of the new-created variable as the operand.  In other words, not all program variables are explicitly defined by pseudo-ops ... some of them are transparently allocated in as needed by the assembler itself in memory locations not previously used for anything..  Each numerically-unique constant is stored only once as a variable and is reused everywhere that requires it.  For example, in the AS-206RAM LVDC assembly listing, =1B18 is an operand in the lines with sequence numbers 051570 and 051910, while =00000004 is used at 051950 and 053380, but they both evaluate to the same numerical value and thus reference the same memory location (2-06-076).  Note that if the literal numerical constant begins with the character 'O' (alphabetic, not digit) then the number is octal, while if the leading 'O' is not present then the number is decimal.
   

Except for the HOP instructions, the other CPU instructions that transfer program control target a location in the current IM/IS rather than a variable in the DM/DS, and thus require a different type of operand. Those instructions (TRA, TNZ, TMI) thus have operands in one of the following two formats:

• The symbolic name of a code location in the current IM/IS.
• "*+n" or "*-n", where n is a literal decimal constant.  This references the memory location n words later or earlier than the current instruction, respectively.  (I say that the literal constant is decimal because yaASM.py implements it in that way.  However, there are no instances of n>7 in the existing LVDC source code, so I really have no way of knowing whether the original assembler accepted decimal constants or octal ones.)
  

Other exceptions:

• The shift instruction, SHF, and the shorthand replacements for it, SHR and SHL.  The latter two shorthand instructions take an operand of 0 or a positive decimal integer, and thus represent logical right or left shifts by a selectable number of positions.  With "0" as the operand, as a special case, the accumulator is cleared.  There are no uses of SHF in the existing source code, so while it must take an integer operand, I'm not sure whether it would be octal or decimal or something else.  Note:  SHR and SHL are implemented as SHF operations, but SHF can only shift by 1 or 2 positions.  Therefore, if the operand for SHR or SHL is greater than 2, the assembler transparently converts the operation to a minimum-length sequence of SHL 2, SHL 1, SHR 2, and SHR 1 operations.  For example, SHL 5 assembles to SHL 2 / SHL 2 / SHL 1.  Consequently, depending on the operand, any given SHR or SHL may assemble to multiple executable words in memory rather than to a single word.
• The CDS instruction requires an operand of the form DM,DS,DUPDN where the three octal fields are interpreted, respectively, as specifying a HOP-constant-like data module (0-7), data sector (0-17), and duplex vs simplex mode (0-1).  The DEQD pseudo-op (see below) can be used to create symbolic macro names for such specifications, and so the operand for CDS can be such a symbolic macro name as well.
• The EXM instruction has operands of the form "target,syllable,modifier", where target, syllable, and modifier are all small literal octal integer constants.  These fields may be interpreted as follows:
• target (0-3):  Specifies offset in residual memory of target instruction:  0 for 600, 1 for 640, 2 for 700, 3 for 740.
  
• syllable (0-1):  Specifies syllable of the target instruction within the target word.
  
• modifier (0-17 octal):  Specifies a 4-bit modifier for the instruction:  the two least-significant bits replace the corresponding bits in the target instruction, while the two most-significant bits bitwise-OR with the corresponding bits.
  
• The PIO instruction accepts only literal octal constants (000-377).  All of the examples I saw in the original LVDC printout were 0-padded, though yaASM.py does not enforce that restriction.
  

Program Structure

Here are some of my own observations and inferences, based on inspection of the AS-206RAM assembly listing.

Overall structure of the program:

• Code:
• Table of contents
  
• Explanatory comments about telemetry data.
• Pseudo variables definitions
  
• Code-entry points which are obliged to be at specific memory locations.  (interrupt, initialization, timing "minor loop", abort)
• Orbital program linkages.
• Macro definitions.
• Utility programs required to be at specific memory locations.  I notice that some of this code is self-modifying.  Perhaps that may be part of the motivation for putting it at a specific location.  Perhaps not.
• Data storage area.  I.e., variables and constants ... but there is also a smidgeon of code stored here (go figure!), for managing the switch-selector table.  Of particular bulk are:
• Switch selector table
• C-band and telemetry station table.
• Section 1:  Initialization
• Section 2: Accelerometer processing.
• Section 3: Boost navigation.
• Section 4:  Guidance select and pre-IGM guidance.
• Section 5: IGM guidance.
• Section 6: Backup routines
• Section 7: Interrupt routines
• Section 8: Orbital initialization
• Section 9: Orbital processor
• Section 10: Orbital navigation
• Section 11: C-band and telemetry navigation routine
• Section 12: Acceleration routines
• Section 13: Orbital guidance
• Section 14: Interrupt processing
• Section 15: Simultaneous memory error (Tough Luck Charlie)
• Section 16: Minor loop support
• Section 17: Minor loop
• Section 18: Disagreement bit processing
• Minor loop error telemetry routine
• Section 19: Switch selector check
• Section 20: Switch selector processing
• Section 21: Flight simulation
• Section 22: Utility Routines
  
• Tables generated by the assembler:
• Segment cross reference table
• Octal memory listing
  

Assembly warnings:  Warnings are marked with a W in the leftmost column of the offending line.  No explanation appears in the assembly listing of why any particular warning is issued.  In the AS-206RAM assembly listing, the sequence numbers at which errors and warnings are found is as follows:

012420 015020 015050 015070 015090 015110 015140 015260 015290 015310
026500 026800 026820 026840 026880 026920 026990 027020 027820 027890
027910 027980 028040 028090 029370 030230 031780 031930 032230 036880
036910 036920 036930 036950 036990 037020 037200 037490 038040 038680
038820

Sector shifts in the program flow:  Recall that each 26-bit word of memory (not including the parity bit) consists of two 13-bit syllables, referred to as syllable 0 and syllable 1.  Each CPU instruction assembles to a single 13-bit value, and thus fits precisely within a single syllable, and any word in memory can simultaneously hold two separate instructions.  When the CPU executes code in a given memory sector, it just sequences through all of the instructions in the currently-selected syllable.  When the last-available word in the current syllable is reached, execution cannot continue.  Rather than forcing the programmer to deal with this situation explicitly, the assembler steps in and transparently substitutes an extra instruction into the program flow to select a different syllable, sector, or module.  So from the programmer's standpoint, he can just write an uninterrupted block of code without even worrying about the fact that it spans several different memory sectors.  The code transparently modified by the assembler uses slightly more memory and execution time that it superficially appears to from the source code, but that usually doesn't matter. 

From the assembler's point of view, though, it's a bit more complicated.  The simplest case is in reaching the end of syllable 0 for a given memory sector.  The first (unused) location of syllable 1 of that same memory sector is accessible by a TRA instruction, so the assembler transparently inserts a TRA just before reaching the end of syllable 0.

What happens when reaching the end of syllable 1 of a memory sector is much trickier.  For one thing, various factors influence the usage of words at the ends of sectors in syllable 1, so it's a chore for the assembler just to figure out when the end of sector 1 has even been reached.  The next problem is that once the end of syllable 1 has been reached, it can't simply switch to a new syllable:  it instead has to switch to a different sector within the memory module, or perhaps even to a different memory module altogether.  That can't be done with a simple TRA instruction, and requires a more-complex HOP instruction instead.  Unlike a TRA instruction which encodes its target address within the instruction itself, a HOP instruction requires a variable containing the "HOP constant" of the target address.  Naturally, no such variable containing the desired HOP constant normally exists.  So in order to insert a HOP instruction, the assembler must first create such a variable:  it must find an unused location in the current data sector or residual sector, and stick a HOP constant into it.

044700 047910 050170 052790 054910 057850 062640 065020 067470 070680
073610 076720 079190 083030 085700 089420 093330 096170 098760 101450
104090 109850 112570 116390 120760 123850 

Assembly errors:  Errors are marked in the leftmost column of the offending line by a character that presumably indicates the type of error.  In the AS-206RAM assembly listing, the 7 such errors are found, and here are my interpretations of what they mean:

• U at sequence number 027140.  The operand, CBNAV, is not a defined symbol.  It appears as though it was probably correct in earlier software versions, but perhaps should have been changed to CBNAV1 in this version.
  
• U at sequence number 029650.  One of the macro parameters, CBRANW, is not a defined symbol.  There is a handwritten note implying that it probably should have been TEMP6.
• O (no sequence number, p. 67).  This is a full-line comment, but the necessary "*" character in column 1 has apparently been accidentally omitted.  Therefore, the first word in the line (which happens to be "+") has been interpreted as an instruction, and naturally the assembler knows of no such instruction.
  
• V at sequence number 047930.  The assembler mistakenly believes the target location, *-2,  is out of range, because it has been fooled by an automatic switch from memory syllable 0 to syllable 1 slightly before.  In fact, the target location actually is accessible by a TRA instruction (or a HOP instruction), but presumably the original assembler was not smart enough to figure that out.
  
• U (no sequence number, p. 187). The target location, TB5GO, is an undefined symbol.
  
• A (no sequence number, p. 188). The target variable, TBB, is defined, but is not located in either the current data sector or in the residual sector, and is therefore not accessible.
  
• O (no sequence number, p. 190). The target location of a jump, ORBGID, is not located in the current data sector.  The instruction is TRA, and ordinarily that means that the assembler would automatically have used a HOP instruction in place of the TRA. For reasons that are unclear to me, the original assembler did not do so in this case, and instead simply discarded the instruction.
  

Notice that about half of the errors above occur on the (rare!) lines having no card-sequence number.  I think that for pragmatic reasons, sequence numbers would usually have been left off of the punch-cards while the code was under development.  Otherwise, they would have needed to be changed frequently, which would be a great inconvenience.  In other words, the sequence numbers were likely only added once the code had reached a releasable form.  Thus most of the errors appeared in areas of the code that were under active development, which is not terribly surprising.

Alas!  There are 7 more errors exactly like the A type error listed above which the original assembler did not even detect.  These are the pairs of lines of code at card-sequence numbers 026840, 026860, 026880, 026900, 026920, 026940, and 026960.  They're all of the form

LABEL   CLA    CONSTANT
        CLA    CONSTANT+1

Fortunately, it's easy to see how these latter 7 errors should be fixed.  As it happens, there are quite a few examples on the same page of the assembly listing that make it clear the pattern should have instead been

LABEL   CDS    CONSTANT
        CLA    CONSTANT+1

• Columns IM, IS, S, LOC, DM, and DS:  These columns are generated by the assembler and represent the fields of the HOP constant associated with the line of code, from the viewpoint of the assembler.  (The only HOP fields missing are DUPIN and DUPDN, which I suppose would be global settings affecting all memory, as opposed to varying on a line by line basis.)  In particular, the IM and IS fields give the memory module and sector in which the line of code appears, and LOC gives the offset into the memory sector of the word in which the code for the instruction is stored.
• Columns A8-A1, A9, and OP:  These columns are also generated by the assembler, and represent fields of the assembled instruction associated with the line of code.  In particular, OP is the octal value of the particular CPU instruction, as tabulated earlier.
  
• Column CONSTANT:  Yet another field generated by the assembler.  Most lines don't have it, but it appears whenever the operand of the instruction is the address of a numerical constant stored at some other place in memory, but for which the assembler knows the value.  For example, both of the lines in the sample above are the same, 342452244, because both of them relate to a HOP SCPOLY instruction.  As I've already explained above, what the assembler does with a line of code like this is to find the SCPOLY routine (which conveniently for us, actually appears in sample above as well), figures out its HOP constant, allocates a word of memory, stores the HOP constant at that location, and then embeds the address of that location into the instruction.  You can actually see all that happening in the sample.  The HOP constant itself corresponds to the values IM=4, IS=04, S=1, LOC=124, DM=2, DS=14 at the line of code SCPOLY STO 777.  I know it's probably tough to do those conversions in your head, so a handy python script (unHOP.py) is available that can do it for you; and in fact, if you feed 342452244 into unHOP.py, the expected values of IM, IS, S, etc., pop out.  (You also get the extra info that DUPIN=1 and DUPDN=1 ... more on which below.)  Moreover, if you look at the lines where the constant appears, namely the lines reading HOP SCPOLY, and you look at the assembled code, you'll see that the address at which the HOP constant is stored must be DM=2, DS=14, LOC=342.
• Column EXPANSION:  The final field generated by the assembler.  It contains the character '+' for instructions which have been expanded from the CALL macro, but is blank otherwise.  Whether there are other things that can appear there, I can't say.
• Columns LEFT-HAND SYMBOL, INSTRUCTION, OPERAND, COMMENT, SEQUENCE:  I've covered these above, and suspect that they may come directly from the punch cards, unchanged.

What the cross reference does is list each symbol in the program, tell you where it appears in memory, and then tells you how to find all uses of that symbol in the code.  It should be pretty obvious to you that in this example, the symbol UTEMP1 is in memory module 2, sector 17, at address 174.  It may or may not be obvious that where the symbol is used is at the line SEQUENCE numbers 085370, 116640, etc.  Alas, the few pages of the assembly listing which I've elected to freely expose do not include the one which UTEMP1 is allocated, but does include several examples of where it is used.  For example, if you look at the sample code I've marked up in green just a bit above, you can see it used at SEQUENCE number 117600, just as expected.  Not all lines of code have SEQUENCE numbers, and in those cases the SEQUENCE number appearing in the table are generated by simply adding 10 to last card having an explicit SEQUENCE number.

Although I haven't shown any examples in the image above, memory locations which the assembler itself automatically allocates also appear in the segment cross reference table.  Recall that there are cases where the assembler transparently allocates memory locations to store values of constants (like the values of numerical expressions or HOP constants) which are referenced on-the-fly without being explicitly defined in the source code.  These variables are distinguished by having no symbolic name.  Instead they are referenced by their unique values rather than by symbolic name.  I.e., their unique values are used as if they were their symbolic names.  Hence what appears in the table in place of a name is the 9-octal-digit value stored at the location.  They appear in the table after all of the symbolic names.

The octal listing of the program:  This is generated by the assembler and appears at the very end of the listing.  It simply shows what appears at each memory location in the modules, as either a single 26-bit octal word or as two 13-bit syllables.  So you can see in the octal table what each instruction and each pseudo-op assembles to in octal form.  In each of the numbered columns of the table, syllable 1 of the memory word is on the left and syllable 0 is on the right.  For example, referring to the image below, in module 2, sector 00, location 0201 (or 2-00-0201 for short), syllable 1 has the value 10170 and syllable 0 has the value 00174. 

It's important to understand the alignment of the data shown in the octal listing:

• 26-bit data words (none of which are shown below) are shifted 1 bit to the left, and thus displayed as 9 octal digits.  The least-significant bit is always 0.
• 13-bit instructions, syllable 1, are shifted 2 bits to the left, and thus displayed as 5 octal digits.  The least-significant 2 bits are always 0.
• 13-bit instructions, syllable 0, are shifted 1 bit to the left, and thus displayed as 5 octal digits.  The most-significant and least-significant bit are always 0.

This seems weird — the instruction alignment in particular! — but I suppose the rationale is that the open bit positions correspond to the positions of parity bits.  The assembler itself does not bother to compute the parity bits for you, and thus represents them all as 0.  If you take an instruction from syllable 1 and one from syllable 0 as shown in the table, overlap the least-significant octal digit from the left-hand instruction with the most-significant octal digit from the right-hand instruction, then bitwise OR them (or add them), you get the full contents of the memory word.  For example, taking the first two instructions shown below (63224 12436), the full 26-bit content of address 2-00-000, left-aligned, is:

  63224
+     12436
  632252436

However, there's no doubt that the visual representation of this data is undoubtedly weird.  And, it's unclear just how useful it is ... certainly not at all, if you're trying to disassemble the instructions by eye!  I've provided a handy python script (unOP.py) that you can use to provide a simple-minded disassembly of the instructions found in the octal listing.  The script assumes that if an octal number you give it has a leading space character then it is in syllable 0, and that if it has no leading space it is in syllable l.  For example, feeding "63224" into it gives back "MPH 315", while feeding " 12436" into it gives back "CLA 124".

MIT Instrumentation Laboratory vs IBM Federal Systems Division

yaLVDC, the LVDC CPU Emulation

The inclusion of this section is an act of pure optimism.  We don't have a working LVDC CPU emulator as of yet.

An important thing to understand, in terms of simulation, is that the LVDC was not fast enough to keep up with the real-time calculations needed to directly control the rocket.  The results would have been too stair-steppy, too choppy.  25 outputs per second isn't enough!  What happened instead is that a separate unit — the LVDA — was needed to accept the digital outputs from the LVDC and turn them into smoothly-changing controls for the rocket. And when I say smoothly-changing, I mean both smoothly in time as well as in terms of electrical properties. Thus any decent simulation would require simulation of not only the LVDC but also of the LVDA, the latter of which is currently outside the scope of what's being provided here.

An interesting aspect of the LVDC is that since it is essentially a "black box" that outputs real-time control signals in response to real-time inputs, it is possible to create a reasonably satisfactory behavioral simulation for it in the absence of the original software, if one simply knows the guidance equations relating the outputs to the inputs.  While creating behavior simulations is not an objective of the Virtual AGC project as far as the Apollo CPUs are concerned, there are people engaged in creating such simulations for the Orbiter NASSP project and elsewhere.

yaASM.py, the LVDC Cross-Assembler

yaASM.py [OCTALS.tsv] <INPUT.lvdc >OUTPUT.lst

• Comments can be added by using the "#" character in column 1.  They are ignored during comparisons.
  
• Empty lines are also ignored, and can be added for beatification purposes.
• Lines with 17 tab-delimited fields contain octal data for up to 8 memory words.  Exactly 17 fields are always present, even if some of the memory locations are unused.
  
• Field 1 is a 3-digit 0-padded octal number in the range 000-377 (octal) that gives the starting memory offset of the line.  Thus the number is always divisible by 8.
• The remaining 16 fields are pairs of 2 fields each:
• The first field contains one of the following:
• A 9-digit octal number (actual format " %09o% ") for a data word.  Notice that the 9-digit number is bracketed by a space character on both the right and left, so the field is actually 11 characters wide.  It can also be a string of 11 spaces ("         ") if the memory location is not used.
  
• A pair of 5-digit octal numbers (actual format "%5o %5o") for two assembled instructions.  The left-hand number is the assembled instruction for syllable 1 and the right-hand number is the instruction for syllable 0.  Either the left-hand or right-hand number can also be 5 spaces ("     ") if not used.
• The second field contains just the character "D" for a memory word that is used, or just a space " " for a word that is not used.
  
• Lines with 3 or more fields whose first field is the word "SECTOR" mark the beginning of a memory sector ... i.e., the next location will be 000.
• Field 1, as already mentioned, is the word "SECTOR".
• Field 2 is the number of the memory module, and is in the range 0-7.
• Field 3 is the number of the memory sector within the module.  It is a 0-padded 2-digit octal number in the range 00-17 (octal).
• Fields 4+ are ignored.  However, field 4 is often an encoded description of the proof-reading processes that have been undertaken to insure the correctness of the sector's data.

Completely-empty memory sectors do not need to appear in the file at all.  However, if any portion of a memory sector is used, the sector appears fully in the file.  I.e., all of the lines with location fields 000, 010, ..., 370 will appear, even if most of their fields are blank.

This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2019-09-23.