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:

Attitude Control and Maneuver Electronics (ACME), which is the
sub-system that directly controls the propulsion system.

Inertial Guidance System (IGS), including the Inertial
Measurement Unit (IMU) and the OBC itself.

Horizon Sensors

Time Reference System (TRS)

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.

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.

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.

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.

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:

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

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

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

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.

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:

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.

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.

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:

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.

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.

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

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:

Poll CLD06
at intervals of 50 ms. or less to determine if data is ready.

When data is ready:

PRO01
to tell the enable the DCS to send the data.

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:

CLD07
is polled at 50 ms. or less intervals. When it becomes active
(accumulator negative), the steps below are taken.

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:

PRO63
is used to reset the radar's discrete input buffer.

PRO01
is used to tell the radar that the OBC wants data.

Wait 20 ms.

Test if data available using CLD00.

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:

Poll CLD32
until active (accumulator negative).

Fetch an 18-bit word by repeating the following 18 times:

PRO23
with accumulator negative. (Starts a pulse on the AGE data clock.)

Wait 2.5 ms.

PRO23
with accumulator positive or zero. (Ends the clock pulse.)

Wait 1.5 ms.

CLD27.
(Reads
the
data
bit.)

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:

Load the accumulator so that the bit to be sent is the sign bit.

PRO22
to output the bit.

Wait 2.5 ms.

PRO23
with accumulator negative. (Start AGE data clock pulse.)

Wait 2 ms.

PRO23
with accumulator positive or zero. (End clock pulse.)

Wait 2 ms.

PRO22
with acculator positive or zero. (Put AGE datalink line back to
its normal resting state.)

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:

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.

PRO21
with accumulator negative to select readout mode.

Load the accumulator with 24-bit data for the TRS. The data
should be in accumulator bits M2-M25.

Repeat the following 24 times:

PRO20
to output accumulator's M1 to the TRS.

SHR1
to discard M1 from the accumulator and move the other accumulator bits
downward.

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.

Delay 9-15 ms.

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.

PRO21
with accumulator zero or positive to select enter mode.

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.

Delay 9-15 ms.

Use the same PRO
instruction from step 2, but with the accumulator positive or zero.

25 repetitions of the following steps. (Yes, that's 25
repetitions, even though only 24 bits are involved.)

PRO20
to get the next bit from the TRS into the accumulator's M1 bit.

SHR1
to logically right-shift the accumulator by one place.

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 * + 2instruction
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.

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.

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

LABEL
OP
OPERAND
#
A
COMMENT

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.

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.

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.

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:

cd
yaAGC/GeminiCatchUpandRendezvousProgram
make

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:

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:

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.

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:

Press the CLEAR button on the MDR.

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.

Press the ENTER button on the MDR to actually perform the
operation.

The astronaut can verify data previously stored in the OBC as
follows:

Press the CLEAR button on the MDR.

Enter just the 2 address digits on the MDK.

Press the READ OUT button on the MDR.

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.

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.

Forward-aft display device. Displays the magnitude of the
forward or aft delta-V from the previously-set zero point, in ft./sec.

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.

Left-right display device. Displays the magnitude of the
leftward or rightward delta-V from the previously-set zero point, in
ft./sec.

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.

Up-down display device. Displays the magnitude of the
upward or downward delta-V from the previously-set zero point, in
ft./sec.

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.

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.

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.

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.

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.

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.

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:

Source code, source code, source code. Any computer
source code—or for that matter, binary code—that ran on the Gemini
computer would
be useful:

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.

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

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: