Home
AGS
LVDC
Gemini
Download
Document library
Change log
Bug and issues
Developer info
Virtual AGC — AGS — LVDC — Gemini

Gemini Spacecraft
On-Board Computer (OBC)
FAQ
yaAGC
yaYUL
yaDSKY
yaOtherStuff
Luminary
Colossus
Language Manual
Physical Implementations
Gemini Patch

Please enable javascript in your browser to see a site-search form here.

Contents

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.


The Gemini VIII OBC, with cover removed
(Smithsonian National Air & Space Museum)

Location of the OBC in the spacecraft

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).


Modular Display Keyboard (MDK)
Modular Display Readout

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.



A basic inventory of the guidance sub-systems includes:
The diagram below shows a very simplified block diagram of the guidance system, but if you click it you'll get a (different) more-detailed block diagram.



The IMU is the usual gimballed stable platform with accelerometers and angular resolvers as in Apollo, except for a key difference that the Gemini IMU had four gimbals rather than the three gimbals of Apollo.  This means that it was not subject to the phenomenon of "gimbal lock", and hence the software used to adjust spacecraft alignment could be simpler than with three gimbals.  The value of the 4th gimbal can be appreciated when considering incidents like the mishap in Gemini VIII in which an uncontrolled roll occurred.  (If the IMU had had only three gimbals, my understanding is that gimbal lock would have occured when the roll angle was too great.)  On the other hand, at that point the spacecraft was under manual control anyway, and I'm sure that the notion that the IMU would have to be realigned later would have been the least of Neil Armstrong and Dave Scott's worries.

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:
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:

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.

Bit position:
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
Syllable:
 Syllable 2
 Syllable 1
 Syllable 0

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):

Bit position:
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
Bit code:
 A1
 A2
 A3
 A4
 A5
 A6
 A7
 A8
 A9
 OP1
 OP2
 OP3
 OP4

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.

Bit position:
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
Data word:
 M25
 M24
 M23
 M22
 M21
 M20
 M19
 M18
 M17
 M16
 M15
 M14
 M13
 M12
 M11
 M10
 M9
 M8
 M7
 M6
 M5
 M4
 M3
 M2
 M1
 S

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:

Bit position:
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
Data word:
 A1
 A2
 A3
 A4
 A5
 A6
 A7
 A8
 A9
 S1
 S2
 S3
 S4
 -
 SYA
 SYB
 -
 S5
 -
 -
 -
 -
 -
 -
 -
 -

In this scheme:
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:

         # Prepare to call MYSUB.  The idea is that the HOPCON pseudo-op
         # makes a memory constant with a suitable return address.  This
         # is loaded into the accumulator before making the subroutine call.
         CLA     * + 2     # LOAD RETURN ADDRESS INTO ACCUMULATOR
         TRA     MYSUB     # JUMP TO MYSUB
         HOPCON  * + 1     # A MEMORY CONSTANT WITH THE RETURN ADDRESS
         ... return from MYSUB is to here ...

         ...

         # THE SUBROUTINE ITSELF.
MYSUB    STO     MYSUBRET  # SAVE THE RETURN ADDRESS TO A VARIABLE
         ... do stuff ...
         HOP     MYSUBRET  # RETURN
MYSUBRET VAR     1         # ALLOCATE A 1-WORD LOCAL VARIABLE OF MYSUB

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:

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.

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:
PRO00
STO     RANGE   # 15 BITS
PRO00
STO     SINAZI  # SINE OF AZIMUTH, 10 BITS
PRO00
STO     SINELEV # SINE OF ELEVATION, 10 BITS

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 (TR) or the time until equipment reset (TX) is transferred from the OBC to the TRS.  In enter mode, the transfer is instead from the TRS to the OBC.  If TR 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:

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, TR, or TX 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, TR, or TX 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:

...
instruction
TRA * + 2
instruction
TRA * + 2
...

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.
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 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

LABEL           OP      OPERAND         # A COMMENT

where
Label
Label + OctalConstant
Label - OctalConstant
*
* + OctalConstant
* - OctalConstant

'*' 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:

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:

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:

cd yaAGC/GeminiCatchUpandRendezvousProgram
make

This requires:
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.)
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:

yaASM [OPTIONS] SourceFilename

The only presently-defined options are:

--lvdc
This switch causes assembly to occur for the LVDC computer.  The default, when the switch is missing, is to assemble for the Gemini OBC.

--compare=Filename
This switch causes the assembler to load the binary file called Filename, and to compare the binary output produced by assembly of the source code to the contents of Filename.  This is type of comparison is useful principally for regression testing of the assembler itself.  This switch causes a change in yaASM's return codes, which are normally based on the presence of errors and warnings.  (In other words, a non-zero return code normally occurs in case there are errors during assembly.)  With the "--compare" switch, though, yaASM has a return code of zero when the binaries match, and a non-zero return code when they don't match.  Naturally, one could use operating-system utilities (such as fc in Win32 or diff in Linux) to mimic this functionality as well; however, the "--compare" switch also has the property of adding meaningful messages about any mismatches to the assembly listing, which the operating-system utilities do not.

--html
Causes creation of an HTML version of the assembly listing.  The HTML output file is named yaASM.html.  The HTML is syntax-highlighted, so that it is easy to distinguish opcodes from line labels, etc.  Finally, the HTML contains hyperlinking from where symbols are used to where they are defined.  It is also possible to define modern annotations for the source code.
 
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:

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:
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 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:


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:

00LLLTTT 10YYYXXX 1xxDDDDD 1DDDDDDD 1DDDDDDD 1DDDDDDD 1xxxxxxx 1xxxxxxx
or
00LLLTTT 10YYYXXX 1xxDxxxx 1xxxxxxx

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,

Plea for Data

As you will have noted if you've read this far, there are some pretty serious gaps in the publicly-accessible data about the Gemini computer and its software.  If you know where to find any more information, please tell me about it.  Examples of some of the things that would be interesting to have include:
Another interesting possibility is to locate a tape from the Gemini Aux Tape Unit.  Since the Aux Tape Unit was used to load software for some mission phases in flight, it is possible such a tape could still hold actual executable OBC software.

Reminiscences and Factoids from the Original Developers

In this section, I provide distilled/edited material from personal correspondence I've had with original OBC developers.  The following are thus not direct quotes, and you should attribute errors to me rather than to my correspondents.

From Eugene Mertz:

I worked on the Gemini project at IBM in Owego, NY, and Bethesda, MD, from about 1962 through 1968, basically from the beginning to the end of the project, and was responsible for the in-orbit software applications of the onboard computer system.  The Gemini software team was organized by function (ascent, rendezvous and in-orbit navigation, and reentry).  My responsibilities encompassed the rendezvous and in-orbit, autonomous navigation functions.  Our rendezvous group consisted of five people:  two analysts, two simulation programmers, and one on-board computer programmer.  The other groups were similarly organized.

The transcendental equations of relative motion between the Gemini spacecraft and its target vehicle included a series expansion of the Earth’s gravitational field (without the South Atlantic Anomaly).  The transcendental equations were written by an IBM engineer, Connie McClure, who was a professor formerly at GW University (I believe) in Washington, DC.  He also taught orbital mechanics to the team very early in the project.  It was a tough course.  I wish I had kept all his notes.  The series expansion was verified and derived by a number of analysts at IBM, other contractors and sub-contractors, and probably NASA.  As I recall, the values of the constants were determined by tracking satellites that were already in orbit.  The constants were to change from time to time but finally settled down to those selected in the OBC.  All equations were checked and re-checked by project members several times to be sure they were accurate.  Some equations were adapted to the in-orbit Autonomous Navigation function.  Many computer hours were expended on IBM mainframes (7090/7094) simulating all mission aspects to “man-rate” the Gemini system.

Our mainframe Fortran simulator had a converter that allowed plugging in the actual Gemini flight code to replace the Fortran version in the 7094 simulation.  This, of course, was used to check the actual flight code for closed-loop timing or other problems.  A Mylar punched tape was used to load the Gemini computer memory itself (except for the programs that were stored on the Auxiliary Tape Unit) prior to launch.  I recall a situation where the tape reader was lifted up the outside of the launch tower, connected to the Gemini computer (which was already installed in the spacecraft), and a program fix loaded to correct a radar hardware problem.  This would NEVER be done today!

We started out with FORTRAN II running on the 7090, but when our computer was upgraded to the 7094, I believe we quickly switched to FORTRAN IV.  IBM was never shy when they pushed for adopting standards.  After all, if their version of the standards was adopted, they had a foot in the door.  The switch from FORTRAN II to FORTRAN IV occurred, but it could have been as early as 1963-64, in time for Gemini 7/6.  Our facility was always on the forefront of technology.  I don’t recall the exact date of the switchover.  The version used for the catch-up and rendezvous simulation program could have been FORTRAN II.  The key is whether or not there are no “machine-dependent features” included in the listing.  I can’t tell for sure.  I know we used punched cards for loading the program, a 1401/1403 for printing, and a special plotter on the “other side of the wall” to show relative trajectories.  Wow!  What power. [Ed.: There are machine-dependent features, it seems, so the program must either have been FORTRAN II or a mix of II and IV.]

The 7094 rendezvous simulator could also accept telemetry data to drive the guidance in open-loop fashion (post flight) to show what really (?) happened during the mission.  Closed-loop computer control in flight proved to be the most efficient mode (only 5% above maneuvering fuel plan). 

Here are a few tidbits which I believe are accurate:

  • I doubt that a “programming language,” per se, existed.
  • Software was written in one of the “standard” languages of the time, but I don’t know which one (Fortran, ASM, other?).
  • A translator was used to generate the flight computer code which was then punched into wide (2-inch?) Mylar tape for use in a memory loader.  But I don’t recall exactly what the translator encompassed.  Perhaps someone else will come forward with clarification.
  • A lot of coordinate system transformations were performed, especially during rendezvous.
  • Changing the flight software required a big shoehorn.  Installing a code change might have meant using 300 memory locations.  Subsequently removing the change would save only 200.
I met Wally Schirra in Washington, DC, almost 25 years to the day after the historic first rendezvous on December 16, 1965.  I recall his words, “I remember you.”  The mission was Gemini 7/6.

The photos below have nothing to do with Gemini.  They depict a Vanguard tracking station using a MiniTrack Mark II installation.  I am the middle figure, and to the left and right are L. Passage and K. Watson, respectively.  To my knowledge, they were not involved in Gemini.  The right-hand photo shows a partially completed half of the antenna, which consisted of two 8-dipole arrays spaced 500 feet apart.  It was all, including frequency converters, etc., constructed by hand by volunteers.  Yes, that is snow on the ground. The photos were taken about four years prior to the Gemini project (following the first successful launch of Vanguard 1 on March 17, 1958).  We worked together on some terrestrial projects in the 1950s.  Many of us were members of the radio club, K2ERQ, and we tracked sightings for Echo (100-foot Mylar balloon) and other satellites.  The tracking program was written in FORTRAN by unknown persons at Brown University.  We ran the program on an IBM 650 computer (drum machine, probably FORTRAN I).  I believe the club’s interest in satellite tracking and space in general announced that the company was ready, willing, and able to enter the space development.  At least, we believe so (according to club lore).
Gene and friends at Vanguard tracking station
 Partially-completed antenna for the tracking station.


Homage

Part of our purpose here is to pay homage to the original Gemini flight-software developers.  I have only a few of their names, and little information about them, so I'm not making much progress on the homage front.   So if you know any of the developers or their relatives or friends, or even just their names, please contact me. 

Here are the names and rough responsibilities we do have, in the order in which I learned of them:
I'm also informed of the Gemini area of the U.S. Space Walk of Fame, which includes an engraved list of names:
Sadly, only 3-4 of the names on the monument seem to from the IBM Gemini flight-software software-development team.

Last modified by Ronald Burkey on 2010-09-06.

Virtual AGC is hosted by ibiblio.org