Contents

• What is the Gemini Spacecraft Computer (OBC)?
• Peripheral Devices
  
• Gemini Documentation
• Evolution of the Flight Software
• OBC Architecture and Interfacing
  
• References
• General Characteristics of the OBC
• Layout of Memory Words
• CPU Instructions
• I/O Signals (for PRO Instruction)
• Discrete Inputs (for CLD Instruction)
• Subroutine Linkage
  
• Telemetry
• Uplink
• Downlink
• Rendezvous Radar
• Aerospace Ground Equipment (AGE)
• Time Reference System (TRS)
  
• Auxiliary Tape Memory (ATM)
  
• OBC Assembly Language
• General format
• Shorthands for some instructions
• Pseudo-ops
  
• Virtual AGC simulation software
  
• The Gemini Catch-Up and Rendezvous Simulation Program
• Background
• Source Code
  
• Building the Catch-Up and Rendezvous Simulation Program
• Running the Catch-Up and Rendezvous Simulation Program
• Data for the Catch-Up and Rendezvous Simulation Program
• Theory of Operation and Porting-Problems for the Catch-Up and Rendezvous Simulation Program
• yaOBC, the OBC CPU Emulation
• yaASM, the OBC Cross-Assembler
• yaPanel, the Control-Panel Emulation (includes discussion of MDIU, PCDP, IVI, ...)
• Communications protocol
  
• Plea for Data
• Reminiscences and Factoids from the Original Developers
  
• Homage
  

What is the Gemini Spacecraft Computer (OBC)?

The Gemini spacecraft computer is, as the name implies, the onboard computer of the Gemini spacecraft. The computer seems to have been referred to variously as the "spacecraft computer", the "digital computer", or the "On-Board Computer" (OBC). It was the Gemini equivalent of Apollo's AGC, though with more limited capabilities and functionality. Its basic use was in the post-launch phases of missions (orbit phase, retrograde phase, re-entry phase), because the Titan II rocket which carried the Gemini spacecraft into orbit was guided by its own (separate) ACS-15 guidance computer, but there was provision also for switchover to the Gemini computer for backup guidance if the need arose. Interestingly, the OBC could be used for automatic attitude control of the spacecraft, but not automatic velocity control; rather, it performed necessary calculations for maneuvers such as orbital insertion or re-entry, and the pilots then performed the manual chores of actually adjusting the spacecraft velocity appropriately.

The OBC was designed and manufactured by IBM's Federal Systems Division, in Owego, New York, just as Apollo's Launch Vehicle Digital Computer (LVDC) was. The OBC and the LVDC are extraordinarily similar at the CPU level.

Peripheral Devices

This section contains a general overview of the OBC's peripheral devices, but many of them are discussed in much greater detail in later sections.

From a user standpoint, the most visible of the OBC's peripheral device was the Manual Data Insertion Unit (MDIU)—the Gemini equivalent of the Apollo DSKY—which comprised the Modular Display Keyboard (MDK) and the Modular Display Readout (MDR).


These were on the Pilot's (as opposed to the Command Pilot's) side of the control panel, at the lower right in the drawing below. The small image below is from the familiarization manual, but if you click on it you'll get a much bigger, much more detailed drawing from the Gemini 5 Mission Report.

Gemini Documentation

Sadly, documentation we've been able to collect for the OBC lags far behind that of the AGC or even that of the Abort Guidance System (AGS). What little survives that we have been able to access can be found in our Document Library.

Evolution of the Flight Software ... or, "Everybody Loves Math Flow 7"

Almost all of the information we have about the Gemini OBC software is second-hand or circumstantial. Hard data is in short supply. Useful information we don't have includes:

• The names of any software developers.
  
• Most importantly, any of the actual flight program source code.

That's a lot that we don't know. What do we know?

Well, as far as naming is concerned, the flight software seems to have been called simply the "operational program". On the subject of versioning of the operational program, from information in the familiarization manual we know which software versions were used for Gemini 6 and 8, and can make some inferences about the versions used for Gemini 9-12. We also know, according to James Tomayko's Computers in Spaceflight, Chapter 1, section 4, that there were eventually nine different versions of the operational program. While Tomayko does not specifically tell us what versions of the program flew on which missions, he does tell us that the operational programs were characterized in terms of something called the "Gemini Math Flow". The Math Flow is a way of describing a software development process in which various software modules were developed and added to or removed from the operational program over time. The Math Flow characterizes the software in terms of what combination of modules is included. The known relationships—as nearly as I can make them out from Tomayko's description—between the various modules and the different versions of the Math Flow are given in the following table.

Software modules	Math Flow version →→→ increasing time →→→
	1	2	3	4	5	6	7
Pre-launch							Yes
Ascent	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Catch-up	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Orbital navigation		Yes
Rendezvous	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Re-entry initialization		Yes		Yes	Yes
Re-entry	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Executor							Yes

All of these software modules are related in obvious ways to the various mission phases, except "Executor". Executor is the interface that interrelates the other software modules and allows them to interact with each other, as well has implementing certain common functionality among them.

But remember, just because two versions of the operational program or of the Math Flow might have had the same software modules, it doesn't imply that the modules were unchanged. Tomayko also tells us which Math Flow versions were used in which missions, and that brings us to the following:

Spacecraft	Operational Program version	Math Flow version	Comments
1			Unmanned mission. Since Gemini I was apparently intended principally as a structural test of the spacecraft, it may not have had a computer onboard.
2		1	Unmanned mission.
3		3
4		3
5		6
6	6	6
7		6
8	7	7	The principal difference between the sixth and seventh operational programs is claimed by the familiarization manual to have been the reworking of the program so that portions of it could be loaded into the computer from the (new) Auxiliary Tape Memory (ATM) during the mission.
9	7	7
10	7?	7	Volume 2 of the familiarization manual claims that the "seventh operational program" was used in spacecraft 8 and all subsequent spacecraft. But the manual predates the launch of Gemini 10, so that statement cannot be taken as authoritative.
11	7?	7
12	7?	7

So it's possible (if not certain) from this table that the operational program versions might have been identical to Math Flow versions, and that the actual flown versions may have been 1, 3, 6, and 7.

There's more info on this topic below, in the section covering the Auxiliary Tape Memory (ATM).

Finally ... though we have no operational program source code, the Project Gemini Familiarization Manual describes the program in very good detail, both textually and in terms of flowcharts. So it may be possible to recreate a satisfying if not 100% accurate version of the program using those descriptions.

OBC Architecture and Interfacing

References

The principal known sources of information about the computer itself are the "Guidance and Control" sections (Section VIII) of the Project Gemini Familiarization Manual, Volume 1 and Volume 2, and most of the information on this web-page was extracted from those sources. If you find my redigesting of the material too poor, you may want to read the Manual instead. However, any simulation software, assemblers, etc., will be based on my understanding and hence on the content of this web-page, so please bring any errors to my attention.

General Characteristics of the OBC

The OBC measured 18.9"(H)×14.5"(W)×12.75"(D), and weighed 58.98 pounds. OBC power was supplied by the IGS Power Supply, which was itself powered from the spacecraft's main +28VDC bus or (for very brief main-power outages or brownouts) the Auxiliary Computer Power Unit (ACPU). The OBC required various voltages (+27.2VDC, +9.3VDC -27.2VDC, +20VDC, +28VDC, and 26VAC, but the existing documentation is inconsistent on the exact voltages used), and itself supplied the MDIU (+25VDC, -25VDC +8VDC) and these latter three voltages were what was actually used internally by the OBC itself.

The computing characteristics were:

• 39 bits per memory word. Each memory word comprised three "syllables" (syllable 0, syllable 1, and syllable 2) of 13 bits each.
• 4096 words of memory, in a ferrite core array. All of this RAM was writable—i.e., there was no read-only memory—but the readout of the memory was non-destructive.
• The memory was logically divided into 16 "sectors" of 256 words each.
• At any given time only 2 sectors are actually accessable, the current sector (selectable under program control) and the "residual" sector (sector 17 octal).
  
• The third syllables of memory words were writable by the OBC hardware, but this function was disabled after the spacecraft left the hangar, so at that point the 3rd syllables were effectively read-only. Consequently, data words always needed to be placed into the first two syllables of memory words. The addressing of data by CPU instructions enforced this data alignment anyway.
  
• "Instruction words" were 13 bits each, and "data words" were 26 bits each, so any given memory word could have had a data word and/or several instruction words packed into it. There were also provisions for "short" data words of 13 bits, but these short data words could be used only for testing purposes by Aerospace Ground Equipment (AGE), and so were irrelevant for software.
• Integer arithmetic was 2's-complement.
  
• Instruction cycle time was 140 μs and all instructions required a single cycle except for MLT and DIV.
  

Layout of Memory Words

As mentioned earlier, memory words are 39 bits, comprising three 13-bit "syllables". In most ways, the syllable is really the natural memory unit, and not the word.


In the discussion below, all bits are defined and discussed relative to their "bit positions". These "bit positions" are central to the thinking of the original Gemini developers, because they relate the ordering in which data was serially shifted in and out of the ferrite-core array, and the original developers' thinking seems to have been steeped in knowledge of the underlying hardware of the CPU. However, the underlying hardware is of very little concern to any modern software developer, so it's best to just think of the "bit positions" as being some sort of arbitrary numbering system. Definitely do not think of them in terms of least-significant vs. most-significant, as that issue will be covered at the very end of this section.

Here is the layout of a 13-bit "instruction word" (really, an instruction syllable):


Bits OP1-OP4 determine the specific instruction, while bits A1-A9 represent the operand of the instruction. (Designations like "A1" come directly from the Gemini documentation, so please don't confuse them as meaning "address" bits. In some cases they are; in some cases they are not.) In most cases A1-A8 select a particular word within a 256-word memory sector, while A9 determines if it is the currently-selected sector (A9=0) or the residual sector (A9=1). (Recall that memory is divided into 16 sectors of 256 words each, and that sector 17 octal is the "residual" sector. We'll discuss how the "current" sector is chosen momentarily. The fields A1-A3 and A4-A6 are often grouped together and given the special names X and Y, respectively. Similarly, we'll refer to OP1-OP4 as the Opcode.

For a normal 26-bit data word, we have the following layout, in which there are 25 bits of data and 1 sign bit. Recall that this is a 2's-complement value.


Numerical data can be interpreted in two different ways, depending on the interpretation of the software. Obviously, the data could be interpreted as a simple 2's complement integer. It can also be interpreted as a fractional value with absolute value less than 1.0. In the latter interpretation, there is an implied factor of 2^-25 that is not stored in memory.

As far as selection of the current sector is concerned, that is done by using the HOP instruction (see the next section) to load a so-called "Hop constant" into hidden CPU registers. The layout of a HOP constant is as follows:


In this scheme:

• A1-A8 selects a word offset into the 256-word memory sector from which to fetch the next instruction.
• A9 determines whether the offset is in the selected sector (0) or the residual sector (1).
• SYB,SYA selects the syllable of the next instruction (0,0 for syllable 0, 0,1 for syllable 1, and 1,0 for syllable 2).
• S1-S4 select the memory sector. After the HOP instruction executes, this setting persists until another HOP instruction changes it.
• S5 selects between "normal" data mode (S5=0) and "special" data mode (S5=1). In normal mode, data words are in syllables 0 and 1. In special mode, the data only comes from syllable 2 and only fills the least-significant 13 bits, while the most-significant 13-bits are all 0. Again, this is a persistent mode until changed by a HOP instruction. (A consequence of being in the special mode is that any HOP instruction will return to normal mode, since the SYB, SYA, and S5 bits of the HOP constant are among the 13 most-significant bits, and therefore will always be zero.) Since the the OBC ability to write to syllable 2 is disabled after the spacecraft has left the hangar, no STO or SPQ have any effect in special mode. (I don't see why SPQ wouldn't work, but that's what the manual says!) The special mode is apparently only used for testing the hardware arithmetic modules, and therefore isn't used in normal operation.
• At power-up, it is as if a HOP constant of 0 is loaded; i.e., the program starts executing at syllable 0 of offset 0 in sector 0.
  

As far as the ordering of bits in terms of significance is concerned, the following scheme applies. Yes, it's wacky and the labeling is inconsistent. Don't blame me.

Field	Most-significant bit	Least-significant bit
Operand (A1-A9)	A9	A1
Opcode (OP1-OP4)	OP4	OP1
X (A1-A3)	A3	A1
Y (A4-A6)	A6	A4
Data (M1-M25)	M1	M25
Sector (S1-S4)	S4	S1

When expressing these various field values as multi-bit collections rather than as individual bits, one conventionally uses octal notation in the usual manner, with more-significant digits being to the left and less-significant digits to the right. Curiously, 26-bit data words, when written in a 9-digit octal notation are aligned at the most-significant bit rather than the least significant bit, so that they are all effectively multiplied by 2. For example, if M1=1 and M2 through M25 and S are 0, then this is written as the octal value 000000002 rather than 000000001. This strange convention does not seem to be applied to any of the other field types, but most of the other fields span an integral number of octal digits.

CPU Instructions

Since there are so many similarities between the OBC instruction set and Apollo's LVDC instruction set, I'll explicitly point out the differences below. A difference not pointed out in the table is that the LVDC instructions MPH, XOR, and CDS, EXM are not present in the OBC.

Mnemonic	Opcode (OP1-OP4) in octal	Timing (140 μs cycles)	Description of the instruction
HOP	00	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 TRA.
DIV	01	1 (results available after 6)	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 via the SPQ instruction from the 5th instruction following the DIV. In other words, 4 other instructions not involving multiplication or division can be performed in the interval between DIV and SPQ.
PRO	02	1	Inputs or outputs an i/o "signal" into or from the accumulator. (In the AGC these are called "channels". In current terminology, we'd probably usually refer to them as "ports".) Whether or not an input or an output is performed depends on the particular signal chosen. The X (A1-A3) and Y (A4-A6) operand fields are used for signal selection. A9 is used as well. For an output operation, it determines if the accumulator should be cleared after the output (A9=1) or preserved (A9=0). For an input operation, it determines if the data should be loaded into the accumulator (A9=0) or logically OR'd with the accumulator (A9=1). A table of the i/o signals vs. addresses is given in the following section. (The PRO instruction is essentially equivalent to the LVDC PIO instruction, but the selection of i/o signals is different.) The documentation does not explain this, but I think that when the PRO instruction is accessing a single-bit signal, only the accumulator's sign bit is used as the output or the input. The remaining bits are unaffected (on input) or are "don't care" (on output). See also the description of shorthands for various instructions.
RSU	03	1	Same as SUB (see below), except that the order of the operands in the subtraction is reversed.
ADD	04	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".
SUB	05	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.
CLA	06	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".
AND	07	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".
MPY	10	1 (results available after 3)	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. The result is available via the SPQ instruction on the 2nd instruction following MPY. Any other instruction not involving multiplication or division can be performed between the MPY and the SPQ.
TRA	11	1	This is an unconditional jump instruction, which branches to the address embedded in the instruction. Bits A1-A9 of the embedded address represent the new offset within either the currently-selected sector or the residual sector. Note that the syllable remains the same, so if (for example) the TRA is itself in syllable 1 of the current program counter, then the next instruction executed will be at syllable 2 in the new program counter. (This differs from the behavior of the corresponding LVDC instruction, in that the LVDC instruction allows selection of the target syllable via A9, but does not allow the new program counter to be in the residual sector.) See also the description of shorthands for various instructions.
SHF	12		Performs a logical shift operation on the accumulator. For this instruction, only bits A1-6 are actually used, as follows: X (A1-3) Y (A4-6) Description of operation 1 2 Shift "right" one position 0 2 Shift "right" two positions X 3 Shift "left" one position X 4 Shift "left" two positions (Other) Clears the accumulator But what do "left" and "right" mean? Fortunately, "left" implies multiplication by powers of two, and "right" division by powers of two, just as modern programmers are accustomed to. For the left-shifts, 0 is shifted into the least-significant bit at the right. For the right-shifts, the sign-bit is shifted into the most-significant bit at the left. Note that this instruction is similar to the corresponding LVDC instruction, but differs in details. See also the description of shorthands for various instructions.
TMI	13	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-A9 of the embedded address represent the new offset within the currently selected 256-word instruction sector or the residual sector. See also TNZ. (This differs from the behavior of the corresponding LVDC instruction, in that the LVDC instruction allows selection of the target syllable via A9, but does not allow the new program counter to be in the residual sector.)
STO	14	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 accumulator retains its value.
SPQ	15	1	Store a product or quotient (computed with MPY or DIV) into the accumulator. (This instruction is equivalent to the LVDC instruction CLA 0775.)
CLD	16	1	A discrete input selected by the operand address is read into the accumulator. The entire accumulator is overwritten. A table of the allowed discretes follows later. (This instruction does not exist in the LVDC.) See also the description of shorthands for various instructions.
TNZ	17	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.

I/O Signals (For PRO Instruction)

Note that in assembly language, in the operand for a PRO instruction, the Y operand field would proceed the X operand field. So, for example, if X=3 and Y=4, the instruction would be PRO43. That's the opposite of present ordering of the columns in the table below and could be confusing, for which I apologize, but I'm too lazy to completely rewrite the table.

Operand		Input / Output	Signal	Comment
X (A1-A3)	Y (A4-A6)
0	0	In	Digital Command System shift pulse gate	Causes a 24-bit word buffered in the Digital Command System (DCS) to be read into bits M1-M24 of the accumulator. Or, reads data from the Rendezvous Radar (if any).
0	1	TBD	Data Transmission System control gate	TBD
0	2	In/Out	Time Reference System data and timing pulses	The action of this signal seems pretty complex. Please read the section on the Time Reference System (TRS) for my conclusions as to what it's actually supposed to do.
0	3	Out	Digit magnitude weight 1	Used in conjunction with "Digit magnitude weight 2", "Digit magnitude weight 4", and "Digit magnitude weight 8" to write a particular digit to an MDR position previously selected using the "Digit select weight X" outputs. The weights derive from a BCD value of the digit whose display is desired.
0	4	Out	Reset data ready, enter, and readout	When zeroed, signals the MDIU to reset its internal buffer so that a numerical keystroke subsequently be collected. It is unclear if this needs to be returned to a non-zero state later. The CLD inputs associated with the ENTER and READ OUT keys also are cleared as a result.
0	5	Out	Digit select weight 1	Used in conjunction with "Digit select weight 2" and "Digit select weight 4" to select the next digit position to which a display value will be output to the MDIU. It is not really explained how these work, but I think that they are used to form an index from 0-7 in the obvious way, and that the leftmost address digit is 0, the 2nd address digit is 1, the leftmost message digit is 2, and so on.
0	6	Out	Memory strobe	I believe that this signal is used only in conjunction with the AGE for testing purposes. When the accumulator is negative, it seems to enable a hardware mode called "marginal early" may help in determining how robust the memory access is with respect to marginal timing. When the accumulator is positive or zero, it disables this diagnostic feature.
1	0	Out	Computer ready	Signal to the Digital Command System (DCS) that the OBC wishes to read a buffered uplinked data word. Also used to tell the Rendezvouse Radar, if any, that radar data is required. In the latter case, a 20 ms. delay must occur afterward before polling the radar-ready discrete input (CLD00).
1	1	Out	Drive counters to zero	For setting a delta-V display on the IVI to zero. First do PRO11 with the accumulator negative, then (see "Select X counter") select the X, Y, or Z axis, then do PRO11 with the accumulator positive or zero to return to the normal state. CLD31, CLD25, and CLD26 can be subsequently used for feedback that the displays are actually at zero.
1	2	Out	Enter	When inactive, the Time Reference System (TRS) is capable of receiving timing data (like TR or TX) from the ODC. When active, the ODC can receive timing data (like ET or TR) from the TRS.
1	3	Out	Digit magnitude weight 2	See Digit magnitude weight 1
1	4	Out	Display device drive	When zeroed, the MDIU display drivers are turned off. When non-zero, the display drivers are turned on.
1	5	Out	Digit select weight 2	See Digit select weight 1
1	6		Autopilot scale factor
2	0	Out	Pitch resolution	Controls the range switch for Pitch Error (or down range error) output. If the sign bit is positive, then there is a 6-to-1 attenuation applied; if the sign bit is negative, there is no attenuation.
2	1	Out	Select X counter	Used along with "Select Y counter" to select one of the IVI's delta-V displays to receive additional commands, as follows: X-axis: PRO12 with accumulator negative, PRO13 with accumulator positive or zero. Y-axis: PRO12 with accumulator positive or zero, PRO13 with accumulator negative. Z-axis: PRO12 with accumulator negative, PRO13 with accumulator negative.
2	2	Out	Aerospace Ground Equipment data link	For outputting a single data bit to the dedicated AGE data link.
2	3	Out	Digit magnitude weight 4	See Digit magnitude weight 1
2	5	Out	Digit select weight 4	See Digit select weight 1
2	6	In	Reset start computation	From the PCDP's RESET switch.
3	0	Out	Yaw resolution	Controls the range switch for Yaw Error (or cross-range error) output. If the sign bit is positive, then there is a 6-to-1 attenuation applied; if the sign bit is negative, there is no attenuation.
3	1	Out	Select Y counter	See "Select X counter".
3	2	Out	Aerospace Ground Equipment data clock	Provides a data clock, one pulse at a time, for reading data on the dedicated AGE data link.
3	3	Out	Digit magnitude weight 8	See Digit magnitude weight 1
3	4	In	Read Manual Data Insertion Unit insert data	Reads a keystroke that has been buffered in the MDIU. This operation should be done only in response to a separate discrete "Data ready" input via CLD. The BCD value of the digit is stored into bits M1-M4 of the accumulator. A PRO40 should be performed afterward to clear the MDIU buffer and allow the next keystroke to be collected, and additional PRO instructions should be used to display the digit on the MDIU.
3	6	Out	Reset radar ready	Sent to the Rendezvous Radar, if any, to reset its discrete input buffer.
4	0	Out	Roll resolution	Controls the range switch for Roll Error output. If the sign bit is positive, then there is a 6-to-1 attenuation applied; if the sign bit is negative, there is no attenuation.
4	1	Out	Elapsed time control and Time Reference System control reset / ATM wind-rewind reset	Signal to the Time Reference System (TRS) that the data about to be fetched from the TRS with PRO20 commands is the elapsed time (ET). This output should persist for 9-15 ms. before being returned to the normal state. It also apparently acts to reset the TRS control circuitry. When used instead with the Auxiliary Tape Memory (ATM), it commands the ATM to stop winding or rewinding. I believe that it also turns off the ATM ERROR lamp.
4	3	Out	Computer malfunction	To the PCDP's MALF light.
4	4	Out	ATM verify/repro command	Send a command to the Auxiliary Tape Memory (ATM) to begin data output. I assume that the accumulator is negative to begin the output and zero or positive to end it.
4	6	TBD	Second stage engine cutoff	TBD
5	0	Out	Computer running	To the PCDP's COMP light.
5	1	In?/Out	Time to start re-entry calculations control / ATM wind command	The use for "time to start re-entry calculations" is TBD. For ATM usage, I believe that this initiates fast-forwarding of the tape drive. I assume that the value in the accumulator should be negative, however, I don't think that outputting a positive or zero value stops the winding. Instead, use PRO14.
5	2	Out	Time to reset control / ATM rewind command	Signal to the Time Reference System (TRS) that transfer of time-to-equipment-reset (TX) data is desired. This output should persist for 9-15 ms. before being returned to the normal state. For ATM usage, this initiates rewinding of the tape drive. I assume that the value in the accumulator should be negative, however, I don't think that outputting a positive or zero value stops the rewinding. Instead, use PRO14.
5	3	Out	Write output processor	For incrementally adjusting the delta-V displays of the IVI. First, the X, Y, or Z display is selected (see "Select X counter" above). No more than 1 ms. later, PRO35 is used to begin the update. The value in the accumulator comprises the sign bit and M1-M12, so the maximum change is -4096 to +4095. Since the displays are actually -999 to +999, in theory the adjustment range is more than full. In practice, only very small adjustments would be made. My understanding of what the hardware actually does is to increment or decrement the displays by 1 every 21.5 ms., and that it will not be ready to process another delta-V until the count has reached zero. For example, trying to change the display by 25 would take about half a second, and no other outputs to the IVI should take place in that interval. The "Velocity error count not zero" discrete (CLD22) can be polled to determine when the increment/decrement pulses have all been sent to the display and the counter has reached zero.
5	4	In	Read delta velocity	This port is used to read the change in velocity from the platform electronics, and to zero the reference velocity for the next readings. A single PRO45 instruction reads the ΔV from all three axes into the accumulator. Documentation is unclear as to how the data appearing in the accumulator is packed, but my nearest guess as to what it's trying to tell us is that each of the X, Y, and Z axis readings is a 4-bit 2's-complement value (thus being in the range -8 to +7), and that they are packed into the accumulator as follows: X: S (sign), M1, M2, M3 Y: M4 (sign), M5, M6, M7 Z: M8 (sign), M9, M10, M11
5	5	TBD	Input processor time	TBD
5	6	Out	Time to retrofire control	Signal to the Time Reference System (TRS) that transfer of time-to-retrograde (TR) data is desired. This output should persist for 9-15 ms. before being returned to the normal state.
6	3	In	Read pitch gimbal	These ports are used for reading gimbal angles from the inertial platform. The units used are TBD. 15-bit values are provided, including the sign bit and M1-M15. The remaining bit positions are zeroed. Each of the PRO commands associated with these ports both reads a previously-measured value and begins accumulating a new measurement, so these ports must be accessed in a very specific procedure to get a complete set of readings, as follows: ... at least 5 ms. from last read of gimbals ... PRO36 # Ignore the value received. ... wait 5 ms. or longer ... PRO46 STO PITCH ... wait 5 ms. or longer ... PRO56 STO ROLL ... wait 5 ms. or longer ... PRO36 STO YAW
6	4	In	Read roll gimbal
6	5	In	Read yaw gimbal
7	0	Out	Pitch error command	For the re-entry mode, the outputs are down-range error rather than pitch error, and cross-range error rather than yaw error. These are values which are expected to be output at intervals of 50 ms. or less, and feed into a 7-bit digital-to-analog converter for driving the Flight Director Indicator (FDI). The output comes from the accumulator sign bit and from bit-positions M8-M13. The analog outputs also feed into range switches which can attenuate the signals, and are controlled by PRO02, PRO03, and PRO04.
7	1	Out	Yaw error command
7	2	Out	Roll error command

Discrete Inputs (For CLD Instruction)

Note that in assembly language, in the operand for a CLD instruction, the Y operand field would proceed the X operand field. So, for example, if X=3 and Y=4, the instruction would be CLD 43. That's the opposite of present ordering of the columns in the table below and could be confusing, for which I apologize, but as I said above, I'm too lazy to rewrite the table.

Operand		Signal	Comment
X (A1-A3)	Y (A4-A6)
0	0	Radar ready	Indicates that data from the Rendezvous Radar (if any) is ready.
0	1	Computer mode 2	From the PCDP's COMPUTER mode selector rotary dial. The rotary dial has 7 positions, encoded onto 3 discrete inputs, "Computer mode 1", "Computer mode 2", and Computer mode 3". The encoding is: Computer Mode 1 Computer Mode 2 Computer Mode 3 Mode 0 0 0 TBD 0 0 1 Pre-launch 0 1 0 Ascent 0 1 1 Catch-up 1 0 0 Rendezvous 1 0 1 Re-entry 1 1 0 TBD 1 1 1 TBD
0	2	Spare
0	3	Processor timing phase 1
0	4	Spare
1	0	Data ready	From the MDIU. It indicates that a digit-keystroke has been buffered within the MDIU and is ready to be read.
1	1	Computer mode 1	See "Computer mode 2".
1	2	Start computation	From the PCDP's START switch
1	3	X zero indication	Indicates that the IVI's X-velocity display is at zero.
1	4	ATM clock	See the ATM section.
2	0	Enter	From ENTER key of MDIU
2	1	Instrumentation System sync	From Instrumentation System (IS), to trigger beginning of a new downlink cycle every 2.4 seconds.
2	2	Velocity error count not zero	From the IVI. It is an indeicator that a prior "Write output processor" (PRO35) has reached completion.
2	3	Aerospace Ground Equipment request	From the AGE. Becomes active (accumulator negative) when a word is available on the dedicated AGE data link.
2	4	Spare
3	0	Readout	From READ OUT key of MDIU
3	1	Computer mode 3	See "Computer mode 2".
3	2	Spare
3	3	ATM on	See the ATM section.
3	4	ATM data channel 2	See the ATM section.
4	0	Clear	From CLEAR key of MDIU
4	1	ATM mode control 1	See the ATM section.
4	2	Simulaton mode command
4	3	ATM end of tape	See the ATM section.
4	4	ATM data channel 3	See the ATM section.
5	0	Time to start re-entry calculations	This is a signal from the Time Reference System (TRS) that its TR (time to retrograde) counter has reached zero.
5	1	ATM mode control 2	See the ATM section.
5	2	Y zero indication	Indicates that the IVI's Y-velocity display is at zero.
5	3	ATM data 1	See the ATM section.
5	4	Spare
6	0	Digital Command System ready	This is a signal from the Digital Command System (DCS)—i.e., the digital uplink from ground control—that data is available for the OBC to read. In general, it is expected that this signal be polled at 50 ms. intervals or shorter.
6	1	Fade-in discrete	From the PCDP's FADE-IN. This is a signal from a relay, but anything beyond that is TBD.
6	2	Z zero indication	Indicates that the IVI's Z-velocity display is at zero.
6	3	Umbilical disconnect
6	4	Spare
7	0	Instrumentation System request
7	1	Abort transfer	From the PCDP's ABORT switch. The software should poll it during ascent mode, and switch from ascent mode to re-entry mode if the input becomes active.
7	2	Aerospace Ground Equipment input data	Reads a single data bit on the dedicated AGE data link.
7	3	Spare
7	4	Spare

Subroutine Linkage

I cannot find any reference to how subroutine linkages were performed, nor do there seem to be an special facilities for making them easier to work with such as the LVDC's "circulating HOP register". (Recall that the LVDC is a very similar descendent of the OBC.) There are some clues in LVDC code samples kludged together by MIT's Instrumentation Lab personnel that the calling sequences might have been something like the following:


In evaluating the likelihood that this was the technique used, we should observe firstly that it does work and is reasonably efficient. The only place where it wouldn't work is for interrupts, since there would be no opportunity with interrupts to pre-load the accumulator with a return address, but the OBC does not appear to have had any facility for interrupts. The LVDC does have interrupts, and consequently it was necessary in the LVDC to replace this type of subroutine linkage with a slightly improved method. On the other hand, we don't really know if the Instrumentation Labs personnel—who, after all, were familiar with AGC assembly language and not with LVDC assembly language—knew what they were doing when the created the LVDC code samples I mentioned.

By the way, it isn't known what pseudo-ops OBC assembly language had, so I don't really know if there was or wasn't a VAR pseudo-op for reserving memory for variables, but there obviously must have been something similar. (In AGC assembly language, the pseudo-op is ERASE, while in AGS assembly language it is BSS.) The HOPCON pseudo-op used here is derived from the same LVDC code samples created by Instrumentation Labs personnel, and not from any Gemini documentation.

Telemetry

Uplink

It was possible to digitally uplink data from ground control to the OBC, via the Digital Command System (DCS). The procedure for fetching a single word from the DCS is as follows:

1. Poll CLD06 at intervals of 50 ms. or less to determine if data is ready.
   
2. When data is ready:
1. PRO01 to tell the enable the DCS to send the data.
2. PRO00 to fetch the 24-bit data word into the accumulator bits M1-M24.
   

In the fetched word, bits M1-M18 contain a data value, while bits M19-M24 contain an address in the range 000-077. The flight software is expected to store the data at the specified address.

The obvious limitations here are that full 26-bit data words are not provided and that the address-range covered is limited. As a variation, there is an "extended" protocol that transmits word pairs rather than single words. The extended protocol allows 26-bit data words and slightly extends the covered address range. It works as follows:

• Consecutive command words are transmitted to address 20 followed by address 21.
• Rather than writing to either address 20 or 21, the two 18-bit data fields are combined into a 36-bit structure.
• A full 26-bit data field and up to 10 address bits can be extracted from the 36-bit structure. The locations of these fields are TBD.
  
• The 26-bit data is actually written to the 10-bit address, if the 10-bit address was in the range 000-117 octal.

Downlink

Conversely, telemetry data could be digitally downlinked from the OBC to ground control. The flight software output 21 data words to the Instrumentation System (IS) for downlinking every 2.4 seconds. The flight software would snapshot the values of 21 memory locations (dependent on the operational mode) into a memory buffer, and then to output the contents of that buffer for transmission. Specifically, the way it works is that:

1. CLD07 is polled at 50 ms. or less intervals. When it becomes active (accumulator negative), the steps below are taken.
2. CLD12 is tested.
• If the accumulator is negative, then the software should snapshot the mode-dependent 21 memory locations into the buffer and output the first buffer word with a PRO10 instruction.
• If instead the accumulator positive or zero, then the software should output the next buffer word in sequence using a PRO10 instruction.

Rendezvous Radar

For those spacecraft having a Rendezvous Radar, the following procedure is used to fetch data from it:

1. PRO63 is used to reset the radar's discrete input buffer.
2. PRO01 is used to tell the radar that the OBC wants data.
3. Wait 20 ms.
4. Test if data available using CLD00.
5. If data is ready (i.e., if accumulator is negative), perform a code-sequence like the following:

The Range data is positive (being a magnitude), and is stored in accumulator bits M8-M24. The least-significant bit (M25) is thus not used. If M8-M11, the 4 most-significant bits, are all 1, then the data should be discarded. The two sine values are stored in M15-M24.

Aerospace Ground Equipment (AGE)

The AGE provides a dedicated data link from the OBC to (as implied by the name) aerospace ground equipment, and provides a way of performing tests or other diagnostic activities by connecting special equipment. The technique of reading a word from the AGE is as follows:

1. Poll CLD32 until active (accumulator negative).
2. Fetch an 18-bit word by repeating the following 18 times:
1. PRO23 with accumulator negative. (Starts a pulse on the AGE data clock.)
2. Wait 2.5 ms.
3. PRO23 with accumulator positive or zero. (Ends the clock pulse.)
4. Wait 1.5 ms.
5. CLD27. (Reads the data bit.)
6. Wait 1.5 ms.
   

Assuming that what the software does with this data is to pack it into bits M1-M18 of a data word, with the first bit read going into M1 and so forth, M4-M1 will contain an operation code. The operation-code bits specify the requested operation as follows:

Mode Bits				Mode
M4	M3	M2	M1
0	0	0	0	None
0	0	0	1	Read words from memory. (See below.)
0	0	1	0	Set marginal early. The software should use PRO60 to enable the "marginal early" memory-accessing mode.
0	0	1	1	Set computer malfunction on. The software should use PRO34 to turn the MALF light on. (It's unclear how the MALF light gets turned off. Probably the astronaut is supposed to do it manually by pressing the RESET button on the PCDP.)
0	1	0	0	Set marginal late. The software should use PRO60 to disable the "marginal early" memory-accessing mode.
0	1	0	1	Set pitch ladder output. (See below.)
0	1	1	0	Set yaw ladder output. (See below.)
0	1	1	1	Set roll ladder output. (See below.)
1	0	0	0	Set all ladder outputs. (See below.)

As you can see, one of these commands causes a memory word to be read and reported back through the interface, while the others are supposed to trigger the OBC software to perform some operation.

When data is being read back (operation 0001), the data word read from the AGE link is interpreted as follows: M5-M12 will contain a data address (A1-A8), M13 (A9) will contain a bit related to AGE internal clock pulse timing, M14-M17 will identify the sector (S1-S4) of the requested data, and S5 will identify the syllable of the requested data. (By selecting S5=0, the data is taken from syllables 0,1. By selecting S5=1, the data is taken from syllable 2 with an implied but fictitious syllable 3 that is entirely 0.) The first bit transmitted is the most-significant bit of higher selected syllable and the last bit transmitted is the least-significant bit of lower selected syllable. The actual transmission technique is to repeat the following 26 times, in most-significant to least-significant bit order:

1. Load the accumulator so that the bit to be sent is the sign bit.
2. PRO22 to output the bit.
3. Wait 2.5 ms.
4. PRO23 with accumulator negative. (Start AGE data clock pulse.)
5. Wait 2 ms.
6. PRO23 with accumulator positive or zero. (End clock pulse.)
7. Wait 2 ms.
8. PRO22 with acculator positive or zero. (Put AGE datalink line back to its normal resting state.)
9. Wait 1 ms.

(The manual states that specifically that "there is a delay of 4.5 ms. between resetting clock 18 and setting clock 19". I cannot fathom any meaning in this statement, so I simply report it as written.)

As far as the "Set XXX ladder outputs" operations are concerned (0101, 0110, 0111, and 1000), the data word read from the AGE is interpreted as a sign bit at M18 and a 6-bit data word (D1-D6) at M12-M17. What is done with this data is TBD.

Time Reference System (TRS)

The Time Reference System (TRS) keeps track of elapsed time from lift-off, and provides count-down times to retrograde and to equipment reset. It counts in 1/8-second increments. The timings being tracked can be transferred to the OBC or set from the OBC, and they can be set by other means such as manual entry and digital uplink from the ground.

The TRS can be accessed by the OBC in one of two modes: "readout mode", which is activated by PRO21 with the accumulator negative, and "enter mode", which is activated by PRO21 with the accumulator positive or zero. In readout mode, the elapsed time (ET), the time until retrograde (T_R) or the time until equipment reset (T_X) is transferred from the OBC to the TRS. In enter mode, the transfer is instead from the TRS to the OBC. If T_R reaches zero, then a discrete from the TRS which can be read with CLD05 becomes active, and the software is generally expected to poll this discrete so that it can know when to begin retrograde.

The TRS has three internal 24-bit counter-buffers in which times are counting upward or downward, and a separate 24-bit buffer used to transfer data to/from the OBC.

In order to make sense of the procedures documented in the familiarization manual, the PRO21 instruction must have some unusual behavior, such as the following:

• It places the accumulator's M25 bit onto the output line to the TRS.
• It places the signal from the input line from the TRS into the accumulator's M1 bit.
• It generates a clock pulse for the TRS.
  

Readout Mode

Here's how the OBC can write data to the TRS.

1. PRO21 with accumulator negative to select readout mode.
2. Load the accumulator with 24-bit data for the TRS. The data should be in accumulator bits M2-M25.
3. Repeat the following 24 times:
1. PRO20 to output accumulator's M1 to the TRS.
2. SHR1 to discard M1 from the accumulator and move the other accumulator bits downward.
4. With the accumulator negative use (only) one of PRO14, PRO65, or PRO25 to strobe the TRS transfer buffer into one its ET, T_R, or T_X counter, respectively.
5. Delay 9-15 ms.
6. Use the same PRO instruction from step 4, but with the accumulator zero or positive.
   

Enter Mode

Here's how the OBC can read data from the TRS.

1. PRO21 with accumulator zero or positive to select enter mode.
2. With the accumulator negative use (only) one of PRO14, PRO65, or PRO25 to load the TRS ET, T_R, or T_X counter value, respectively, into its transfer buffer.
3. Delay 9-15 ms.
4. Use the same PRO instruction from step 2, but with the accumulator positive or zero.
   
5. 25 repetitions of the following steps. (Yes, that's 25 repetitions, even though only 24 bits are involved.)
   
1. PRO20 to get the next bit from the TRS into the accumulator's M1 bit.
   
2. SHR1 to logically right-shift the accumulator by one place.
   
6. Notice that after the 25th step above, the first bit that was read will have been shifted out of the accumulator entirely, so only the bits from the 2nd through 25th reads will remain.
   

Auxiliary Tape Memory (ATM)

At some point in the evolution of the operational program, feature creep caused the size of the operational program to overrun the total amount of memory provided by the ferrite array. For Gemini VIII through XII, the approach taken was to modularize the software in a way that allowed it to be reloaded into the OBC during the mission with software that was specialized for the current phase of the mission. So even though we talk (for example) about the "software for Gemini X", the software for Gemini X was really several different programs that were loaded just during the mission phases in which they were used. The programs were stored in the Auxiliary Tape Memory (ATM) and then transferred to the OBC. The actual capacity of the tape was "over 85,000 thirteen-bit words", which is about 7 times the capacity of the ferrite array. I don't know exactly how long it took to load programs from the ATM into the OBC, but the total tape could be read in 67 minutes, so the maximum amount of time a program load could have taken would be about 10 minutes. Since not all of the memory could be overwritten, and since syllable 2 of the 39-bit memory words couldn't be changed in flight anyway, the actual loads would have taken less time, and is estimated at about 7 minutes.

Since the newly-loaded software could only be placed in syllables 0 and 1 of the memory words, any newly-loaded software would have to be written in a manner uses memory and CPU time very inefficiently, such as:


In other words, only one syllable per memory word would actually contain an instruction that did anything useful (wasting 2/3 of the memory), and only half of the instructions would be otherwise-unneeded jump instructions (wasting 1/2 of the CPU time). However, subroutines that needed to be time-efficient could be in Module I (see below) and wouldn't have to be loaded in flight anyway.

Loading software from the ATM into the OBC is actually a software operation rather than a hardware-only operation, so it requires that some software—namely, the software that does the software loading—remain always in the OBC without being overwritten. That invariant portion of the software is known as "Module I". There were six modules in all, and the actually-loaded software at any given time contained some combination of these modules.

• Module I (always present): Executor, Pre-launch mode, diagnostics, and ATM read programs. (Refer to the software-evolution section earlier to understand some of these terms better.)
• Module II: Ascent mode, Catch-up mode w/o radar, and the portion of Re-entry mode suitable for an abort during ascent.
• Module III: Catch-up mode and Rendezvous mode.
• Module IV: Touchdown-predict mode and Re-entry mode.
• Module V: Ascent mode w/o abort capability, Catch-up mode, and Rendezvous mode w/o rendezvous self-test. This module is a slimmed-down version of modules II and III which is present as a precaution against failure of the ATM itself.
• Module VI: Orbit-predict, Orbit-navigation, and Orbit-determination modes.

I can't tell you (yet) how many separate software loads occurred during the missions, nor which modules were loaded during these loads, but that is probably information we can find or deduce at some point in the future. I believe, however, that loads occurred during the pre-launch phase after diagnostics had been completed, in orbit prior to rendezvous, and after rendezvous but prior to re-entry.

The documentation does not precisely describe how data is read from the ATM. But the following is my best guess as to how the actual OBC/ATM inteface works.

Various of the PRO/CLD instructions mentioned below are repurposed from interfacing to other peripherals like the TRS. The image at right, showing the pilot controls for the ATM, came from the Gemini XII Mission Report. (I was obliged to replace all of the text to make it legible for presentation here.) In the AUTO mode, it appears as though data could be written to the tape using the Aerospace Ground Equipment (AGE), but only the STDBY, REWIND, WIND, and PROG modes seem to have been useful during the mission.

• The position of the ATM mode switch can be read by combining the two bits from CLD14 and CLD15. I assume that being in STDY or not is what affects the repurposing of the PRO/CLD instructions I mentioned earlier and that the remaining 4 positions are what is reported as the mode. I don't know what numerical codes are associated with which modes.
  
• The ATM is commanded by the computer to wind (fast forward), rewind, or to stop winding/rewinding with the PRO15, PRO25, or PRO14 instructions, respectively, on the basis of the positioning of the ATM mode switch. Wind and rewind occur at about 12 inches per second, whereas reading or writing occurs at 1.5 inches per second.
  
• The ATM is commanded to verify/reprogram (i.e., to output actual data or, I assume, to pause playback) with the PRO44 instruction.
• CLD33 is used to determine that the ATM has reached the proper speed for reading (or writing) data from (to) it, and become active roughly 5 seconds after the tape drive has been set in motion.
  
• When the ATM is outputting data, the data is provided in 3-bit frames at a rate of 200 frames per second.
• A new 3-bit data frame is ready to be used when CLD41 becomes active.
• The 3-bit frame's data is retrieved using the commands CLD44, CLD43, and CLD35 to get the individual bits-positions of the frame.
• The end or beginning of the tape is detected with CLD34.

The ERROR lamp seems to have been directly controlled from the ATM rather than from the OBC. The 3-bit data frames mentioned above were actually 4 bits each, with the 4th bit being a parity bit, so the ERROR lamp was lit when a parity error was detected. Moreover, the data was triply redundant as well, so a voter circuit could detect an error if there was a mismatch between the redundant data. Finally, the data checks occur even during wind/rewind operations, so the ERROR light can potentially be lit during those activities. On a similar note, it may have been possible to read data from the ATM during a tape wind/rewind operation, but I have no data on that subject. I believe that a PRO14 will extinguish the lamp if it is lit.

The RUN lamp is also controlled directly by the ATM, and indicates that the tape is in motion; it lights 5 seconds after receiving any command that sets the tape in motion. It will be automatically extenguished if the beginning or end of the tape is reached.

During an ATM search operation, the IVI was used to show the tape position (in 13-bit words) on the left/right display, and the module words on the fore/aft display.

As far as how the data is actually encoded on the tape—i.e., how the 3-bit frames are recombined into 39-bit memory words, and where those words are placed in memory—I have, as of yet, found no clue in the documentation.

OBC Assembly Language

I've not yet found any samples whatever (flight software or otherwise) of actual OBC assembly language, so it's unclear what the syntax is, what the pseudo-ops are, etc. But I'm still looking. In the absence of any such samples, we necessarily define our own syntax, based on observations of usages in the Project Gemini Familiarization Manual and of pseudo-LVDC code produced by MIT Instrumentation Labs personnel.

General format

The symbol '#' is used to begin a comment. All text from '#' to the end of a line is discarded before parsing the remainder of the line, but is still shown in assembly listings.

A double-pound ("##") is still a comment, but is treated specially by the assembler in that it produces a visually special annotation in output HTML assembly listings (if any) and is omitted from the normal textual assembly listing. The intention is that '#' is used to mark a comment from the original source code, while "##" is used to mark modern commentary on that source code. Double-pounds produce this special effect only if aligned at column 1, and are otherwise treated identically to '#'.

Other than blank lines or comments which fill an entire line, the format of an individual line of code is


where

• LABEL is an optional symbolic name for the current memory pointer. If present, LABEL must be aligned at column 1. Labels are limited to 8 characters or less, and may contain any character which is not white-space.
  
• OP is either an opcode or else a pseudo-op. By convention, the OP column is aligned at the 2nd tab stop (where tab stops are 8-columns wide), but this convention is for aesthetic purposes only. The assembler requires merely that the OP not begin at column 1, in order to prevent it from being confused with a label.
• Some shorthand instructions or pseudo-ops don't require operands. By convention, if present the OPERAND is aligned at the next tab stop after OP, however, the assembler requires merely that they be separated by whitespace. The nature of the operand differs, depending on whether the OP acts on a constant (such as PRO or CLD) or on an address (such as STO or CLA):
• In all cases except the DEC pseudo-op, OPs which require constants for operands need octal constants. These are simply collections of octal digits.
• For OPs whose OPERAND is an address, any of the following forms is allowed:

• The comment field, by convention, is aligned two tab stops after the start of the OPERAND field. Again, this is not a requirement of the assembler, but simply makes all the comments line up nicely.
  

'*' is a special case of a program label which always refers to the current location. Interpretation of the optional OctalConstant is not as straightforward as it seems, because there is some contextual dependence:

• When the address being referenced is an instruction in a context in which an instruction address is needed (such as "TRA * + 2"), OctalConstant is a count of instructions—i.e., of syllables.
  
• However, when the address being referenced is data in a context in which data is needed (such as "STO MYVAR + 1"), OctalConstant is a count of memory words.
• Finally, there is the case in which the address referenced is an instruction where data would be needed, or vice-versa. This case is rejected by the assembler as an error, although there are actually some unusual cases where it could be sensible.
  

Shorthands for some instructions

Shorthand	Description
SHR1	Same as an SHF with X=1, Y=2. The existence of this shorthand and its translation is deduced from the text of the Project Gemini Familiarization Manual.
SHR2	Same as an SHF with X=0, Y=2. The existence of this shorthand and its translation is deduced from the text of the Project Gemini Familiarization Manual.
SHL1	Same as an SHF with Y=3. The value of X doesn't matter in this case, but our assembler will use X=0. The existence of this shorthand and its translation is deduced from the text of the Project Gemini Familiarization Manual.
SHL2	Same as an SHF with Y=4. The value of X doesn't matter in this case, but our assembler will use X=0. The existence of this shorthand and its translation is deduced from the text of the Project Gemini Familiarization Manual.
PROYX	Same as a PRO with X=X and Y=Y. The existence of this shorthand and its translation is deduced from the text of the Project Gemini Familiarization Manual. It is TBD with this shorthand how to select whether the important A9 operand bit is 0 or 1. Possibly it is always 0 and you need to use the full PRO form of the instruction when A9=1.
CLDYX	Same as a CLD with X=X and Y=Y. The existence of this shorthand and its translation is deduced from the text of the Project Gemini Familiarization Manual.
NOOP	A no-operation instruciton that simply advances to the next instruction in sequence. The assembler translates this to "TRA * + 1". The existence of NOOP, though not this specific translation of it, is deduced from LVDC code snippets created by Instrumentation Labs personnel.

Pseudo-ops

Pseudo-op	Description	Example
HOPCON	Assembles a HOP constant into the current memory location. Its operand is the address of another memory location. The existence of this pseudo-op is deduced from LVDC code snippets created by Instrumentation Labs personnel.	# A SUBROUTINE LINKAGE. CLA * + 2 TRA ASUBROU HOPCON * + 1 RETHERE ... return here ... ... # A SUBROUTINE ASUBROU STO RETADDR ... do stuff ... HOP RETADDR RETADDR VAR
DEC	Assembles a decimal constant into memory. It can assemble either integer values or else fractional values with absolute values less than 1, and it determines the method used on the basis of whether or not a decimal point is present. There is no method provided for encoding a constant having both an integer and a fractional part. Its operand is a set of decimal digits, optionally preceded by '+' or '-', optional leading zeroes, and an optional '.'. The allowed range of values is -33554432 to +33554431 for integers. Note that the data will be aligned with the next syllable 0 in sequence. The existence of this pseudo-op is deduced from LVDC code snippets created by Instrumentation Labs personnel.	ANINT DEC -12345678 AFRACT DEC -.52 AFRACT2 DEC +0.987654321
OCT	Assembles an octal constant into memory. Its operand is a set of octal digits. The allowed range of values is 0 to 377777777. Note that the data will be aligned with the next syllable 0 in sequence. The existence of this pseudo-op is deduced from LVDC code snippets created by Instrumentation Labs personnel.	ANOCT OCT 1234567
ORG	Moves the assembler's current address to a different location within the current memory sector and current memory module. Its operand is a set of octal digits forming a constant in the range 0-377. I assume from personal experience that a pseudo-op like this must exist, but there is no hint of it in any existing documentation.	ORG 0
SECT	Changes the assembler's current memory sector within the current memory module, and changes the assembler's current syllable pointer to the next unused syllable in that memory sector. Its operand is a set of octal digits forming a constant in the range 0-17. Alternately, the operand may be the label of a memory location. In this case, what happens is that the assembler's current memory sector and memory module are changed to that of the labeled memory location, and the assembler's current syllable pointer is moved to the next unused location in that memory sector. I assume from personal experience that a pseudo-op like this must exist, but there is no hint of it in any existing documentation.	# WRITING CODE IN SECTOR 4 SECT 4 ... ASUB ... code for ASUB ... # WANT TO DEFINE A VARIABLE # USED BY THE ASUB ROUTINE # IN THE RESIDUAL SECTOR, # BUT THEN TO CONTINUE CODING # WHERE WE LEFT OFF. SECT 17 AVAR VAR # COULD ACTUALLY SAY "SECT 4" # HERE, BUT SAYING # "SECT ASUB" INSTEAD MAKES # IT EASIER TO MOVE THE CODE # AROUND IF (SAY) SECTOR 4 # FILLS UP. SECT ASUB ... more code ...
MODULE	Changes the assembler's current memory module, and changes the assembler's current sector and current syllable pointer to the lowest unused syllable in that module. Its operand is a set of octal digits forming a constant in the range 0-7 for LVDC, or simply 0 for the Gemini OBC. I assume from personal experience that a pseudo-op like this must exist, but there is no hint of it in any existing documentation.	MODULE 0 SECT 5
VAR	Allocates a word or several words for storage of variables. The operand is a set of octal digits forming a constant that gives the number of words allocated. If the operand is missing, it is assumed to be 1. I assume from personal experience that a pseudo-op like this must exist, but there is no hint of it in any existing documentation.	# ALLOCATE A 21-WORD BUFFER # FOR DOWNLINKING DIGITAL # DATA. INSTDAT VAR 25 # ALSO, SEE THE HOPCON AND # SECT EXAMPLES ABOVE.

Virtual AGC simulation software

In the foregoing sections I've talked about the characteristics of the Gemini OBC itself. In this section I discuss simulation software provided by the Virtual AGC project to simulate the OBC & friends. Little of the software I'll describe actually exists as of yet, so much of these sections is a speculation about software that I might create. But some significant simulation code from the original Gemini developers does exist and is covered as well.

The Gemini Catch-Up and Rendezvous Simulation Program

Background

This is an actual existing program described in this report, with the full FORTRAN source code in Appendix A of the report. The program was used by the original Gemini developers to verify algorithms for the catch-up and rendezvous flight phases. It is a behavioral simulation of the flight code, rather than being flight code itself. The actual flight code was apparently developed by handing the validated FORTRAN source code to programmers, who recoded it to something usable directly in the Gemini OBC. It is therefore the closest thing we have at the present time to actual flight code. The report was contributed by Gemini developer Eugene Mertz, and scanned by his son Dave. Thanks, Gene and Dave!

Although the report is dated slightly after the Gemini 7/6 mission, Gene recollects that it was actually prepared a few weeks before the mission, which was the first rendezvous maneuver of manned spacecraft. In other words, it's reasonable to suppose that the FORTRAN code corresponds to the Gemini 7/6 mission.

Gene comments, "The FORTRAN code seems to be complete since it had to simulate the flight code. The coding style is archaic, to say the least. Today’s techniques (and newer languages) would produce better code! But, hey, the system worked to perfection despite problems that cropped up in equipment other than the computer (example: the plug falling out at 2 inches off the pad!). I believe the version was FORTRAN IV since this was the language of choice at the time for the IBM 7094. I recall one problem that we had running the binary deck after it sat dormant for several months. The problem arose because one of the FORTRAN programmers used an “undocumented instruction” that IBM decided to change to make it better. I put one chad in the offending hole and duplicated the deck. The chad stayed in long enough to read the “fix” into memory. After that… no problem! (Also, no voting machine was involved.)"

Two separate application programs are actually provided, though using much of the same underlying machinery. Both a batch-oriented program (capable of receiving a bunch of input data and quickly generating corresponding output data for the mission) and a dynamic simulation program that operates in real-time are provided.

Source Code

The source code for Report #4 described above has been extracted from the report and is available in the Virtual AGC software source tree under the directory yaAGC/GeminiCatchUpandRendezvousProgram/.

The original program was really combined FORTRAN II and IBM 7090/7094 assembly-language. Both the original FORTRAN II and the assembly code did things which simply cannot be performed with any modern version of FORTRAN, so the original source wouldn't have been directly compilable and (if somehow it compiled) the executable would not have worked as expected on any computer other than an IBM 7090/7094. The theory of operation section explains some of the problems involved. Therefore, the source code in the Virtual AGC source tree has necessarily been modified from the original to be buildable and portable.

In general, the following modifications have been made:

• Every effort has been made to keep the FORTRAN source identical to the original, in files with names of the form *.f. The very minimal differences from the original which could not be avoided are clearly marked, and would have compiled and worked properly with the original compiler.
• The IBM 7090/7094 assembly-language is provided (in files named *.s) but does not participate in the build. Instead, complete replacements are provided (in files named *.c).

Building the Catch-Up and Rendezvous Simulation Program

In a general Virtual AGC program build, the catch-up and rendezvous simulation program is built automatically. But if you just want to build the Gemini simulation and none of the rest of Virtual AGC, you can do this:


This requires:

• GNU make
• GNU gcc
• GNU gfortran
• GNU sed
  

Although the Makefile has provisions for using the earlier GNU g77 in place of gfortran, but it's best not to use it because I've found that with g77 the program will appear to compile but the executable will not be fully functional. If you adapt for other compilers, let me know the details. Note: At build-time, the Makefile dynamically transforms the FORTRAN II to a more-modern FORTRAN dialect (*.f → *.for), since the FORTRAN II code cannot be directly compiled with a modern compiler. This transformation behavior must therefore also be mimicked if changing to a different toolset.

Running the Catch-Up and Rendezvous Simulation Program

The batch-oriented simulation program, referred to in Report #4 as the "static environment", is created as the executable named BENCH7. The dynamic simulation program, referred to in Report #4 as the "dynamic environment", is created as MAIN7. Neither has any command-line arguments, but both expect input files to be available. (The nature of the input files and output files is discussed in the next section.)

• BENCH7: Receives input on file-descriptors 5 and 6, and outputs on file-descriptor 9. Therefore, in a UNIX-type runtime environment, it would be reasonable to run the program with the command "BENCH7 5<Infile1 6<Infile2 9>Outfile".
  
• MAIN7: Receives input on file-descriptor 5, and outputs on file-descriptors 9 and 14. Therefore, in a UNIX-type runtime environment, it would be reasonable to run the program with the command "BENCH7 5<Infile 9>Outfile1 14>Outfile2".

Both programs may also print some status messages on stderr, due to my alterations rather than to any intention of the original programmers.

Data for the Catch-Up and Rendezvous Simulation Program

The input-data files needed to run the simulation program(s) are described in Report #4. Actually generating such data is TBD.

Gene's comments: "The problem is that there is no 'environment' FORTRAN program to generate the radar inputs to the OBC (range, azimuth, and elevation to the target), the platform inputs to the OBC (gimbal angles and accelerations), horizon sensor angles, and astronaut inputs (thrusting, switch position selections, etc.) required for a complete simulation of rendezvous flights. Without that, the executable just loops through the equations and logic waiting for dynamic inputs to arrive. As I recall, the 'environment' simply had the target moving in a constant, 'circular' orbit around an oblate Earth whose gravitational field was defined by a six-term series potential function. Time (one second increments) was common to both the 'environment' and the OBC FORTRAN programs. I believe the astronaut switch inputs were originally simulated using the 7090 (or 7094) console keys. Today, mouse clicks would do the trick. Thrusting and attitude were closed-loop from the OBC results using rates approximating the actual spacecraft capability. The 'environment' development is being left to the student at this time. Data were communicated between FORTRAN programs through judicious use of COMMON arrays."

Theory of Operation and Porting-Problems for the Catch-Up and Rendezvous Simulation Program

As mentioned above, the original source code from Report #4 is incompatible with modern FORTRAN—or indeed, any modern high-level computer language—in various fundamental ways. Therefore, significant code alterations had to be made to produce a portable, working program; yet, every attempt was made to preserve the original source in as much detail as possible, and to preserve its "look and feel" otherwise. Those problems and fixes are described in this section, along with some theory of operation of the original code in order to understand the nature of the problems.

TBD

yaOBC, the OBC CPU Emulation

yaOBC, if it existed, would be a software simulation of the OBC. At present, I don't know if I'll actually create OBC emulator software or not. But if I do, at least this will be a section this web-page for it!

yaASM, the OBC Cross-Assembler

yaASM is in the planning stages, but does not yet exist. yaASM will be an assembler for Gemini OBC and LVDC assembly language files, outputting a binary executable suitable for being used with yaOBC or yaLVDC simulation software. The assembly languages are as defined above or on the LVDC page. Of course, the reason this combined approach is used is because of the great similarities between the two computers and their instruction sets.

By convention, but not by any requirement of the assembler, Gemini OBC and LVCD source-code files have the filename extensions .obc and .lvdc, respectively. This convention arises from the existence (or potential existence) of CPU-specific syntax highlighters when viewing such source code. The assembler does not care what the filename extension are.

The command-line syntax for yaASM closely follows that of other Virtual AGC assemblers, such as yaYUL and yaLEMAP:


The only presently-defined options are:

--lvdc

--compare=Filename

--html

yaASM always outputs its binary in a file called yaASM.bin). Similarly, the assembly listing file is always output to the file yaASM.lst.

The formats of the binary output files differ for Gemini OBC vs. LVDC, only in that the number of syllables per word and the total number of memory modules differ, causing the lengths of the files to differ. The Gemini OBC has 3 syllables per memory word, whereas the LVDC has 2 syllables per memory word. Moreover, the LVDC has up to 8 memory modules, whereas the Gemini OBC has only 1 (so that the concept of a "memory module" isn't even discussed elsewhere on this page). LVDC syllables are theoretically 14 bits rather than 13 bits, but the extra bit is a parity bit that is accessible only in hardware, and therefore is not supported. Otherwise, the file formats are the same:

• The binary file consists of a sequence of 16-bit little-endian words.
• Each output word holds a 13-bit syllable, aligned at the least-significant bit of the 16-bit word.
• The output words are ordered so that the first word is for syllable 0 of address 0 of sector 0 of module 0.
• Successive output words increment first the syllable (0,1,2 for OBC and 0,1 for LVDC), then the address (0 to 255), then the sector (0 to 15), then the module number (0 only for OBC and 0 to 7 for LVDC).
  

yaPanel, the Control Panel Emulation

Unlike the Apollo spacecraft (plural), the Gemini spacecraft had a simple enough control panel that it makes sense to simulate the complete control panel on a single computer screen. Of course, since we won't simulate all of the Gemini peripherals, many of the controls and readouts won't be functional. Recall that the MDIU comprises the MDR readout unit and the MDK keypad unit, as seen in the photo at right, to provide a simple display and keypad interface to the OBC.

yaPanel software would provide a simulated MDIU interface to the yaOBC simulated-OBC software ... if yaPanel existed. Right now, it's merely a fairly-distant gleam in my eye.

Operation of the OBC via the MDIU follows a simple set of conventions, as follows:

• Command/data entry into the computer is performed by entering a 7-digit string of numbers.
• The first two digits are an "address" (01-99), and the final five digits are a "message" (octal or decimal, depending on context). Note that the MDR has a 7-digit readout, which is parsed into a 2-digit field followed by a 5-digit field.
• The digit '9' serves a dual purpose, in that if it is the leading digit of the 5-digit message field it is treated as a minus-sign.
• If the astronaut makes a data-entry error in using the MDIU (see the procedures listed just below), the MDR display shows all 0 to indicate that an error occurred.
• When entering digits, pressing the CLEAR key on the MDR will erase all of the digits so that entry can be restarted.
• When entering digits, it's necessary to wait until a digit is displayed before entering the next digit.
  

Control of the OBC via the MDIU is very similar to control of the Apollo AGS via its DEDA. Here are the operations which can be performed by the astronaut using the MDIU:

• The astronaut can control the OBC by inserting data into OBC memory addresses using the MDK and MDR. The procedure for doing so is as follows:
1. Press the CLEAR button on the MDR.
   
2. Enter 7 digits using the numerical keypad on the MDK. The first two digits are the address, and the last five digits are the data.
   
3. Press the ENTER button on the MDR to actually perform the operation.
• The astronaut can verify data previously stored in the OBC as follows:
1. Press the CLEAR button on the MDR.
   
2. Enter just the 2 address digits on the MDK.
3. Press the READ OUT button on the MDR.
4. The requested data will be displayed and updated at half-second intervals.

The relationship of the "addresses" 1-99 to actual physical memory addresses is TBD. (There is no reason logically why they can't map to any 99 memory locations. However, for efficiency of coding, it's reasonable to suppose that they were actually contiguous. It's also reasonable to suppose that they resided in the residual sector, so that they could be immediately accessed by code in any memory sector.)

As another example, yaPanel would provide a simulated Pilots' Control and Display Panel (PCDP). The additional controls provided by the PCDP are:

• The COMPUTER mode selector—selects between the different sub-programs the computer can run, such as "pre-launch", "ascent", and so on.
  
• The START switch—tells the computer to actually begin executing the computation selected by the COMPUTER selector.
• The COMP light—lit while the computation is in progress.
• The MALF light—to indicate a malfunction.
• The RESET switch—to reset the computer after a malfunction.
• The ON-OFF switch.
  

Then too, consider the Incremental Velocity Indicator (IVI) from the command-pilot's control panel, as depicted at right. The IVI has a set of three 3-digital displays that show the current velocity of the spacecraft relative to a previously-set zero reference. (It can also be used to show data related to the Auxiliary Tape Memory, if any.) The OBC sends pulses to the IVI that increment or decrement the displays whenever the velocity changes.

1. Forward-direction indication lamp. When lit, indicates that the delta-V value shown on the forward-aft display device (2) is in the forward direction.
   
2. Forward-aft display device. Displays the magnitude of the forward or aft delta-V from the previously-set zero point, in ft./sec.
3. Left-direction indication lamp. When lit, indicates that the delta-V value shown on the left-right display device (4) is in the left direction.
4. Left-right display device. Displays the magnitude of the leftward or rightward delta-V from the previously-set zero point, in ft./sec.
   
5. Right-direction indication lamp. When lit, indicates that the delta-V value shown on the left-right display device (4) is in the right direction.
6. Up-down display device. Displays the magnitude of the upward or downward delta-V from the previously-set zero point, in ft./sec.
7. Up-direction indication lamp. When lit, indicates that the delta-V value shown on the up-down display device (6) is in the up direction.
8. Down-direction indication lamp. When lit, indicates that the delta-V value shown on the up-down display device (6) is in the down direction.
9. Down-up rotary switch. Can be used to manually zero or otherwise adjust the up-down display device (6). Spring-loaded to return to the neutral position.
   
10. Left-right rotary switch. Can be used to manually zero or otherwise adjust the left-right display device (4). Spring-loaded to return to the neutral position.
11. Aft-forward rotary switch. Can be used to manually zero or otherwise adjust the forward-aft display device (2). Spring-loaded to return to the neutral position.
12. Aft-direction indication lamp. When lit, indicates that the delta-V value shown on the forward-aft display device (2) is in the aft direction.

yaPanel also provides some simulated control-panel indicators related to the Time Reference System (TRS), which relate to passage of real time rather than being controlled by the OBC. These displays include three separate clocks and a stop-watch function. We don't provide a simulated TRS as such, but yaPanel is obviously aware of the passage of real time, and consequently it can provide these simulations itself. The operation of these simulated devices should be pretty self-explanatory.

Communications protocol

As with the Apollo simulation software provided by the Virtual AGC project, the principal method I've elected to use for interconnecting a simulated CPU (in this case, yaOBC) to its simulated peripherals (yaPanel) and simulated ground telemetry stations (yaTelemetry) is a system of "virtual wires" implemented with TCP sockets. In a system like this, yaOBC broadcasts a TCP message to all connected client programs like yaPanel whenever data is output via a PRO instruction. Conversely, connected client programs send TCP messages to yaOBC whenever the state of some peripheral changes; yaOBC buffers these changes in memory, so that it can deliver them on demand to the flight software whenever a CLD or input PRO instruction is encountered. The pre-existing Apollo TCP protocol described on our developer page is inadequate for Gemini, because that protocol has only 24 message bits per packet, whereas in Gemini we need at least 33 bits (1 bit for CLD vs. PRO, 3 bits for X, 3 bits for Y, and 26 bits for data), so we provide a completely new protocol, but which is compatible in the sense that messages in the Apollo protocol cannot be confused with messages in the Gemini protocol, and therefore can be intermixed on the same socket if desired. It also has the desirable property that one can unambiguously detect a byte which starts a packet from bytes which are interior to packets.

Each packet, transmitted in either direction, shall consist of 4 bytes or 8 bytes, as follows:


This is more bytes than presently needed (5 would be adequate for a minimal protocol), but current parsers in programs like yaTelemetry use multiples of 4 bytes, so I think this is a reasonable compromise, as well as making it easier to extend in the future. In this notation,

• "x" is a presently-unused bit that may be used in future extensions of the protocol, and is always filled with a value of 0.
• "LLL" indicates the packet length: the packet is 4*(1+LLL) bytes long, so LLL is 000 for 4-byte packets and 001 for 8-byte packets.
  
• "TTT" is a "packet type" field, as follows:
• 000 is either the output or input data for a Gemini PRO instruction.
• 001 is the input data for a Gemini CLD instruction.
• Other values are presently unused, but I would anticipate that they could be used for LVDC, Skylab, or other presently unimplemented simulation types.
• "XXX" and "YYY" are the X and Y operands of the appropriate PRO and CLD instructions.
• "D" or "D...D" are data, with the leftmost bit as depicted being the most-significant and the rightmost being the least-significant.