Revision 2cc40e60d1817fe9a52f631080a3b1c4d31f3a96 authored by Ron Burkey on 04 August 2022, 23:22:04 UTC, committed by Ron Burkey on 04 August 2022, 23:22:04 UTC
due to recent problem reports.
1 parent ca207b4
Gemini.html
<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>The Gemini Spacecraft Computer</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="author" content="Ron Burkey">
<link rel="icon" type="image/png" href="favicon.png">
<meta name="author" content="Ron Burkey">
<script type="text/javascript" src="Header.js"></script>
</head>
<body style="background-image: url(gray3.jpg);">
<script type="text/javascript">
document.write(headerTemplate.replace("@TITLE@","Gemini Spacecraft").replace("@SUBTITLE@","On-Board Computer (OBC)"))
</script>
<h2>Contents</h2>
<ul>
<li><a href="#What_is_the_Gemini_Spacecraft_Computer_">What is the
Gemini Spacecraft Computer (OBC)?</a></li>
<li><a href="#Peripheral_Devices">Peripheral Devices</a><br>
</li>
<li><a href="#Gemini_Documentation">Gemini Documentation</a></li>
<li><a href="#Evolution_of_the_Flight_Software">Evolution of the
Flight Software</a></li>
<li><a href="#Architecture_of_the_Computer">OBC Architecture and
Interfacing<br>
</a></li>
<ul>
<li><a href="#References">References</a></li>
<li><a href="#General_Characteristics_of_the_Computer">General
Characteristics of the OBC</a></li>
<li><a href="#Layout_of_Memory_Words">Layout of Memory Words</a></li>
<li><a href="#Instruction_Sequencing">Instruction Sequencing</a><br>
</li>
<li><a href="#CPU_Instructions">CPU Instructions</a></li>
<li><a href="#IO_Ports_For_PRO_Instruction">I/O Signals (for <span
style="font-family: courier new,courier,monospace;">PRO</span>
Instruction)</a></li>
<li><a href="#Discrete_Inputs_For_CLD_Instruction">Discrete
Inputs (for <span style="font-family: courier
new,courier,monospace;">CLD</span> Instruction)</a></li>
<li><a href="#Subroutine_Linkage">Subroutines</a><br>
</li>
<li><a href="#Telemetry">Telemetry</a></li>
<ul>
<li><a href="#Uplink">Uplink</a></li>
<li><a href="#Downlink">Downlink</a></li>
</ul>
<li><a href="#Rendezvous_Radar">Rendezvous Radar</a></li>
<li><a href="#Aerospace_Ground_Equipment_AGE">Aerospace Ground
Equipment (AGE)</a></li>
<li><a href="#Time_Reference_System_TRS">Time Reference System
(TRS)</a><br>
</li>
<li><a href="#Auxiliary_Tape_Memory_ATM">Auxiliary Tape Memory
(ATM)</a></li>
<li>(See also <a href="#yaPanel_the_Control_Panel_Emulation_">the
yaPanel section</a> for various other user-interface related
peripheral devices.)<br>
</li>
</ul>
<li><a href="#Gemini_Assembly_Language">OBC Assembly Language</a></li>
<ul>
<li><a href="#General_format">General format</a></li>
<li><a href="#Shorthands_for_some_instructions_">Shorthands for
some instructions</a></li>
<li><a href="#Pseudo-ops">Pseudo-ops</a></li>
<li><a href="#Software_Examples">Software Examples</a><br>
</li>
</ul>
<li><a href="#Virtual_AGC_simulation_software">Virtual AGC
simulation software</a></li>
<ul>
<li><a href="#Downloads">Downloads</a><br>
</li>
<li><a href="#The_Gemini_Catch-Up_and_Rendezvous">The Gemini
Catch-Up and Rendezvous Simulation Program</a></li>
<ul>
<li><a href="#Background">Background</a></li>
<li><a href="#Source_Code">Source Code</a><br>
</li>
<li><a href="#Building_the_Catch-Up_and_Rendezvous">Building
the Catch-Up and Rendezvous Simulation Program</a></li>
<li><a href="#Running_the_Catch-Up_and_Rendezvous">Running the
Catch-Up and Rendezvous Simulation Program</a></li>
<li><a href="#Data_for_the_Catch-Up_and_Rendezvous">Data for
the Catch-Up and Rendezvous Simulation Program</a></li>
<li><a href="#Theory_of_Operation_for_the_Catch-Up_and">Theory
of Operation and Porting-Problems for the Catch-Up and
Rendezvous Simulation Program</a></li>
</ul>
<li><a href="#yaOBC_the_OBC_CPU_Emulation"><span
style="font-weight: bold;">yaOBC</span>, the OBC CPU
Emulation</a></li>
<ul>
<li><a href="#Invoking_yaOBC_">Invocation</a></li>
<li><a href="#Debugging_Interface_of_yaOBC">Debugging
interface</a></li>
<li><a href="#Protocol">Communications Protocol</a><br>
</li>
</ul>
<li><a href="#yaOBCASM_the_OBC_Cross-Assembler"><span
style="font-weight: bold;">yaASM</span>, the OBC
Cross-Assembler</a></li>
<li><a href="#yaPanel_the_Control_Panel_Emulation_"><span
style="font-weight: bold;">yaPanel</span>, the
Control-Panel Emulation</a> (includes discussion of <a
href="#yaMDIU_the_MDIU_Emulation">MDIU</a>, <a href="#PCDP">PCDP</a>,
<a href="#IVI">IVI</a>, ...)</li>
</ul>
<li><a href="#Plea_for_Data">Plea for Data</a></li>
<li><a href="#Reminiscences_and_Factoids_from_the">Reminiscences
and Factoids from the Original Developers</a><br>
</li>
<li><a href="#Homage">Homage</a><br>
</li>
</ul>
<h2><a name="What_is_the_Gemini_Spacecraft_Computer_"
id="What_is_the_Gemini_Spacecraft_Computer_"></a>What is the
Gemini Spacecraft Computer (OBC)?<br>
</h2>
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.<br>
<br>
The OBC was designed and manufactured by IBM's Federal Systems
Division, in Owego, New York, just as Apollo's <a href="LVDC.html">Launch
Vehicle Digital Computer (LVDC)</a> was. The OBC and the
LVDC are extraordinarily similar at the CPU level.<br>
<br>
<table summary="" style="width: 100%; text-align: left;"
cellspacing="2" cellpadding="2">
<tbody>
<tr>
<td style="text-align: center; vertical-align: middle;"><img
style="width: 576px; height: 649px;" alt=""
src="GeminiComputerPhoto.jpg" width="576" height="649"><br>
<span style="font-weight: bold;">The Gemini VIII OBC, with
cover removed</span><br>
(Smithsonian National Air & Space Museum)<br>
</td>
<td style="text-align: center; vertical-align: middle;"><img
alt="" src="GeminiPhysicalLayout.jpg" style="width: 566px;
height: 532px;" width="566" height="532"><br>
<br>
<span style="font-weight: bold;">Location of the OBC in the
spacecraft</span><br>
</td>
</tr>
</tbody>
</table>
<br>
<h2><a name="Peripheral_Devices" id="Peripheral_Devices"></a>Peripheral
Devices</h2>
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.<br>
<br>
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 <a href="yaDSKY.html">DSKY</a>—which
comprised the Modular Display Keyboard (MDK) and the Modular Display
Readout (MDR).<br>
<br>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: middle; text-align: center;"><img
style="width: 364px; height: 307px;" alt=""
src="GeminiMDK.png" width="364" height="307"><br>
<span style="font-weight: bold;">Modular Display Keyboard
(MDK)</span><br>
</td>
<td style="vertical-align: top; text-align: center;"><img
style="width: 476px; height: 324px;" alt=""
src="GeminiMDR.png" width="476" height="324"><br>
<span style="font-weight: bold;">Modular Display Readout</span><br>
</td>
</tr>
</tbody>
</table>
<br>
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 <span style="font-style: italic;">Gemini 5 Mission Report</span>.<br>
<br>
<div style="text-align: center;"><a href="Gemini5-panels.png"><img
alt="" title="Click to enlarge" src="GeminiPanels-small.png"
style="border: 2px solid ; width: 863px; height: 610px;"
width="863" height="610"></a><br>
<div style="text-align: left;"><br>
A basic inventory of the guidance sub-systems includes:<br>
<ul>
<li>Attitude Control and Maneuver Electronics (ACME), which is
the sub-system that directly controls the propulsion system.<br>
</li>
<li>Inertial Guidance System (IGS), including the Inertial
Measurement Unit (IMU) and the OBC itself.<br>
</li>
<li>Horizon Sensors</li>
<li>Time Reference System (TRS)</li>
</ul>
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.<br>
<br>
<div style="text-align: center;"><span style="text-decoration:
underline;"><a href="GeminiGuidanceSystemBlockDiagram.jpg"><img
alt="" title="Click for a more-detailed diagram"
src="GeminiGuidanceSystemBlockDiagram-small.jpg"
style="border: 2px solid ; width: 600px; height: 403px;"
width="600" height="403"></a></span><br>
</div>
<br>
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 occurred 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.<br>
</div>
</div>
<h2><a name="Gemini_Documentation" id="Gemini_Documentation"></a>Gemini
Documentation</h2>
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 <a href="links2.html#OBC">Document Library</a>.
There's a lot of unique stuff there contributed by original Gemini
developers.<br>
<br>
Of particular note are the portions of the <i>Gemini Operations
Handbook</i>, for spacecraft 7 and 10, and especially subsection
2.5.7 of those handbooks. These provide user instructions for
the flight-computer software, and in the case of spacecraft 10 are
particularly detailed. For example, in the case of spacecraft
10, there's a complete list, with explanations, scope, and format,
of all of the memory variables (addresses 0-162) accessible from the
MDIU/DCS.<br>
<h2><a name="Evolution_of_the_Flight_Software"
id="Evolution_of_the_Flight_Software"></a>Evolution of the
Flight Software ... or, "Everybody Loves Math Flow 7" ... or,
"What is software, my man? What is software?"<br>
</h2>
Information about the Gemini OBC software is hard to come by.
Useful information we <span style="font-style: italic;">don't</span>
have includes any actual OBC software that's contemporary to the
Gemini project itself, and that's a lot not to know. But the
situation isn't all bad, partly because the development method of
the Gemini OBC software causes us to question what the notion of
having the original software even means. I'll explain more
about that shortly, but there's an important sense in which we
actually do have significant portions of the software at our
disposal.<br>
<br>
But before turning our attention to such lofty matters, let's begin
with some of the more-mundane details. Firstly, 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, we have only partial
information, from the familiarization manual, from <a
href="http://www.hq.nasa.gov/office/pao/History/computers/Ch1-3.html">James
Tomayko's
Computers in Spaceflight, Chapter 1, section 4</a>, and from <a
href="Documents/GeminiSoftwareHistory.pdf"> this short memo</a>.
(Where there's any discrepancy, I personally believe in the memo.)<br>
<br>
The operational programs were characterized in terms of something
called the "Math Flow". In brief, the Math Flow is the
complete design of the software, expressed in Gemini as a series of
very detailed flowcharts. The development of the Math Flow
eventually went through 7 major versions, designated MF-1 through
MF-7. But there were differing revisions for each of the major
versions as well.<br>
<br>
The overall software design was partitioned into several different
areas of basic functionality. In math-flow MF-1 through MF-6, these
functional areas were integrated into a single operational
program. (Though for some missions, unneeded functionality
could be omitted. Thus, Catch-up & Rendezvous were omitted in
spacecraft GT-3, GT-4, and GT-7.) In MF-7, the code was
refactored into 6 different high-level "Program Modules", which
could be loaded into memory from the <a
href="Gemini.html#Auxiliary_Tape_Memory_ATM">Auxiliary Tape Memory
(ATM)</a> when needed during specific mission phases, though
Module I was in memory at all times and didn't need to be loaded
from the ATM. The modules were as follows:<br>
<table summary="" style="margin-left: auto; margin-right: auto;
text-align: left;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="vertical-align: top;">Module<br>
</th>
<th style="vertical-align: top;">Basic Functionality<br>
</th>
</tr>
<tr>
<td style="font-weight: bold;"><span style="font-weight:
normal;">MOD I</span><br>
</td>
<td style="vertical-align: top;">Executor<br>
Pre-Launch<br>
Diagnostics<br>
Computational subroutines (SINCOS, SQROOT, etc.)<br>
ATM-read<br>
</td>
</tr>
<tr>
<td style="font-weight: bold;"><span style="font-weight:
normal;">MOD</span> <span style="font-weight: normal;">II</span><br>
</td>
<td style="vertical-align: top;">Ascent (with abort
capability)<br>
Catch-up (without radar)<br>
Re-entry for ascent-abort<br>
</td>
</tr>
<tr>
<td style="font-weight: bold;"><span style="font-weight:
normal;">MOD</span> <span style="font-weight: normal;">III</span><br>
</td>
<td style="vertical-align: top;">Catch-up (with radar)<br>
Rendezvous<br>
</td>
</tr>
<tr>
<td style="font-weight: bold;"><span style="font-weight:
normal;">MOD</span> <span style="font-weight: normal;">IV</span><br>
</td>
<td style="vertical-align: top;">Touchdown-predict<br>
Re-entry<br>
Re-entry initialization<br>
</td>
</tr>
<tr>
<td style="font-weight: bold;"><span style="font-weight:
normal;">MOD</span> <span style="font-weight: normal;">V</span><br>
</td>
<td style="vertical-align: top;"> Simplified functions as
backup for ATM failure:<br>
<div style="margin-left: 40px;"> Ascent (without abort
capability)<br>
Catch-up and Rendezvous (without self-test)<br>
</div>
</td>
</tr>
<tr>
<td style="font-weight: bold;"><span style="font-weight:
normal;">MOD</span> <span style="font-weight: normal;">VI</span><br>
</td>
<td style="vertical-align: top;">Orbit-predict<br>
Orbit-navigation<br>
Orbit-determination<br>
</td>
</tr>
</tbody>
</table>
<br>
The astronauts used the Computer Mode rotary switch on the <a
href="#PCDP">Pilots' Control and Display Panel</a> to select from
amount the following mission phases to indirectly affect the active
functionality areas: Pre-launch, Ascent, Catch-up, Rendezvous,
or Re-entry.<br>
<br>
All of these functionality areas are self-explanatory, 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.<br>
<br>
As far as the relationship between this stuff and the missions is
concerned, the best info I have at present is as follows:<br>
<br>
<table summary="" style="margin-left: auto; margin-right: auto;
text-align: left;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="font-weight: bold; text-align: center;"><br>
<br>
Spacecraft<br>
</th>
<th style="text-align: center; vertical-align: bottom;">
Mission<br>
Designation<br>
</th>
<th style="text-align: center; vertical-align: bottom;"> Math
Flow<br>
version<br>
</th>
<th style="vertical-align: bottom;">
<div style="text-align: center;"> Program<br>
number,<br>
</div>
<div style="text-align: center;"> revision<br>
</div>
</th>
<th style="font-weight: bold; vertical-align: top;"><br>
<br>
Comments<br>
</th>
</tr>
<tr>
<td style="text-align: center;">GT-1<br>
</td>
<td style="text-align: center;">Gemini 1<br>
</td>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">n/a<br>
</td>
<td style="vertical-align: middle;">Unmanned mission.
Since Gemini I was apparently intended principally as a
structural test of the spacecraft, it may not have had a
computer onboard.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">MF-1<br>
</td>
<td style="text-align: center;">-<br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">MF-2<br>
</td>
<td style="text-align: center;">-<br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; color: rgb(0, 153, 0);"> n/a<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"> n/a<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"> MF-3<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"><a
href="Documents/GeminiMinnickMathFlow.pdf"> 6444540, B</a></td>
<td style="vertical-align: top; color: rgb(0, 153, 0);">
Flowcharts that we have! Seemingly, one minor revision
prior to the software flown in the Gemini 2 unmanned
mission. You'll notice, though, that the first manned
missions (Gemini 3 and 4) still used MF-3, though in a later
minor revision. It's useful to know that:<br>
<ul>
<li>Rendezvous begins on p. 1</li>
<li>Gimbal Angle and CLOCK subroutines are on p. 8</li>
<li>SINCOS and ARCTAN subroutines are on p. 9<br>
</li>
<li>Re-entry begins on p. 10</li>
<li>SHIFT, SQRT (also computes arcsin), and LOG
subroutines are on p. 15</li>
<li>MDIU subroutine is on p. 16</li>
<li>Ascent guidance begins on p. 17</li>
<li>Fast-loop ascent guidance begins on p. 19</li>
<li>Root sum subroutine begins on p. 22</li>
<li>Executor, Accelerometer, DCS, and DAS are on p. 23</li>
<li>MDIU scaling stuff starts on p. 24<br>
</li>
<li>AGE is on p. 26</li>
<li>Standby, TRS, and I/O subroutines are on p. 27<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="text-align: center; color: rgb(0, 153, 0);"> n/a<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"> n/a<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);">
MF-3(?)<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"><a
href="Documents/GeminiAscentAppendixE.pdf"> 62-564-0020, B<br>
(Ascent Guidance and<br>
Fast Ascent Guidance only)</a><br>
</td>
<td style="vertical-align: middle; color: rgb(0, 153, 0);">
Flowcharts that we have! See pp. 2-3 of the linked
document. The document contains a lot of other helpful
stuff like detailed explanations of the variables, some
additional theory, and source code of a FORTRAN
implementation.<br>
<br>
I'm not really clear where this goes in the development
chronology, merely that it is a few months later than the
corresponding elements from the Detailed Math Flow in the
preceding entry.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-2<br>
</td>
<td style="text-align: center;">Gemini 2<br>
</td>
<td style="text-align: center;">MF-3<br>
</td>
<td style="text-align: center; white-space: nowrap;"> 6444541,
C</td>
<td style="vertical-align: middle;">Unmanned mission.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-3<br>
</td>
<td style="text-align: center;">Gemini III<br>
</td>
<td style="text-align: center;">MF-3<br>
</td>
<td style="text-align: center;">6444566, C</td>
<td style="vertical-align: middle;">First manned mission.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-4<br>
</td>
<td style="text-align: center;">Gemini IV<br>
</td>
<td style="text-align: center;">MF-3<br>
</td>
<td style="text-align: center;">6444909, C<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">MF-4<br>
</td>
<td style="text-align: center;">-<br>
</td>
<td style="vertical-align: top;">Work stopped prior to "sell
off".<br>
</td>
</tr>
<tr>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">MF-5<br>
</td>
<td style="text-align: center;">-<br>
</td>
<td style="vertical-align: top;">Work stopped prior to release
or sell off.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-5<br>
</td>
<td style="text-align: center;">Gemini V<br>
</td>
<td style="text-align: center;">MF-6<br>
</td>
<td style="text-align: center;">6444871, B<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-6<br>
</td>
<td style="text-align: center;">Gemini VI-A<br>
</td>
<td style="text-align: center;">MF-6<br>
</td>
<td style="text-align: center; white-space: nowrap;"> 6444871,
D<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-7<br>
</td>
<td style="text-align: center;">Gemini VII<br>
</td>
<td style="text-align: center;">MF-6<br>
</td>
<td style="text-align: center;">6444871, D</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-8 (backup)<br>
</td>
<td style="text-align: center;">n/a<br>
</td>
<td style="text-align: center;">MF-6<br>
</td>
<td style="text-align: center;">6444871, E<br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-8<br>
</td>
<td style="text-align: center;">Gemini VIII<br>
</td>
<td style="text-align: center;">MF-7<br>
</td>
<td style="text-align: center; white-space: nowrap;">MOD I:
6449856, C<br>
MOD II: not used<br>
MOD III: not used<br>
MOD IV: 6449864, B<br>
MOD V: 6449812, B<br>
MOD VI: not used<br>
</td>
<td style="vertical-align: middle;">The principal difference
between MF-6 and MF-7 was the reworking of the integrated
operational program into 6 individual Modules (here referred
to as MOD I through MOD VI) that were treated as independent
programs, loadable into main memory at runtime from the new
Auxiliary Tape Memory (ATM). One consequence is that
each of the 6 Modules in MF-7 now had its own individual
program number and revision.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-9<br>
</td>
<td style="text-align: center;">Gemini IX-A<br>
</td>
<td style="text-align: center;">MF-7<br>
</td>
<td style="text-align: center;">MOD I: 6449856, C<br>
MOD II: not used<br>
MOD III: not used<br>
MOD IV: 6449864, B<br>
MOD V: 6449812, B<br>
MOD VI: not used</td>
<td rowspan="1" style="vertical-align: middle;"> <br>
</td>
</tr>
<tr>
<td style="text-align: center; color: rgb(0, 153, 0);"> n/a<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"> n/a<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"> MF-7<br>
</td>
<td style="text-align: center; color: rgb(0, 153, 0);"><a
href="Documents/GeminiOBC-MathFlow-III.pdf"> MOD III:
6449883</a></td>
<td style="vertical-align: top; color: rgb(0, 153, 0);">
Flowcharts that we have! Later than any Module III
flown prior to the ATM, and therefore presumably
algorithmically mature, but preceding (by some unknown
number of revisions) the first use of Module III as an
integrated program loaded from the ATM in Gemini X and
therefore presumably relatively immature in terms of its
implementation in OBC assembly language. But remember,
we don't have any of the original OBC assembly language, and
it's only the algorithmic correctness that concerns us.<br>
<br>
Incidentally, this scan derived from a microfilm retrieved
from a wastebasket prior to the project's move from the
Washington, D.C., area in mid-1966. Obviously, we're
always trying to find better sources of material. (If
you happen to have any wastebaskets from that era that are
still loaded with microfilm, be sure to let us know.)</td>
</tr>
<tr>
<td style="text-align: center;">GT-10<br>
</td>
<td style="text-align: center;">Gemini X</td>
<td style="text-align: center;">MF-7<br>
</td>
<td style="text-align: center; white-space: nowrap;">MOD I:
6449856, C (?)<br>
MOD II: 6449816, A<br>
MOD III: 6449895<br>
MOD IV: 6449864, B (?)<br>
MOD V: 6449812, B (?)<br>
MOD VI: 6450027<br>
</td>
<td rowspan="1" style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-11<br>
</td>
<td style="text-align: center;">Gemini XI<br>
</td>
<td style="text-align: center;">MF-7<br>
</td>
<td style="text-align: center;">?<br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td style="text-align: center;">GT-12<br>
</td>
<td style="text-align: center;">Gemini XII<br>
</td>
<td style="text-align: center;">MF-7<br>
</td>
<td style="text-align: center;">?<br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
<br>
Finally, let's return to odd question of whether or not we're in
possession of any of the original flight software. This
question is related to the serious if somewhat facetiously-phrased
question asked in this title's heading, namely: "What is
software?" In the context of the Virtual AGC project --- and I
think in the minds of most currently-active computer programmers
(2011) --- the question "What is software?" is very easily
answered: If you have the source code of the program (and some
way of compiling or assembling that code) or if you have the binary
executable of the program (and some way to execute it), then you
have the software. If you have all of the instructions for how
to compile/assemble it, so much the better. But the OBC
software developers had a somewhat different view of this question,
and their view is bound up in the method used to develop the
software.<br>
<br>
The most important thing to understand about the
software-development process for the OBC software is that it was
very heavily dependent on design as opposed to coding. What I
mean by that is the following:<br>
<ol>
<li>Great attention was given to deriving the mathematics needed
for achieving the objectives, and great attention was given as
well to verifying the correctness of that mathematics.</li>
<li>Then (and only then), great attention was given to developing
the "Math Flow". To repeat what I said earlier, the Math
Flow was a series of a flowcharts specifying the algorithms to
be implemented in very great detail. The flowcharts
described the algorithms in such detail that the programmer had
very few options left open to him in actually coding that
software into a form that could be compiled or assembled.</li>
<li>Then (and only then), software was coded. But the coding
was almost entirely a slavish detail-by-detail translation of
the flowchart into computer source-code form.</li>
</ol>
It was interesting (and at first frustrating) for me to discuss the
matter of existence of the software with OBC developers, because
from my point of view the software (source code) seemingly no longer
existed, while from the point of view of the OBC developers the
software did still exist to the extent that the flowcharts still
existed ... because to them the software <span style="font-style:
italic;">is</span> the flowchart and not the source code.
The source code could always be reproduced from the flowchart,
albeit with great effort, and not necessarily byte-for-byte
identical to the original. When viewed from this perspective,
it makes little difference how the flowchart is translated into
computer language—whether into FORTRAN as was done for simulation
purposes or into OBC assembly language for the mission
computer—because regardless, it's the same flowchart so it's the
same program.<br>
<br>
Now, in the preceding paragraph I probably exaggerated the OBC
developers' somewhat in order to make my point, but I think there is
nevertheless a lot of validity in the viewpoint that was
expressed: If we have the Math Flow charts, then we have the
software. You'll notice from the table above that we do have
some of the Math Flow charts, though the validity of what we have
could be debated.<br>
<br>
I'll leave it as an exercise for the reader to decide whether or not
we actually have any of the software, or whether or not we're
rationalizing.<br>
<h2><a name="Architecture_of_the_Computer"
id="Architecture_of_the_Computer"></a>OBC Architecture and
Interfacing<br>
</h2>
<h3><a name="References" id="References"></a>References</h3>
The principal known sources of information about the computer itself
are the "Guidance and Control" sections (Section VIII) of the <span
style="font-style: italic;">Project Gemini Familiarization Manual</span>,
<a href="Documents/GeminiManualVol1Sec2.pdf"> Volume 1</a> and <a
href="Documents/GeminiManualVol2Sec2.pdf"> Volume 2</a>, and most
of the information on this web-page was extracted from those
sources. If you find my re-digesting of the material too poor,
you may want to read the Manual instead. However, any
simulation software, assemblers, etc., will be based on <span
style="font-style: italic;">my</span> understanding and hence on
the content of this web-page, so please bring any errors to my
attention.<br>
<br>
Also, I should state that there's a lot of information on this page
that comes from personal communications with original OBC
developers, and can't be found in any other reference that's going
to be available to the reader ... or probably, to anyone.
While I present a general acknowledgements and "homage" to the
original OBC developers in general at the very end of this web-page,
let me mention here the OBC developers who have been so directly
helpful to me. In no particular order:<br>
<ul>
<li>Gene Mertz</li>
<li>Charlie Leist</li>
<li>Alden Minnick</li>
<li>Don O'Neill</li>
</ul>
<h3><a name="General_Characteristics_of_the_Computer"
id="General_Characteristics_of_the_Computer"></a>General
Characteristics of the OBC</h3>
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.<br>
<br>
The computing characteristics were:<br>
<ul>
<li>39 bits per memory word. Each memory word comprised
three "syllables" (syllable 0, syllable 1, and syllable 2) of 13
bits each.</li>
<li>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.</li>
<li>The memory was logically divided into 16 "sectors" of 256
words each.</li>
<li>At any given time only 2 sectors are actually accessible, the
current sector (selectable under program control) and the
"residual" sector (sector 17 octal).<br>
</li>
<li>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.<br>
</li>
<li>"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 <a href="#Aerospace_Ground_Equipment_AGE">Aerospace
Ground Equipment</a> (AGE), and so were irrelevant for
software.</li>
<li>Integer arithmetic was 2's-complement.<br>
</li>
<li>Instruction cycle time was 140 μs and all instructions
required a single cycle except for MLT and DIV.<br>
</li>
</ul>
<h3><a name="Layout_of_Memory_Words" id="Layout_of_Memory_Words"></a>Layout
of Memory Words</h3>
I should make it clear that in this section I'm describing my
perspective on the organization of OBC memory, in terms of how the
original OBC programmers would have worked with it, in terms of how
one would work with it using the tools I've created for this site,
and in terms of what I think would be the thinking of "modern"
programmers at the time I'm writing these words (2011). I'm
not slavishly reproducing here the material on memory organization
from the most-complete documentation available to us, namely the
"Guidance and Control" sections (Section VIII) of the <span
style="font-style: italic;">Project Gemini Familiarization Manual</span>,
<a href="Documents/GeminiManualVol1Sec2.pdf"> Volume 1</a> and <a
href="Documents/GeminiManualVol2Sec2.pdf"> Volume 2</a>, because
that documentation seems to me to conflict with what I've been told
by actual OBC programmers. The specific area of difficulty is
bit-ordering within memory words. You see, the memory was
accessed by a kind of serial interface, and the natural hardware
view is in terms of the time-order in which the bits are shifted in
and out ... whereas the natural software or mathematical view is in
terms of which bits are the most-significant or least-significant—or
as normally represented, which bits are on the "left" and which are
on the "right". So I'll adopt the latter perspective, but if
you wish to explore what the documentation says on the topic of
bit-ordering, feel free to do so.<br>
<br>
In all cases, when I show you binary or octal representations of OBC
memory, it will use the notation common today, in which the
least-significant bits or octal digits are on the right and the
most-significant bits or octal digits are on the left.<br>
<br>
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. Except in one specific
case, storing and retrieving 26-bit data, syllables within a memory
word are completely unrelated to (and independent of) each
other. So you're really best served by thinking of memory as a
set of syllables rather than a set of words.<br>
<br>
Not all syllables are created equal. In the normal operating
mode of the OBC at mission time, the following rules apply:<br>
<ul>
<li>All CPU instructions which fetch, store, or otherwise operate
on data stored in memory work <span style="font-style: italic;">only</span>
with 26-bit (2-syllable) data words in which the
less-significant syllable is stored in syllable 0 of memory and
the more-significant word is stored in syllable 1 (in the same
word) of memory.</li>
<li>Only syllables 0 and 1 are capable of being modified.
Syllable 2 is read-only.</li>
<li>Therefore, as you can imagine, all data other than code is
allocated in syllables 0 and 1.</li>
<li>Code is commonly stored in syllable 2 ... though since data
does not use all of syllables 0 and 1, some code will be stored
in syllables 0 and 1 as well.</li>
</ul>
(There's also a less-common operating mode called "half-word mode"
which has somewhat different rules, but this mode has limited usage
so we'll return to it later rather than diverting the main
discussion.)<br>
<br>
Now let's look at some common syllable or double-syllable formats.<br>
<br>
Every CPU instruction consists of a single syllable, in the
following bit layout:<br>
<div style="text-align: left; margin-left: 40px;"><br>
<span style="font-family: Courier New,Courier,monospace;">PPPPAAAAAAAAA</span><br>
</div>
<br>
where <span style="font-family: Courier New,Courier,monospace;">PPPP</span>
is a 4-bit code identifying the specific CPU instruction (the "op
code") and <span style="font-family: Courier
New,Courier,monospace;">AAAAAAAAA</span> is a 9-bit code (3 octal
digits) identifying (in a way that varies by instruction type) the
operand for the instruction. Conventionally, OBC programmers
name the individual bits like so:<br>
<ul>
<li><span style="font-family: Courier New,Courier,monospace;">OP4</span>
is the most-significant bit of <span style="font-family:
Courier New,Courier,monospace;">PPPP</span> and <span
style="font-family: Courier New,Courier,monospace;">OP1</span>
is the least-significant.</li>
<li><span style="font-family: Courier New,Courier,monospace;">A9</span>
is the most-significant bit of <span style="font-family:
Courier New,Courier,monospace;">AAAAAAAAA</span> and <span
style="font-family: Courier New,Courier,monospace;">A1</span>
is the least-significant.<br>
</li>
</ul>
In most instruction types, <span style="font-family: Courier
New,Courier,monospace;">A1-A8</span> select a particular memory
word. Since there are only 8 bits, only 256 different words
are accessible. Recall, moreover, that memory consists of 16
sectors of 256 words each of 3 syllables each. So the
instruction is able to select a specific word address, but the
sector containing the word and the syllable within the word can't be
selected ... those have to be known by other means, which we'll
discuss later; for now, just realize that at any time there's some
"current sector" and "current syllable", and that whatever the CPU
is doing operates within that current selection. When <span
style="font-family: Courier New,Courier,monospace;">A1-A8</span>
is interpreted in this way, <span style="font-family: Courier
New,Courier,monospace;">A9</span> can be used to override the
current sector and instead to do a one-time selection of sector 0,
which is referred to as the "residual sector". <span
style="font-family: Courier New,Courier,monospace;">A9=0</span>
means to use the current sector and <span style="font-family:
Courier New,Courier,monospace;">A9=1</span> means to use the
residual sector. But there's no way to select a different
sector or a different syllable on an individual-instruction basis.<br>
<br>
Several instructions use a scheme in which the field consisting of
bits <span style="font-family: Courier New,Courier,monospace;">A1-A3</span>
is given the name "X" and <span style="font-family: Courier
New,Courier,monospace;">A4-A6</span> are given the name "Y", thus
giving the instruction two independent parameters. In those
cases, <span style="font-family: Courier New,Courier,monospace;">A7</span>
and <span style="font-family: Courier New,Courier,monospace;">A8</span>
are unused, and <span style="font-family: Courier
New,Courier,monospace;">A9</span> may or may supply additional
functionality<br>
<br>
For normal 26-bit data, recall that a standard 2's-complement format
is used. OBC programmers conventionally refer to the sign bit
(i.e., the most-significant bit if interpreting the data as an
unsigned integer) as <span style="font-family: Courier
New,Courier,monospace;">S</span>, to the most-significant non-sign
bit as <span style="font-family: Courier New,Courier,monospace;">M25</span>,
and to the least-significant bit as <span style="font-family:
Courier New,Courier,monospace;">M1</span>. Therefore, in a word
containing such data, syllable 1 will contain <span
style="font-family: Courier New,Courier,monospace;">S</span> and <span
style="font-family: Courier New,Courier,monospace;">M25-M14</span>;
syllable 0 will contain <span style="font-family: Courier
New,Courier,monospace;">M13-M1</span>.<br>
<br>
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 some
scaling factor needed to relate the actual value of the number to
the binary value that's stored in memory. The OBC and its software
have no method for dealing with scaling factors, and it was up to
the programmer to understand which interpretation was used, as well
as to explicitly scale values during computations to avoid overflow
and loss of significant bits.<br>
<br>
An important variation in which 26 bits of data aren't numerical in
nature is the so-called "HOP constant". A "HOP constant" is
used by a dedicated CPU instruction (<span style="font-family:
courier new,courier,monospace;">HOP</span>) to change things
such as the currently-selected memory sector and syllable by loading
a hidden CPU register that can't be accessed by other means. The
layout of a HOP constant is as follows:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family: Courier
New,Courier,monospace;">xxxxxxxxHxSSxPPPPAAAAAAAAA</span><br>
</div>
<br>
In this scheme:<br>
<ul>
<li>Bits <span style="font-family: Courier
New,Courier,monospace;">AAAAAAAAA</span> are given names <span
style="font-family: Courier New,Courier,monospace;">A9-A1</span>
and are interpreted as described earlier, in that they allow
selection of a word address (0-255) and provide an override for
current-sector vs. residual sector. After the <span
style="font-family: courier new,courier,monospace;">HOP</span>
instruction executes, this setting persists within the CPU's
hidden HOP register only for the current instruction and is then
incremented to the next sequential word (or to some other word
if a branch occurs).<br>
</li>
<li>Bits <span style="font-family: Courier
New,Courier,monospace;">SS</span>, respectively given the
names <span style="font-family: Courier New,Courier,monospace;">SYB</span>
and <span style="font-family: Courier New,Courier,monospace;">SYA</span>,
specify
the current syllable: 00 for syllable 0, 01 for syllable
1, and 10 for syllable 2. After the <span
style="font-family: courier new,courier,monospace;">HOP</span>
instruction executes, this setting persists until another <span
style="font-family: courier new,courier,monospace;">HOP</span>
instruction changes it.</li>
<li>Bits <span style="font-family: Courier
New,Courier,monospace;">PPPP</span>, respectively given the
names <span style="font-family: Courier New,Courier,monospace;">S4-S1</span>,
specify the current sector. After the <span
style="font-family: courier new,courier,monospace;">HOP</span>
instruction executes, this setting persists until another <span
style="font-family: courier new,courier,monospace;">HOP</span>
instruction changes it, though as we've seen it can be
overridden to instead use sector 0 on an
instruction-by-instruction basis using the <span
style="font-family: Courier New,Courier,monospace;">A9</span>
feature possessed by some of the CPU instructions.<br>
</li>
<li><span style="font-family: Courier New,Courier,monospace;">H</span>
selects between "normal" mode (<span style="font-family: Courier
New,Courier,monospace;">H=0</span>) and "half-word" mode (<span
style="font-family: Courier New,Courier,monospace;">H=1</span>),
and this mode persists until another <span style="font-family:
Courier New,Courier,monospace;">HOP</span> instruction changes
it. "Normal" mode is what I've been describing to you up
to this point. In half-word mode (HWM), the data comes
from syllable 2 rather than syllables 0,1, and therefore
is only 13 bits rather than 26. When the CPU fetches such
data from memory, it fills the least-significant 13 bits of the
CPU's accumulator register, while the most-significant 13-bits
are all 0. An interesting consequence of being in the
half-word mode is that <span style="font-style: italic;">any</span>
<span style="font-family: courier new,courier,monospace;">HOP</span>
instruction will return to normal mode (since <span
style="font-family: Courier New,Courier,monospace;">H</span>
is among the higher 13 bits of a HOP constant) and the current
syllable will always become 0 (since <span style="font-family:
Courier New,Courier,monospace;">SYB</span> and <span
style="font-family: Courier New,Courier,monospace;">SYA</span>
are also among the 13 more-significant bits). Moreover,
since the the OBC's ability to write to syllable 2 is disabled
after the spacecraft has left the hangar, no <span
style="font-family: courier new,courier,monospace;">STO</span>
or <span style="font-family: courier new,courier,monospace;">SPQ</span>
have any effect in half-word mode.<br>
</li>
<li>At power-up, the behavior differed between the early Gemini
missions without ATM (Auxiliary Tape Memory), and the later ones
with ATM:</li>
<ul>
<li>Without ATM, it is as if a HOP constant is loaded that puts
the unit in normal mode (i.e., not half-word mode) at syllable
0 of word 0 in sector 0.</li>
<li>With ATM, it is as if a HOP constant is loaded that puts the
unit into half-word mode at syllable 2 of word 0 in sector 0.<br>
</li>
</ul>
</ul>
You may wonder what half-word mode is good for? Well,
originally, it seems to have been intended for testing
purposes. Later, when the flight-program outstripped the size
of available memory, it became necessary to add the ATM and use it
to overlay programs at runtime. In that case, I guess, it's
useful to be able to run a program entirely within syllable 2 (which
is read-only) without fear that the ATM can overlay it. But
you know, I'm not really sure.<br>
<h3><a name="Instruction_Sequencing" id="Instruction_Sequencing"></a>Instruction
Sequencing</h3>
You may naïvely suppose (I did!) if you did not read the preceding
section in great detail, that the everyday usage of the words "word"
and "syllable" applies similarly in stepping through the OBC (or
LVDC) instructions. In proceeding through a sentence of
natural language like English, you use up all of the syllables in a
word before proceeding to the next word. So you might suppose
that OBC instructions would sequence in a manner something like the
following: word <span style="font-style: italic; font-family:
Helvetica,Arial,sans-serif;">N</span> syllable 0, word <span
style="font-style: italic; font-family:
Helvetica,Arial,sans-serif;">N</span> syllable 1, word <span
style="font-style: italic; font-family:
Helvetica,Arial,sans-serif;">N</span> syllable 2, word <span
style="font-style: italic; font-family:
Helvetica,Arial,sans-serif;">N+1</span> syllable 0, word <span
style="font-style: italic; font-family:
Helvetica,Arial,sans-serif;">N+1</span> syllable 1, and so
on. In fact, this is not the case at all, and (as you may
infer from the instruction definitions in the following section)
would have caused insuperable difficulties. So get the naïve
interpretation right out of your head!<br>
<br>
<span style="font-style: italic;">Instead,</span> the instruction
sequencing was like this:<br>
<div style="margin-left: 40px;"><br>
word 0 syllable <span style="font-style: italic; font-family:
Helvetica,Arial,sans-serif;">N<br>
</span> word 1 syllable <span style="font-style: italic;
font-family: Helvetica,Arial,sans-serif;">N<br>
</span> word 2 syllable <span style="font-style: italic;
font-family: Helvetica,Arial,sans-serif;">N<br>
</span> etc.<br>
</div>
<br>
so that the syllable number never changed automatically as you
progressed through the program. But you could always change
the syllable manually by executing an instruction (<big><span
style="font-family: Courier New,Courier,monospace;">HOP</span></big>)
and
a HOP constant specifically designed to change the syllable
number. <br>
<br>
In retrospect, from an outsiders point of view, it would perhaps
have been less confusing in terms of instruction sequencing if the
OBC hardware designers had used the word "paragraph" rather than
"syllable". Alas! it's a bit late to worry about that
now. The OBC programmers I've consulted seem to think that
this is a perfectly natural scheme, and don't seem to have
experienced any confusion over the concept of "syllables". <br>
<h3><a name="CPU_Instructions" id="CPU_Instructions"></a>CPU
Instructions</h3>
If you're interested in Gemini, you may not be very interested in
Apollo's <a href="LVDC.html#CPU_Instructions">LVDC</a> instruction
set. But there are so many similarities between the two that
I'll probably not be able to resist the temptation to point out some
of the differences as I proceed. A difference not pointed out
in the table below is that the LVDC instructions <span
style="font-family: courier new,courier,monospace;">MPH</span>, <span
style="font-family: courier new,courier,monospace;">XOR</span>,
and <span style="font-family: courier new,courier,monospace;">CDS</span>,
<span style="font-family: courier new,courier,monospace;">EXM</span>
are not present in the OBC.<br>
<br>
Note that in what follows, a name representing a location of memory
holding an instruction is called a "left-hand symbol" in the
parlance of the Gemini OBC programmers, and I will continue to call
it that (or LHS for short) rather than adopting more-current
terminology.<br>
<br>
Finally, when I talk below about the assembly-language syntax of the
instructions, I'm referring to the syntax supported by my own <span
style="font-weight: bold;">yaASM</span> assembler presented as a
download on this website. This syntax is very similar to the
original OBC assembler's syntax but we can't be sure it's identical
because no documentation for the original assembler has been located
up to this point in time.<br>
<br>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="text-align: center;"><br>
<br>
Mnemonic<br>
</th>
<th style="text-align: center;">Opcode<br>
(OP1-OP4)<br>
in octal<br>
</th>
<th style="vertical-align: top; text-align: center;"> Timing<br>
(140 μs<br>
cycles)<br>
</th>
<th><br>
<br>
Description of the instruction<br>
</th>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> HOP<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 00<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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 <span style="font-family: Courier
New,Courier,monospace;">HOP</span> 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 <span style="font-family: Courier
New,Courier,monospace;">HOP</span> instruction is
used. See also <span style="font-family: Courier
New,Courier,monospace;">TRA</span>.<br>
<br>
However ... the fact that <span style="font-family: Courier
New,Courier,monospace;">HOP</span> operates on HOP
constants rather than on the left-hand symbols that are the
labels for locations in the code as actually understood by
the programmers, is not very convenient. The simple
act of HOPping to a location would have to look something
like this:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">HTARGET HOPC
TARGET # Set up a HOP
constant for the target location.<br>
...<br>
HOP HTARGET # HOP to
the target location<br>
...<br>
TARGET
...
#
Location we want to HOP to.</span><br>
</div>
<br>
This is pretty cumbersome. The assembler therefore
provides a special feature in that if the operand of a HOP
is a left-hand symbol for a code location, which would
otherwise be illegal, the assembler silently allocates and
initializes a HOP constant of the same name, but enclosed in
parentheses, and then it pretends that the operand of the
HOP was really the newly-created HOP constant.
Therefore, in assembly language, the following becomes legal
even though seemingly illegal in machine code:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">
HOP TARGET #
HOP to the target location<br>
...<br>
TARGET
...
#
Location we want to HOP to.<br>
</span></div>
<br>
But what the assembler really outputs in this case is the
same as in the first example (with the HOP constant named "<span
style="font-family: Courier New,Courier,monospace;">(TARGET)</span>"
instead of "<span style="font-family: Courier
New,Courier,monospace;">HTARGET</span>").<br>
<br>
The assembler performs a similar service for the <span
style="font-family: Courier New,Courier,monospace;">CLA</span>
and <span style="font-family: Courier
New,Courier,monospace;">STO</span> instructions (see
below). There are some drawbacks to this special feature as
well, namely:<br>
<ul>
<li>Any left-hand symbols used as targets of HOPs in this
way must be 6 characters or less rather than 8.</li>
<li>The assembler always creates the implicit HOP
constants in the residual sector 17, syllable 0.</li>
<li>Since there are no explicit allocations for the
implicit HOP constants, it's easy for the programmer to
overlook that they're being created, and therefore to be
less aware of the rate at which memory is being used up.</li>
<li>There's no provision for half-word mode.</li>
</ul>
Fortunately, there's no drawback here that can't be worked
around by explicitly defining any troublesome HOP constants
needed, as in the first example.<br>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> DIV<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 01<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
(results<br>
available<br>
after 6)<br>
</td>
<td style="vertical-align: middle;"> 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 <span style="font-family:
courier new,courier,monospace;">SPQ</span> instruction
from the 5th instruction following the <span
style="font-family: Courier New,Courier,monospace;">DIV</span>.
In
other words, 4 other instructions not involving
multiplication or division can be performed in the interval
between <span style="font-family: Courier
New,Courier,monospace;">DIV</span> and <span
style="font-family: courier new,courier,monospace;">SPQ</span>.<br>
<br>
To illustrate the assembly-language syntax, let's divide the
integer 56 by 3 and store the result in a variable:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">RESULT
#
Allocate variable for output.<br>
K56
DEC
56 # Provide
dividend as a constant.<br>
K3
DEC
3 #
Provide divisor as a constant.<br>
CLA
K56 # Load divisor
into accumulator.<br>
DIV
K3 # Start the
division.<br>
NOP
#
The result won't be available<br>
NOP
#
for a while, so kill some time.<br>
NOP<br>
NOP<br>
SPQ
#
Fetch quotient into accumulator.<br>
STO RESULT #
Save it!</span><br>
</div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> PRO<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 02<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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=1) or logically OR'd with the
accumulator (A9=0). A table of the i/o signals vs.
addresses is given in the <a
href="#IO_Ports_For_PRO_Instruction">following section</a>.
(The <span style="font-family: Courier
New,Courier,monospace;">PRO</span> instruction is
essentially equivalent to the <a
href="LVDC.html#CPU_Instructions">LVDC</a> <span
style="font-family: courier new,courier,monospace;">PIO</span>
instruction, but the selection of i/o signals is different.)<br>
<br>
The documentation does not explain this, but I think that
when the <span style="font-family: Courier
New,Courier,monospace;">PRO</span> instruction is
accessing a single-bit signal, only the accumulator's sign
bit is used as the output or the input. (I'm not sure
what the effect on other bit-positions should be on input.)<br>
<br>
There are several allowable assembly-language syntaxes for
this instruction:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">PRO <span
style="font-style: italic;">YX </span></span><span
style="font-family: Courier New,Courier,monospace;"># If
A9=0</span><br>
<span style="font-family: Courier New,Courier,monospace;">PRO
0<span style="font-style: italic;">YX </span></span><span
style="font-family: Courier New,Courier,monospace;">#
Same as "PRO YX"</span><br>
<span style="font-family: Courier New,Courier,monospace;">PRO
4<span style="font-style: italic;">YX</span>
# If A9=1</span><br>
<br>
</div>
(Or, you could just look at it as having a literal octal
constant as operand, and that constant was placed directly
into the bits A9-A1.) For example, to read MDIU
keystroke data, <span style="font-style: italic;">X</span>=3
and <span style="font-style: italic;">Y</span>=4, so<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">PRO 43</span><br>
</div>
<div style="margin-left: 40px;"></div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> RSU<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 03<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> Same as <span
style="font-family: monospace;">SUB</span> (see below),
except that the order of the operands in the subtraction is
reversed.<br>
<br>
Assembly-language example to compute <span
style="font-family: Courier New,Courier,monospace;">RESULT</span>=3-56:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">RESULT
#
Allocate variable for output.<br>
ARG1 DEC
56<br>
ARG2 DEC 3<br>
CLA ARG1<br>
RSU
ARG2<br>
STO RESULT</span></div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> ADD<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 04<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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".<br>
<br>
Assembly-language example to compute <span
style="font-family: Courier New,Courier,monospace;">RESULT</span>=56+3:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">RESULT
#
Allocate variable for output.<br>
ARG1 DEC
56<br>
ARG2 DEC 3<br>
CLA ARG1<br>
ADD
ARG2<br>
STO RESULT </span>
</div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> SUB<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 05<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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 <span style="font-family:
Courier New,Courier,monospace;">RSU</span>.<br>
<br>
Assembly-language example to compute <span
style="font-family: Courier New,Courier,monospace;">RESULT</span>=56-3:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">RESULT
#
Allocate variable for output.<br>
ARG1 DEC
56<br>
ARG2 DEC 3<br>
CLA ARG1<br>
SUB
ARG2<br>
STO RESULT<br>
</span></div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> CLA<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 06<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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".<br>
<br>
Assembly-language example to load the accumulator with
decimal 56:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">K56
DEC 56</span><br>
<span style="font-family: Courier New,Courier,monospace;">
CLA
K56</span><br>
</div>
<br>
Note that as with the <span style="font-family: Courier
New,Courier,monospace;">HOP</span> instruction, the
assembler allows seemingly meaningless usages like "<span
style="font-family: Courier New,Courier,monospace;">CLA
LHS</span>", where <span style="font-family: Courier
New,Courier,monospace;">LHS</span> is the left-hand symbol
of a code location rather that the name of a variable or
constant. What the assembler does in this case is
automatically, silently to create a HOP constant in memory
called "<span style="font-family: Courier
New,Courier,monospace;">(LHS)</span>", and then to
substitute the "<span style="font-family: Courier
New,Courier,monospace;">CLA (LHS)</span>" for the original
instruction. See the notes accompanying the <span
style="font-family: Courier New,Courier,monospace;">HOP</span>
instruction for full details.<br>
<div style="margin-left: 40px;"></div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> AND<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 07<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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".<br>
<br>
Assembly-language example to compute <span
style="font-family: Courier New,Courier,monospace;">RESULT</span>=037&052
(i.e.,
to logically AND together octal 37 and octal 52):<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">RESULT
#
Allocate variable for output.<br>
ARG1 OCT 37<br>
ARG2 OCT 52<br>
CLA ARG1<br>
SUB
ARG2<br>
STO RESULT</span></div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> MPY<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 10<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
(results<br>
available after 3)<br>
</td>
<td style="vertical-align: middle;">This is a multiplication
instruction. It multiplies two 24-bit numbers to
produce a 26-bit product. The accumulator provides the
address of one multiplication factor, and the address
embedded in the instruction points to the other
factor. 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 <span
style="font-family: monospace;">SPQ</span> instruction on
the 2nd instruction following <span style="font-family:
Courier New,Courier,monospace;">MPY</span>. Any
other instruction not involving multiplication or division
can be performed between the <span style="font-family:
courier new,courier,monospace;">MPY</span> and the <span
style="font-family: courier new,courier,monospace;">SPQ</span>.<br>
<br>
To illustrate the assembly-language syntax, let's multiply
the integer 56 by 3 and store the result in a variable:<br>
<br>
<span style="font-family: Courier New,Courier,monospace;">RESULT
#
Allocate variable for output.<br>
K56
DEC 56<br>
K3
DEC 3<br>
CLA K56<br>
MPY
K3 # Start the
multiplication.<br>
NOP
#
The result won't be available<br>
NOP
#
for a while, so kill some time.<br>
SPQ
#
Fetch product into accumulator.<br>
STO RESULT #
Save it!</span><br>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> TRA<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 11<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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 1 in
the new program counter. (This differs from the
behavior of the corresponding <a
href="LVDC.html#CPU_Instructions">LVDC</a> 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.)<br>
<br>
See also the description of <a
href="Gemini.html#Shorthands_for_some_instructions_">shorthands
for
various instructions</a>.<br>
<br>
Assembly-language examples:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;"># Branch from location
START to location FINISH.<br>
START TRA
FINISH<br>
...</span><br>
<span style="font-family: Courier New,Courier,monospace;">FINISH
...<br>
# Branch from location START2 to FINISH2, but use<br>
# relative addressing rather than the left-hand<br>
# symbol FINISH2. The NOP instructions below<br>
# could be anything --- the point is simply that<br>
# FINISH2 is 3 words in memory after START2.<br>
START2 TRA *+3<br>
NOP<br>
NOP<br>
FINISH2 ...</span><br style="font-family: Courier
New,Courier,monospace;">
</div>
<br>
The operand for <span style="font-family: Courier
New,Courier,monospace;">TRA</span> is either an existing
left-hand symbol for an instruction (rather than for a
variable or constant), or else an expression of the form "*+<span
style="font-style: italic;">N</span>" or "*-<span
style="font-style: italic;">N</span>", where <span
style="font-style: italic;">N</span> is any number from 1
to 7.<br>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> SHF<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 12<br>
</td>
<td style="text-align: center; vertical-align: middle;"><br>
</td>
<td style="vertical-align: middle;"> Performs a logical shift
operation on the accumulator. For this instruction,
only bits A1-6 are actually used, as follows:<br>
<br>
<table summary="" style="text-align: left; margin-left:
auto; margin-right: auto;" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<th style="vertical-align: top; font-weight: bold;
text-align: center;"> X<br>
(A1-3)<br>
</th>
<th style="vertical-align: top; font-weight: bold;
text-align: center;"> Y<br>
(A4-6)<br>
</th>
<th style="vertical-align: top; font-weight: bold;"><br>
Description of operation<br>
</th>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">
1<br>
</td>
<td style="vertical-align: top; text-align: center;">
2<br>
</td>
<td style="vertical-align: top;">Shift "right" one
position<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">
0<br>
</td>
<td style="vertical-align: top; text-align: center;">
2<br>
</td>
<td style="vertical-align: top;">Shift "right" two
positions</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">
X<br>
</td>
<td style="vertical-align: top; text-align: center;">
3<br>
</td>
<td style="vertical-align: top;">Shift "left" one
position</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">
X<br>
</td>
<td style="vertical-align: top; text-align: center;">
4<br>
</td>
<td style="vertical-align: top;">Shift "left" two
positions</td>
</tr>
<tr>
<td colspan="2" rowspan="1" style="vertical-align:
top; text-align: center;"> (Other)<br>
</td>
<td style="vertical-align: top;">Clears the
accumulator<br>
</td>
</tr>
</tbody>
</table>
<br>
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.<br>
<br>
For the left-shifts, 0 is shifted into the least-significant
bit at the right. For the right-shifts, the sign-bit
is duplicated into the most-significant bit at the left.<br>
<br>
For illegal X,Y combinations, the accumulator is zeroed.<br>
<br>
Note that this instruction is similar to the corresponding <a
href="LVDC.html#CPU_Instructions">LVDC</a> instruction,
but differs in details.<br>
<br>
See also the description of <a
href="Gemini.html#Shorthands_for_some_instructions_">shorthands
for
various instructions</a>.<br>
<br>
There assembly-language syntax for this instruction is:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">SHF <span
style="font-style: italic;">YX</span></span><br>
<br>
</div>
(Or, you could just look at it as having a literal octal
constant as operand, and that constant was placed directly
into the bits A6-A1.) For example, to shift right one
position, <span style="font-style: italic;">X</span>=1 and
<span style="font-style: italic;">Y</span>=2, so<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">SHF 21</span><br>
</div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> TMI<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 13<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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 <span style="font-family:
Courier New,Courier,monospace;">TNZ</span>. (This
differs from the behavior of the corresponding <a
href="LVDC.html#CPU_Instructions">LVDC</a> 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.)<br>
<br>
Assembly-language examples:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;"># Branch from location
START to location FINISH<br>
# because VALUE is negative:<br>
VALUE DEC -129<br>
START TMI FINISH<br>
...
#
Never gets here!<br>
</span> <span style="font-family: Courier
New,Courier,monospace;">FINISH
...
#
But does get to here!<br>
# Don't branch from START2 to FINISH2, because<br>
# VALUE2 is not negative:<br>
VALUE2 DEC 127<br>
START2 TMI FINISH2<br>
...
#
Comes to here!<br>
TRA BAILOUT<br>
FINISH2
...
#
Never comes to here!<br>
BAILOUT ...<br>
</span><br style="font-family: Courier
New,Courier,monospace;">
</div>
The operand for <span style="font-family: Courier
New,Courier,monospace;">TMI</span> is either an existing
left-hand symbol for an instruction (rather than for a
variable or constant), or else an expression of the form "*+<span
style="font-style: italic;">N</span>" or "*-<span
style="font-style: italic;">N</span>", where <span
style="font-style: italic;">N</span> is any number from 1
to 7. The usage of the latter relative-addressing
forms isn't illustrated in the code example for <span
style="font-family: Courier New,Courier,monospace;">TMI</span>,
but you can look at the code example for <span
style="font-family: Courier New,Courier,monospace;">TRA</span>
instead; it works exactly the same for <span
style="font-family: Courier New,Courier,monospace;">TMI</span>.<br>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> STO<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 14<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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.<br>
<br>
Assembly-language example:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">RESULT
#
Allocate a variable</span><br style="font-family:
Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">
STO
RESULT # Store accumulator value in the
variable.</span><br>
</div>
<br>
Note that as with the <span style="font-family: Courier
New,Courier,monospace;">HOP</span> instruction, the
assembler allows seemingly meaningless usages like "<span
style="font-family: Courier New,Courier,monospace;">STO
LHS</span>", where <span style="font-family: Courier
New,Courier,monospace;">LHS</span> is the left-hand symbol
of a code location rather that the name of a variable or
constant. What the assembler does in this case is
automatically, silently to create a HOP constant in memory
called "<span style="font-family: Courier
New,Courier,monospace;">(LHS)</span>", and then to
substitute the "<span style="font-family: Courier
New,Courier,monospace;">STO (LHS)</span>" for the original
instruction. See the notes accompanying the <span
style="font-family: Courier New,Courier,monospace;">HOP</span>
instruction for full details.<br>
<div style="margin-left: 40px;"></div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> SPQ<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 15<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;">Store a product or
quotient (computed with <span style="font-family: courier
new,courier,monospace;">MPY</span> or <span
style="font-family: courier new,courier,monospace;">DIV</span>)
into 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. (This instruction is somewhat similar to the <a
href="LVDC.html#CPU_Instructions">LVDC</a> instruction <span
style="font-family: courier new,courier,monospace;">CLA
0775</span>, though quite different in detail.)<br>
<br>
For assembly-language examples, see <span
style="font-family: Courier New,Courier,monospace;">MPY</span>
or <span style="font-family: Courier
New,Courier,monospace;">DIV</span> above.<br>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> CLD<br>
</td>
<td style="vertical-align: middle; text-align: center;"> 16<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> A discrete input (i.e., a
single bit) selected by the operand address is read into the
accumulator. The entire accumulator is overwritten so
that every bit position has the value of the discrete input
bit, and consequently will be either 000000000 or else
377777777 octal. A test of either <span
style="font-family: Courier New,Courier,monospace;">TMI</span>
or <span style="font-family: Courier
New,Courier,monospace;">TNZ</span> thereafter can thus
branch on the basis of the bit value. A <a
href="#Discrete_Inputs_For_CLD_Instruction">table of the
allowed discrete inputs</a> follows later. (This
instruction does not exist in the <a
href="LVDC.html#CPU_Instructions">LVDC</a>.)<br>
<br>
See also the description of <a
href="Gemini.html#Shorthands_for_some_instructions_">shorthands
for
various instructions</a>.<br>
<br>
There assembly-language syntax for this instruction is:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">CLD <span
style="font-style: italic;">YX</span></span><br>
<br>
</div>
(Or, you could just look at it as having a literal octal
constant as operand, and that constant was placed directly
into the bits A6-A1.) For example, to read the MDIU
data-ready bit, <span style="font-style: italic;">X</span>=1
and <span style="font-style: italic;">Y</span>=0, so<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">CLD 01</span></div>
</td>
</tr>
<tr>
<td style="font-family: courier new,courier,monospace;
vertical-align: middle; text-align: center;"> TNZ</td>
<td style="vertical-align: middle; text-align: center;"> 17<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="vertical-align: middle;"> 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 word address within the sector,
while bit A9 selects between the current sector vs. the
residual sector. (In the LVDC, A9 instead selects the
syllable within the current sector, which is possible since
the LVDC has only 2 syllables.) See also <span
style="font-family: Courier New,Courier,monospace;">TMI</span>.<br>
<br>
Assembly-language examples:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;"># Example 1: Branch to
location IS129 if accumulator is<br>
# equal to 129 and to ISNOT129 if accumulator is not<br>
# equal to 129:<br>
K129 DEC 129<br>
SUB K129<br>
TNZ
ISNOT129<br>
TRA IS129<br>
...<br>
IS129 ...<br>
...<br>
ISNOT129 ...<br>
# Example 2: A simple loop with 10 iterations:<br>
LOOPCTR
#
Variable for counting loop iterations.<br>
K1
DEC 1<br>
K10
DEC 10<br>
CLA
K10 # Setup for the
loop.<br>
STO LOOPCTR<br>
LOOP
...
#
Do stuff<br>
CLA LOOPCTR #
Decrement and test loop counter<br>
SUB K1<br>
TNZ LOOP<br>
...
#
Done!<br>
</span><br style="font-family: Courier
New,Courier,monospace;">
</div>
The operand for <span style="font-family: Courier
New,Courier,monospace;">TNZ</span> is either an existing
left-hand symbol for an instruction (rather than for a
variable or constant), or else an expression of the form "*+<span
style="font-style: italic;">N</span>" or "*-<span
style="font-style: italic;">N</span>", where <span
style="font-style: italic;">N</span> is any number from 1
to 7. The usage of the latter relative-addressing
forms isn't illustrated in the code example for <span
style="font-family: Courier New,Courier,monospace;">TNZ</span>,
but you can look at the code example for <span
style="font-family: Courier New,Courier,monospace;">TRA</span>
instead; it works exactly the same for <span
style="font-family: Courier New,Courier,monospace;">TNZ</span>.<br>
</td>
</tr>
</tbody>
</table>
<br>
<h3><a name="IO_Ports_For_PRO_Instruction"
id="IO_Ports_For_PRO_Instruction"></a>I/O Signals (For <span
style="font-family: courier new,courier,monospace;">PRO</span>
Instruction)<br>
</h3>
Note that in assembly language, in the operand for a <span
style="font-family: courier new,courier,monospace;">PRO</span>
instruction, the Y operand field would proceed the X operand
field. So, for example, if X=3 and Y=4, the instruction would
be <span style="font-family: courier new,courier,monospace;">PRO43</span>.
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.<br>
<br>
<table summary="" style="margin-left: auto; margin-right: auto;
text-align: left;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th colspan="2" rowspan="1" style="text-align: center;
vertical-align: middle;"> Operand<br>
</th>
<th colspan="1" rowspan="2" style="text-align: center;
vertical-align: bottom;">Input /<br>
Output<br>
</th>
<th colspan="1" rowspan="2" style="text-align: center;
vertical-align: bottom;"> Signal<br>
</th>
<th colspan="1" rowspan="2" style="text-align: center;
vertical-align: bottom;"> Comment<br>
</th>
</tr>
<tr>
<th style="text-align: center; vertical-align: middle;">X
(A1-A3)<br>
</th>
<th style="text-align: center; vertical-align: middle;">Y
(A4-A6)<br>
</th>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> In<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Digital
Command System shift pulse gate<br>
</td>
<td style="vertical-align: middle;">Causes a 24-bit word
buffered in the <a href="#Uplink">Digital Command System</a>
(DCS) to be read into bits M1-M24 of the accumulator.
Or, reads data from the <a href="#Rendezvous_Radar">Rendezvous
Radar</a> (if any).<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Data
Transmission System control gate<br>
</td>
<td style="vertical-align: middle;">Used to output a data word
to the <a href="#Downlink">Instrumentation System</a> (IS)
for digital downlink.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;">
In/Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Time
Reference System data and timing pulses<br>
</td>
<td style="vertical-align: middle;">The action of this signal
seems pretty complex. Please read the section on the <a
href="#Time_Reference_System_TRS">Time Reference System</a>
(TRS) for my conclusions as to what it's actually supposed
to do.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Digit
magnitude weight 1<br>
</td>
<td style="vertical-align: middle;"> Used in conjunction with
"Digit magnitude weight 2", "Digit magnitude weight 4", and
"Digit magnitude weight 8" to write a particular digit to an
<a href="#yaMDIU_the_MDIU_Emulation">MDR</a> position
previously selected using the "Digit select weight <span
style="font-style: italic;">X</span>" outputs. The
weights derive from a BCD value of the digit whose display
is desired.<br>
<br>
I haven't seen any explanation of how to clear a digit so
that it's blank ... perhaps there was no such feature,
though it seems to me that it would make data-entry very
confusing if so. There are a number of ways this might
have been done. Until I understand it better, the <span
style="font-weight: bold;">yaPanel</span> MDIU emulator
handles this as follows:<br>
<ul>
<li>Using any combination of magnitudes that doesn't form
a BCD (i.e., something in the range 0-9) will clear the
selected digit to be blank.</li>
<li>Pressing the MDR's CLEAR button will make all of the
digits blank.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Reset
data ready, enter, and readout<br>
</td>
<td style="vertical-align: middle;">When zeroed, signals the <a
href="#yaMDIU_the_MDIU_Emulation">MDIU</a> 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 <span
style="font-family: courier new,courier,monospace;">CLD</span>
inputs associated with the ENTER and READ OUT keys also are
cleared as a result.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Digit
select weight 1<br>
</td>
<td style="vertical-align: middle;">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 <a href="#yaMDIU_the_MDIU_Emulation">MDIU</a>.
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.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Memory
strobe<br>
</td>
<td style="vertical-align: middle;">I believe that this signal
is used <span style="font-style: italic;">only</span> in
conjunction with the <a
href="#Aerospace_Ground_Equipment_AGE">AGE</a> 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.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Computer ready<br>
</td>
<td style="vertical-align: middle;">Signal to the <a
href="#Uplink">Digital Command System</a> (DCS) that the
OBC wishes to read a buffered uplinked data word. Also
used to tell the <a href="#Rendezvous_Radar">Rendezvous
Radar</a>, 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 (<span
style="font-family: courier new,courier,monospace;">CLD00</span>).<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Drive
counters to zero<br>
</td>
<td style="vertical-align: middle;">For setting a delta-V
display on the <a href="#IVI">IVI</a> to zero. First
do <span style="font-family: courier
new,courier,monospace;">PRO11</span> with the accumulator
negative, then (see "Select X counter") select the X, Y, or
Z axis, then do <span style="font-family: courier
new,courier,monospace;">PRO11</span> with the accumulator
positive or zero to return to the normal state. <span
style="font-family: courier new,courier,monospace;">CLD31</span>,
<span style="font-family: courier new,courier,monospace;">CLD25</span>,
and <span style="font-family: courier
new,courier,monospace;">CLD26</span> can be subsequently
used for feedback that the displays are actually at zero.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Enter<br>
</td>
<td style="vertical-align: middle;">When inactive, the <a
href="#Time_Reference_System_TRS">Time Reference System</a>
(TRS) is capable of receiving timing data (like T<sub><small>R</small></sub>
or T<sub><small>X</small></sub>) from the ODC. When
active, the ODC can receive timing data (like ET or T<sub><small>R</small></sub>)
from the TRS. </td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Digit
magnitude weight 2<br>
</td>
<td style="vertical-align: middle;">See Digit magnitude
weight 1<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Display
device drive<br>
</td>
<td style="vertical-align: middle;"> The "display device
drive", as far as I can see, is what's used to turn the
physical wheel on which the <a
href="Gemini.html#yaMDIU_the_MDIU_Emulation">MDIU</a>
display-digits are inscribed to the proper position for
display. In other words when the drive is off (i.e.,
PRO41 output a zero) the last-selected digit continues to be
displayed, while when the drive is on (PRO41 output
non-zero) the display wheel will be turned if
necessary. Therefore, the drive is normally off, but
is turned on briefly when a digit is being changed.
The full procedure is as follows:<br>
<ol>
<li>Use the digit-select weights to choose the
display-position which is supposed to be changed.</li>
<li>Turn on the display device drive.</li>
<li>Use the digit-magnitude weights to determine what
digit is driven into the selected display position.</li>
<li>Wait 0.5 seconds.</li>
<li>Turn off the display device drive.<br>
</li>
</ol>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Digit
select weight 2<br>
</td>
<td style="vertical-align: middle;">See Digit select weight 1<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"><br>
</td>
<td style="text-align: left; vertical-align: middle;">
Autopilot scale factor<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Pitch
resolution<br>
</td>
<td style="vertical-align: middle;">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.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Select
X counter<br>
</td>
<td style="vertical-align: middle;"> Used along with "Select Y
counter" to select one of the <a href="#IVI">IVI</a>'s
delta-V displays to receive additional commands, as follows:<br>
<ul>
<li>X-axis: <span style="font-family: courier
new,courier,monospace;">PRO12</span> with accumulator
negative, <span style="font-family: courier
new,courier,monospace;">PRO13</span> with accumulator
positive or zero.</li>
<li>Y-axis: <span style="font-family: courier
new,courier,monospace;">PRO12</span> with accumulator
positive or zero, <span style="font-family: courier
new,courier,monospace;">PRO13</span> with accumulator
negative.</li>
<li>Z-axis: <span style="font-family: courier
new,courier,monospace;">PRO12</span> with accumulator
negative, <span style="font-family: courier
new,courier,monospace;">PRO13</span> with accumulator
negative.</li>
</ul>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Aerospace Ground Equipment data link<br>
</td>
<td style="vertical-align: middle;">For outputting a single
data bit to the dedicated <a
href="#Aerospace_Ground_Equipment_AGE">AGE</a> data link.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Digit
magnitude weight 4<br>
</td>
<td style="vertical-align: middle;">See Digit magnitude
weight 1</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Digit
select weight 4<br>
</td>
<td style="vertical-align: middle;">See Digit select weight 1<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> In<br>
</td>
<td style="text-align: left; vertical-align: middle;">Reset
start computation<br>
</td>
<td style="vertical-align: middle;">From the <a href="#PCDP">PCDP</a>'s
RESET switch.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Yaw
resolution<br>
</td>
<td style="vertical-align: middle;">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.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Select
Y counter<br>
</td>
<td style="vertical-align: middle;">See "Select X counter".<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Aerospace Ground Equipment data clock<br>
</td>
<td style="vertical-align: middle;">Provides a data clock, one
pulse at a time, for reading data on the dedicated <a
href="#Aerospace_Ground_Equipment_AGE">AGE</a> data link.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Digit
magnitude weight 8<br>
</td>
<td style="vertical-align: middle;">See Digit magnitude weight
1<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> In<br>
</td>
<td style="text-align: left; vertical-align: middle;">Read
Manual Data Insertion Unit insert data<br>
</td>
<td style="vertical-align: middle;">Reads a keystroke that has
been buffered in the <a href="#yaMDIU_the_MDIU_Emulation">MDIU</a>.
This operation should be done only in response to a separate
discrete "Data ready" input via <span style="font-family:
courier new,courier,monospace;">CLD</span>. The BCD
value of the digit is stored into bits M1-M4 of the
accumulator. A <span style="font-family: courier
new,courier,monospace;">PRO40</span> should be performed
afterward to clear the MDIU buffer and allow the next
keystroke to be collected, and additional <span
style="font-family: courier new,courier,monospace;">PRO</span>
instructions should be used to display the digit on the
MDIU.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Reset
radar ready<br>
</td>
<td style="vertical-align: middle;">Sent to the <a
href="#Rendezvous_Radar">Rendezvous Radar</a>, if any, to
reset its discrete input buffer.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Roll
resolution<br>
</td>
<td style="vertical-align: middle;">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.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Elapsed
time control and Time Reference System control reset / ATM
wind-rewind reset<br>
</td>
<td style="vertical-align: middle;">Signal to the <a
href="#Time_Reference_System_TRS">Time Reference System</a>
(TRS) that the data about to be fetched from the TRS with <span
style="font-family: courier new,courier,monospace;">PRO20</span>
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.<br>
<br>
<span style="font-style: italic;">(Units with ATM only.)</span>
It has additional functionality for the <a
href="#Auxiliary_Tape_Memory_ATM">Auxiliary Tape Memory</a>
(ATM), in that it commands the ATM to stop winding or
rewinding. I believe that it also turns off the ATM
ERROR lamp. (I don't know how to select between the
TRS/ATM functions, or if it always performs both
simultaneously.)<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Computer malfunction<br>
</td>
<td style="vertical-align: middle;">To the <a href="#PCDP">PCDP</a>'s
MALF light.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM
verify/repro command<br>
</td>
<td style="vertical-align: middle;">Send a command to the <a
href="#Auxiliary_Tape_Memory_ATM">Auxiliary Tape Memory</a>
(ATM) to begin data output. I assume that the
accumulator is negative to begin the output and zero or
positive to end it.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> TBD<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Second
stage engine cutoff<br>
</td>
<td style="vertical-align: middle;">TBD<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Computer running<br>
</td>
<td style="vertical-align: middle;">To the <a href="#PCDP">PCDP</a>'s
COMP light.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;">
In?/Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Time to
start re-entry calculations control / ATM wind command<br>
</td>
<td style="vertical-align: middle;">The use for "time to start
re-entry calculations" is TBD.<br>
<br>
<span style="font-style: italic;">(Units with ATM only.)</span>
Initiates winding of the <a
href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>.
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 <a
href="#Auxiliary_Tape_Memory_ATM">PRO14</a>. (I
don't know how to select between the timing and ATM
functions, or if it always performs both simultaneously.)</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Time to
reset control / ATM rewind command<br>
</td>
<td style="vertical-align: middle;">Signal to the <a
href="#Time_Reference_System_TRS">Time Reference System</a>
(TRS) that transfer of time-to-equipment-reset (T<sub><small>X</small></sub>)
data is desired. This output should persist for 9-15
ms. before being returned to the normal state.<br>
<br>
<span style="font-style: italic;">(Units with ATM only.)</span>
Initiates rewinding of the <a
href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>.
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 <a
href="Gemini.html#Auxiliary_Tape_Memory_ATM">PRO14</a>.
(I don't know how to select between the TRS/ATM functions,
or if it always performs both simultaneously.)</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Write
output processor<br>
</td>
<td style="vertical-align: middle;">For incrementally
adjusting the delta-V displays of the <a href="#IVI">IVI</a>.
First, the X, Y, or Z display is selected (see "Select X
counter" above). No more than 1 ms. later, <span
style="font-family: courier new,courier,monospace;">PRO35</span>
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 (<span style="font-family:
courier new,courier,monospace;">CLD22</span>) can be
polled to determine when the increment/decrement pulses have
all been sent to the display and the counter has reached
zero.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle; color:
rgb(0, 0, 0);"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> In<br>
</td>
<td style="text-align: left; vertical-align: middle;">Read
delta velocity<br>
</td>
<td style="vertical-align: middle;"> This port is used to read
the change in velocity from the platform electronics, and to
zero the reference velocity for the next readings.<br>
<br>
A single <span style="font-family: courier
new,courier,monospace;">PRO45</span> instruction reads the
Δ<span style="font-style: italic;">V</span> 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:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family:
Courier New,Courier,monospace;">XXXXYYYYZZZZ00000000000000</span><br>
</div>
<br>
Even if correct, the units are TBD. </td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> TBD<br>
</td>
<td style="text-align: left; vertical-align: middle;">Input
processor time<br>
</td>
<td style="vertical-align: middle;">TBD<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Time to
retrofire control<br>
</td>
<td style="vertical-align: middle;">Signal to the <a
href="#Time_Reference_System_TRS">Time Reference System</a>
(TRS) that transfer of time-to-retrograde (T<sub><small>R</small></sub>)
data is desired. This output should persist for 9-15
ms. before being returned to the normal state.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle; color:
rgb(0, 0, 0);"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> In<br>
</td>
<td style="text-align: left; vertical-align: middle;">Read
pitch gimbal<br>
</td>
<td rowspan="3" style="vertical-align: middle;"> These ports
are used for reading gimbal angles from the inertial
platform. The units used are TBD, as the documents
discussing them speak only of phase-shifted 400 cps voltages
rather than true angles.<br>
<br>
15-bit values are provided, including the sign bit and the
14 most-significant bits. The 11 least-significant
bits are zeroed. Each of the <span
style="font-family: courier new,courier,monospace;">PRO</span>
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:<br>
<div style="margin-left: 40px;"><span style="font-family:
courier new,courier,monospace;">... at least 5 ms. from
last read of gimbals ...<br>
PRO36 # Must ignore the first value
received.<br>
... wait >= 5 ms. ...<br>
PRO46<br>
STO PITCH<br>
</span> <span style="font-family: courier
new,courier,monospace;">... wait >= 5 ms. ...<br>
</span> <span style="font-family: courier
new,courier,monospace;">PRO56<br>
STO ROLL<br>
</span> <span style="font-family: courier
new,courier,monospace;">... wait >= 5 ms. ...<br>
</span> <span style="font-family: courier
new,courier,monospace;">PRO36<br>
STO YAW<br>
# The total time must be <=30 ms.<br>
</span></div>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle; color:
rgb(0, 0, 0);"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> In<br>
</td>
<td style="text-align: left; vertical-align: middle;">Read
roll gimbal<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle; color:
rgb(0, 0, 0);"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> In<br>
</td>
<td style="text-align: left; vertical-align: middle;">Read yaw
gimbal<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Pitch
error command<br>
</td>
<td rowspan="3" style="vertical-align: middle;">For the
re-entry mode, the outputs are down-range error rather than
pitch error, and cross-range error rather than yaw error.<br>
<br>
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 <span
style="font-family: courier new,courier,monospace;">PRO02</span>,
<span style="font-family: courier new,courier,monospace;">PRO03</span>,
and <span style="font-family: courier
new,courier,monospace;">PRO04</span>.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Yaw
error command<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> Out<br>
</td>
<td style="text-align: left; vertical-align: middle;">Roll
error command<br>
</td>
</tr>
</tbody>
</table>
<h3><a name="Discrete_Inputs_For_CLD_Instruction"
id="Discrete_Inputs_For_CLD_Instruction"></a>Discrete Inputs
(For <span style="font-family: courier new,courier,monospace;">CLD</span>
Instruction)</h3>
Note that in assembly language, in the operand for a <span
style="font-family: courier new,courier,monospace;">CLD</span>
instruction, the Y operand field would proceed the X operand
field. So, for example, if X=3 and Y=4, the instruction would
be <span style="font-family: courier new,courier,monospace;">CLD 43</span>.
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.<br>
<br>
<table summary="" style="margin-left: auto; margin-right: auto;
text-align: left;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th colspan="2" rowspan="1" style="text-align: center;
vertical-align: middle;"> Operand<br>
</th>
<th colspan="1" rowspan="2" style="text-align: center;
vertical-align: bottom;"> Signal<br>
</th>
<th colspan="1" rowspan="2" style="text-align: center;
vertical-align: bottom;"> Comment<br>
</th>
</tr>
<tr>
<th style="text-align: center; vertical-align: middle;">X
(A1-A3)<br>
</th>
<th style="text-align: center; vertical-align: middle;">Y
(A4-A6)<br>
</th>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;">Radar
ready<br>
</td>
<td style="vertical-align: middle;">Indicates that data from
the <a href="#Rendezvous_Radar">Rendezvous Radar</a> (if
any) is ready.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Computer mode 2<br>
</td>
<td style="vertical-align: middle;"> From the <a href="#PCDP">PCDP</a>'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:<br>
<br>
<table summary="" style="margin-left: auto; margin-right:
auto; text-align: left;" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<th style="vertical-align: top; font-weight: bold;
text-align: center;"> Computer<br>
Mode 1<br>
</th>
<th style="vertical-align: top; font-weight: bold;
text-align: center;"> Computer<br>
Mode 2<br>
</th>
<th style="vertical-align: top; font-weight: bold;
text-align: center;"> Computer<br>
Mode 3<br>
</th>
<th style="font-weight: bold; vertical-align: bottom;
text-align: center;"> Mode<br>
</th>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> TBD<br>
</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> Pre-launch<br>
</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> Ascent<br>
</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> Catch-up<br>
</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> Rendezvous<br>
</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> Re-entry<br>
</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 0<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> TBD<br>
</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> 1<br>
</td>
<td style="vertical-align: middle; text-align:
center;"> TBD<br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Processor timing phase 1<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;">Data
ready<br>
</td>
<td style="vertical-align: middle;">From the <a
href="#yaMDIU_the_MDIU_Emulation">MDIU</a>. It
indicates that a digit-keystroke has been buffered within
the MDIU and is ready to be read.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Computer mode 1<br>
</td>
<td style="vertical-align: middle;">See "Computer mode 2".</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;">Start
computation<br>
</td>
<td style="vertical-align: middle;">From the <a href="#PCDP">PCDP</a>'s
START switch<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;">X zero
indication<br>
</td>
<td style="vertical-align: middle;">Indicates that the <a
href="#IVI">IVI</a>'s X-velocity display is at zero.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM
clock<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="#Auxiliary_Tape_Memory_ATM">ATM</a>
section.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Enter<br>
</td>
<td style="vertical-align: middle;">From ENTER key of <a
href="#yaMDIU_the_MDIU_Emulation">MDIU</a><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Instrumentation System sync<br>
</td>
<td style="vertical-align: middle;">From <a href="#Downlink">Instrumentation
System</a> (IS), to trigger beginning of a new downlink
cycle every 2.4 seconds.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Velocity error count not zero<br>
</td>
<td style="vertical-align: middle;">From the <a href="#IVI">IVI</a>.
It is an indicator that a prior "Write output processor" (<span
style="font-family: courier new,courier,monospace;">PRO35</span>)
has reached completion.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Aerospace Ground Equipment request<br>
</td>
<td style="vertical-align: middle;">From the <a
href="#Aerospace_Ground_Equipment_AGE">AGE</a>.
Becomes active (accumulator negative) when a word is
available on the dedicated AGE data link.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Readout<br>
</td>
<td style="vertical-align: middle;">From READ OUT key of <a
href="#yaMDIU_the_MDIU_Emulation">MDIU</a><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Computer mode 3<br>
</td>
<td style="vertical-align: middle;">See "Computer mode 2".</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM on<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>
section.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM data
channel 2<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>
section.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Clear<br>
</td>
<td style="vertical-align: middle;">From CLEAR key of <a
href="#yaMDIU_the_MDIU_Emulation">MDIU</a><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM mode
control 1<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>
section.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Simulation mode command<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM end
of tape<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>
section.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM data
channel 3<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>
section.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;">Time to
start re-entry calculations<br>
</td>
<td style="vertical-align: middle;">This is a signal from the
<a href="#Time_Reference_System_TRS">Time Reference System</a>
(TRS) that its T<sub>R</sub> (time to retrograde) counter
has reached zero.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM mode
control 2<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>
section.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;">Y zero
indication<br>
</td>
<td style="vertical-align: middle;">Indicates that the <a
href="Gemini.html#IVI">IVI</a>'s Y-velocity display is at
zero.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;">ATM data
1<br>
</td>
<td style="vertical-align: middle;"><span style="font-style:
italic;">(Units with ATM only. Otherwise, spare.)</span>
See the <a href="Gemini.html#Auxiliary_Tape_Memory_ATM">ATM</a>
section.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 5<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Digital
Command System ready<br>
</td>
<td style="vertical-align: middle;">This is a signal from the
<a href="#Uplink">Digital Command System</a> (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.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Fade-in
discrete<br>
</td>
<td style="vertical-align: middle;">From the <a href="#PCDP">PCDP</a>'s
FADE-IN. This is a signal from a relay, but anything
beyond that is TBD.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;">Z zero
indication<br>
</td>
<td style="vertical-align: middle;">Indicates that the <a
href="Gemini.html#IVI">IVI</a>'s Z-velocity display is at
zero.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Umbilical disconnect<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 0<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Instrumentation System request<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 1<br>
</td>
<td style="text-align: left; vertical-align: middle;">Abort
transfer<br>
</td>
<td style="vertical-align: middle;">From the <a href="#PCDP">PCDP</a>'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.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 2<br>
</td>
<td style="text-align: left; vertical-align: middle;">
Aerospace Ground Equipment input data<br>
</td>
<td style="vertical-align: middle;">Reads a single data bit on
the dedicated <a href="#Aerospace_Ground_Equipment_AGE">AGE</a>
data link.<br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 3<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;"> 7<br>
</td>
<td style="text-align: center; vertical-align: middle;"> 4<br>
</td>
<td style="text-align: left; vertical-align: middle;"> Spare<br>
</td>
<td style="vertical-align: middle;"><br>
</td>
</tr>
</tbody>
</table>
<h3><a name="Subroutine_Linkage" id="Subroutine_Linkage"></a>Subroutines</h3>
As weird as it may seem in modern terms, <span style="font-style:
italic;">the Gemini OBC CPU had no mechanism for easily
implementing subroutines</span>. Further, the
assembly-language source code for the OBC slavishly implemented what
is basically a state machine, using the separately designed "math
flow" as a pattern. Therefore <span style="font-style:
italic;">the OBC software developers had little need for
subroutines</span>. You may think I'm wrong about this, but
I've pursued this question with several OBC developers to an extent
they probably consider tiresome—fortunately, they've been very
patient!—and I think that this is an inescapable conclusion.
Therefore, while the OBC may have been a splendid mechanism for
developing state machines, it would have been very tiresome for
developing general-purpose software without any easy subroutine
mechanism.<br>
<br>
Now, there <span style="font-style: italic;">were</span> a few
subroutines, but they weren't created willy-nilly during development
as we often do today. Indeed, the full list (give or take a
few due to errors), including some explanation of how to set up the
inputs and retrieve the outputs of the subroutines, can be found in
the Gemini Programming Manual. In modern terms, we'd probably
think of these as library routines, but in Gemini they were the <span
style="font-style: italic;">only</span> subroutines. I'll
return to this topic of library routines at the end of the section.<br>
<br>
Naturally, since there were some subroutines, there had to be some
software workaround for the fact that the CPU itself didn't support
subroutines, and it seems to have been this:<br>
<ul>
<li>Before calling a subroutine such as SQROOT, the calling
program would load the accumulator with the HOP constant of the
location to which the subroutine was supposed to return, and
then HOP to the subroutine.</li>
<li>While we don't actually have any of the math subroutines to
look at, presumably the math subroutine would have to:</li>
<ul>
<li>Save the accumulator in a variable.</li>
<li>Do whatever computations it was supposed to do.</li>
<li>HOP to the saved return address.</li>
</ul>
</ul>
In terms of the native capabilities of the machine code, it's
actually very cumbersome to accomplish all of this, since it's
necessary to set up several HOP constants (one for the subroutine
entry point and one for each potential return address), each of
which has names that must be distinct from the names of the
subroutine and return points themselves. But you may have
noticed from the earlier descriptions of the <span
style="font-family: Courier New,Courier,monospace;">HOP</span>, <span
style="font-family: Courier New,Courier,monospace;">CLA</span>,
and <span style="font-family: Courier New,Courier,monospace;">STO</span>
instructions that the assembler implements a feature for them in
which left-hand symbols can be used as their operands (which would
otherwise be illegal), and the assembler simply automatically
creates HOP constants as necessary. Therefore, even though
what's going on behind the scenes is somewhat more complex, the
assembly language for the subroutine linkage as described above
simply looks like this:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family: Courier
New,Courier,monospace;">
CLA RETADR # Set up the
return address.<br>
HOP
SUBROU # HOP to the subroutine.<br>
RETADR ...
# Subroutine returns to here.<br>
...<br>
RSUBROU
# Variable to hold SUBROU's return
address.<br>
SUBROU STO RSUBROU # Enter
SUBROU, store return address.<br>
...
# Do stuff
inside of SUBROU.<br>
HOP
RSUBROU # Return from SUBROU.<br>
</span><br>
</div>
There are several HOP constants used here ("<span
style="font-family: Courier New,Courier,monospace;">(SUBROU)</span>"
and "<span style="font-family: Courier New,Courier,monospace;">(RETADR)</span>"),
but
the assembler creates them transparently, and the programmer doesn't
have to know about them unless he suddenly finds himself out of
memory. In this example, <span style="font-family: Courier
New,Courier,monospace;">RSUBROU</span> also holds a HOP constant,
but is nevertheless just a normal variable that hasn't been handled
in any special way by the assembler. (A construct like "<span
style="font-family: Courier New,Courier,monospace;">CLA *+2</span>"
seems like it would be useful here, since it would have eliminated
the need to explicitly define the symbol <span style="font-family:
Courier New,Courier,monospace;">RETADR</span>. But the OBC
developers haven't mentioned doing anything like that, so I haven't
bothered to implement it. This makes sense in light of the
Math Flow diagrams from which the code was created, because they
include the detail of setting up the return addresses. Hence
to conform to the Math Flow, the coders would have explicitly set up
the return addresses anyway.)<br>
<br>
I suppose I should make it clear that I'm not honestly sure that the
original OBC assembler worked in this way. But multiple OBC
developers have made it clear to me that this is the way they recall
handling subroutines, even though the explanation of why it was <span
style="font-style: italic;">legal</span> to do so (in light of the
contradictory machine-code characteristics) has been lost in the
ensuing decades. So I see little alternative to supposing that
the original assembler did indeed have a similar feature.<br>
<br>
Before leaving the subject of subroutines, let me just briefly
return to the list of existing subroutines on pages 21-24 the <a
href="Documents/GeminiProgrammingManual.pdf"> Gemini Programming
Manual</a> that I mentioned earlier. One of the most
important subroutines is <span style="font-family: Courier
New,Courier,monospace;">I/O</span>, which seems to be rather
mysterious and we're unfortunately told little about it; it appears
to be an exception in that no return address was supposed to be
supplied to it. The most complete information is available for
the subroutines listed on page 22 of the manual, since for those
routines there's actually some documentation about how to set up the
inputs and how to fetch the outputs of the subroutines. I've
collected a little additional information on some of those routines
not covered by the manual, and will present that info here just for
the sake of completeness:<br>
<ul>
<li><span style="font-family: Courier New,Courier,monospace;">ROOTSUM</span>
computed the square root of the squares of its two arguments.</li>
<li><span style="font-family: Courier New,Courier,monospace;">SQROOT</span>
seemingly accepted its input in the variable <span
style="font-family: Courier New,Courier,monospace;">ALPHA1</span>
and output the square root in variable <span
style="font-family: Courier New,Courier,monospace;">ALPHA3</span>.
The input variable <span style="font-family: Courier
New,Courier,monospace;">ALPHA2</span> was a first guess at the
result, to speed up the computation.<br>
</li>
<li><span style="font-family: Courier New,Courier,monospace;">SINCOS</span>,
listed in the manual as "SIN COS" is a single routine that
returns both the sine and cosine. The input was in units
of degrees.<br>
</li>
<li><span style="font-family: Courier New,Courier,monospace;">ATANGM</span>,
computed the arctangent, <span style="font-style: italic;">probably</span>
of the ratio <span style="font-family: Courier
New,Courier,monospace;">GAMMA1</span>/<span
style="font-family: Courier New,Courier,monospace;">GAMMA2</span>
of the input variables. The output is thought to be in
units of radians.<br>
</li>
<li>There was also a routine to compute the tangent, even though
it's missing from the tables.</li>
<li><span style="font-family: Courier New,Courier,monospace;">LOG</span>
is the base 10 logarithm.<br>
</li>
</ul>
Sadly, I'm not aware of what most of the other routines actually
did. Though not a subroutine as such, the code identified as
the "Executer" was very important and deserves some special
attention. Also known as <big><font><font size="2"
color="black"><big>the executive program (commonly called Hard
Core), it was assigned to sector 00 and contained
code common to all mode programs</big></font></font></big><big><font><font
size="2" color="black"><big> (Pre-Launch, Ascent, Catch-up,
Rendezvous, Re-entry)</big></font></font></big><big><font><font
size="2" color="black"><big>, such as:<br>
</big></font></font></big>
<ul>
<li><big><font><font size="2" color="black"><big>resetting
discrete outputs</big></font></font></big></li>
<li><big><font><font size="2" color="black"><big>reading time
programs</big></font></font></big></li>
<li><big><font><font size="2" color="black"><big>subroutines</big></font></font></big></li>
<li><big><font><font size="2" color="black"><big>timing programs</big></font></font></big></li>
<li><big><font><font size="2" color="black"><big>go-nogo-go
routine</big></font></font></big></li>
<li><big><font><font size="2" color="black"><big>setting computer
malfunction light</big></font></font></big></li>
<li><big><font><font size="2" color="black"><big>AGE routine</big></font></font></big></li>
<li><big><font><font size="2" color="black"><big>logic to jump to
the mode programs<br>
</big></font></font></big></li>
</ul>
<big><font><font size="2" color="black"><big>The Executer and
whatever mode program happened to be active functioned
somewhat like coroutines. After each pass through a
mode program, there was always a return to the beginning of
the executive program, where the discrete outputs were
set, time was read again, and so forth. After the
Executer pass, control was passed back to the mode program
again, and this process of cycling back and forth between
the Executor and the mode program continued.<br>
<br>
</big></font></font></big> There's also a little information
available on placement of some of these subroutines (and other
programs) in memory ... though, other than the Executer and MDIU
programs, I'm told that the placement of the various subprograms in
memory may not have been terribly important. As of early 1963,
prior to the ATM and in-flight swapping of programs in and out of
memory, the following is known about memory placement (thanks to
notes by Alden Minnick):<br>
<br>
<table summary="" style="text-align: left; margin-left: auto;
margin-right: auto;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="vertical-align: top; text-align: center;"> Program<br>
</th>
<th style="vertical-align: top; text-align: center;"> Starting
address<br>
</th>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">
Rendezvous<br>
</td>
<td style="vertical-align: top; text-align: center;"> 01-2-007
... but I've also been told 02-2-105, 01-2-105, 06-2-007,
03-2-306.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">Catch Up<br>
</td>
<td style="vertical-align: top; text-align: center;"> 01-2-105<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> Reentry<br>
</td>
<td style="vertical-align: top; text-align: center;"> 06-2-000<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">Sin Cos<br>
</td>
<td style="vertical-align: top; text-align: center;"> 05-2-000<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">Square
root, Arcsine<br>
</td>
<td style="vertical-align: top; text-align: center;"> 05-2-325
... but I've also been told 05-2-000<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> MDIU<br>
</td>
<td style="vertical-align: top; text-align: center;"> 11-0-060<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;">Ascent
Guidance<br>
</td>
<td style="vertical-align: top; text-align: center;"> 13-2-002<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> Executor<br>
</td>
<td style="vertical-align: top; text-align: center;"> 00-0-000<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> Standby<br>
</td>
<td style="vertical-align: top; text-align: center;"> 00-1-023<br>
</td>
</tr>
</tbody>
</table>
<br>
But I suspect these allocations changed a lot after that as, for
example, I'm also told that at some point the MDIU was assigned to
sector 17 (octal) rather than 11 (octal).<br>
<h3><a name="Telemetry" id="Telemetry"></a>Telemetry<br>
</h3>
<h4><a name="Uplink" id="Uplink"></a>Uplink<br>
</h4>
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:<br>
<ol>
<li>Poll <span style="font-family: courier
new,courier,monospace;">CLD06</span> at intervals of 50 ms. or
less to determine if data is ready.<br>
</li>
<li>When data is ready:</li>
<ol style="list-style-type: lower-alpha;">
<li><span style="font-family: courier new,courier,monospace;">PRO01</span>
to tell the enable the DCS to send the data.</li>
<li><span style="font-family: courier new,courier,monospace;">PRO00</span>
to fetch the 24-bit data word into the accumulator bits
M1-M24.<br>
</li>
</ol>
</ol>
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.<br>
<br>
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:<br>
<ul>
<li>Consecutive command words are transmitted to address 20
followed by address 21. </li>
<li>Rather than writing to either address 20 or 21, the two 18-bit
data fields are combined into a 36-bit structure.</li>
<li>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.<br>
</li>
<li>The 26-bit data is actually written to the 10-bit address, if
the 10-bit address was in the range 000-117 octal.</li>
</ul>
<h4><a name="Downlink" id="Downlink"></a>Downlink</h4>
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:<br>
<ol>
<li><span style="font-family: courier new,courier,monospace;">CLD07</span>
is polled at 50 ms. or less intervals. When it becomes
active (accumulator negative), the steps below are taken.</li>
<li><span style="font-family: courier new,courier,monospace;">CLD12</span>
is tested.</li>
<ul>
<li>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 <span
style="font-family: courier new,courier,monospace;">PRO10</span>
instruction.</li>
<li>If instead the accumulator positive or zero, then the
software should output the next buffer word in sequence using
a <span style="font-family: courier new,courier,monospace;">PRO10</span>
instruction.</li>
</ul>
</ol>
<h3><a name="Rendezvous_Radar" id="Rendezvous_Radar"></a>Rendezvous
Radar</h3>
For those spacecraft having a Rendezvous Radar, the following
procedure is used to fetch data from it:<br>
<ol>
<li><span style="font-family: courier new,courier,monospace;">PRO63</span>
is used to reset the radar's discrete input buffer.</li>
<li><span style="font-family: courier new,courier,monospace;">PRO01</span>
is used to tell the radar that the OBC wants data.</li>
<li>Wait 20 ms.</li>
<li>Test if data available using <span style="font-family:
courier new,courier,monospace;">CLD00</span>.</li>
<li>If data is ready (i.e., if accumulator is negative), perform a
code-sequence like the following:</li>
</ol>
<div style="margin-left: 80px;"><span style="font-family: courier
new,courier,monospace;">PRO00<br>
STO RANGE # 15 BITS<br>
PRO00<br>
STO SINAZI # SINE OF AZIMUTH, 10
BITS<br>
PRO00<br>
STO SINELEV # SINE OF ELEVATION, 10 BITS<br>
</span></div>
<br>
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.<br>
<h3><a name="Aerospace_Ground_Equipment_AGE"
id="Aerospace_Ground_Equipment_AGE"></a>Aerospace Ground
Equipment (AGE)</h3>
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:<br>
<ol>
<li>Poll <span style="font-family: courier
new,courier,monospace;">CLD32</span> until active (accumulator
negative).</li>
<li>Fetch an 18-bit word by repeating the following 18 times:</li>
<ol style="list-style-type: lower-alpha;">
<li><span style="font-family: courier new,courier,monospace;">PRO23</span>
with accumulator negative. (Starts a pulse on the AGE
data clock.)</li>
<li>Wait 2.5 ms.</li>
<li><span style="font-family: courier new,courier,monospace;">PRO23</span>
with accumulator positive or zero. (Ends the clock
pulse.)</li>
<li>Wait 1.5 ms.</li>
<li><span style="font-family: courier new,courier,monospace;">CLD27</span>.
(Reads
the data bit.)</li>
<li>Wait 1.5 ms.<br>
</li>
</ol>
</ol>
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:<br>
<br>
<table summary="" style="margin-left: auto; margin-right: auto;
text-align: left;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th colspan="4" rowspan="1" style="vertical-align: top;
text-align: center;">Mode Bits<br>
</th>
<th colspan="1" rowspan="2" style="vertical-align: bottom;
text-align: center;">Mode<br>
</th>
</tr>
<tr>
<th style="vertical-align: top; text-align: center;"> M4<br>
</th>
<th style="vertical-align: top; text-align: center;"> M3<br>
</th>
<th style="vertical-align: top; text-align: center;"> M2<br>
</th>
<th style="vertical-align: top; text-align: center;"> M1<br>
</th>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: left;"> None<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: bottom; text-align: left;">Read
words from memory. (See below.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: left;">Set
marginal early. The software should use <span
style="font-family: courier new,courier,monospace;">PRO60</span>
to enable the "marginal early" memory-accessing mode.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: left;">Set
computer malfunction on. The software should use <span
style="font-family: courier new,courier,monospace;">PRO34</span>
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 <a href="#PCDP">PCDP</a>.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: left;">Set
marginal late. The software should use <span
style="font-family: courier new,courier,monospace;">PRO60</span>
to disable the "marginal early" memory-accessing mode.</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: left;">Set pitch
ladder output. (See below.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: left;">Set yaw
ladder output. (See below.)</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: left;">Set roll
ladder output. (See below.)</td>
</tr>
<tr>
<td style="vertical-align: top; text-align: center;"> 1<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: center;"> 0<br>
</td>
<td style="vertical-align: top; text-align: left;">Set all
ladder outputs. (See below.)</td>
</tr>
</tbody>
</table>
<br>
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.<br>
<br>
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:<br>
<ol>
<li>Load the accumulator so that the bit to be sent is the sign
bit.</li>
<li><span style="font-family: courier new,courier,monospace;">PRO22</span>
to output the bit.</li>
<li>Wait 2.5 ms.</li>
<li><span style="font-family: courier new,courier,monospace;">PRO23</span>
with accumulator negative. (Start AGE data clock pulse.)</li>
<li>Wait 2 ms.</li>
<li><span style="font-family: courier new,courier,monospace;">PRO23</span>
with accumulator positive or zero. (End clock pulse.)</li>
<li>Wait 2 ms.</li>
<li><span style="font-family: courier new,courier,monospace;">PRO22</span>
with accumulator positive or zero. (Put AGE datalink line
back to its normal resting state.)</li>
<li>Wait 1 ms.</li>
</ol>
(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.)<br>
<br>
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.<br>
<h3><a name="Time_Reference_System_TRS"
id="Time_Reference_System_TRS"></a>Time Reference System (TRS)</h3>
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.<br>
<br>
The TRS can be accessed by the OBC in one of two modes:
"readout mode", which is activated by <span style="font-family:
Courier New,Courier,monospace;">PRO21</span> with the accumulator
negative, and "enter mode", which is activated by <span
style="font-family: Courier New,Courier,monospace;">PRO21</span>
with the accumulator positive or zero. In readout mode, the
elapsed time (ET), the time until retrograde (T<sub>R</sub>) or the
time until equipment reset (T<sub>X</sub>) is transferred from the
OBC to the TRS. In enter mode, the transfer is instead from
the TRS to the OBC. If T<sub>R</sub> reaches zero, then a
discrete from the TRS which can be read with <span
style="font-family: Courier New,Courier,monospace;">CLD05</span>
becomes active, and the software is generally expected to poll this
discrete so that it can know when to begin retrograde.<br>
<br>
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. <br>
<br>
In order to make sense of the procedures documented in the
familiarization manual, the <span style="font-family: Courier
New,Courier,monospace;">PRO21</span> instruction must have some
unusual behavior, such as the following:<br>
<ul>
<li>It places the accumulator's M25 bit onto the output line to
the TRS.</li>
<li>It places the signal from the input line from the TRS into the
accumulator's M1 bit.</li>
<li>It generates a clock pulse for the TRS.<br>
</li>
</ul>
<h4>Readout Mode</h4>
Here's how the OBC can write data to the TRS.<br>
<ol>
<li><span style="font-family: Courier New,Courier,monospace;">PRO21</span>
with accumulator negative to select readout mode.</li>
<li>Load the accumulator with 24-bit data for the TRS. The
data should be in accumulator bits M2-M25.</li>
<li>Repeat the following 24 times:</li>
<ol style="list-style-type: lower-alpha;">
<li><span style="font-family: Courier New,Courier,monospace;">PRO20</span>
to output accumulator's M1 to the TRS.</li>
<li><span style="font-family: Courier New,Courier,monospace;">SHR1</span>
to discard M1 from the accumulator and move the other
accumulator bits downward.</li>
</ol>
<li>With the accumulator negative use (only) one of <span
style="font-family: Courier New,Courier,monospace;">PRO14</span>,
<span style="font-family: Courier New,Courier,monospace;">PRO65</span>,
or <span style="font-family: Courier New,Courier,monospace;">PRO25</span>
to strobe the TRS transfer buffer into one its ET, T<sub>R</sub>,
or T<sub>X</sub> counter, respectively.</li>
<li>Delay 9-15 ms.</li>
<li>Use the same <span style="font-family: Courier
New,Courier,monospace;">PRO</span> instruction from step 4,
but with the accumulator zero or positive.<br>
</li>
</ol>
<h4>Enter Mode</h4>
Here's how the OBC can read data from the TRS.<br>
<ol>
<li><span style="font-family: Courier New,Courier,monospace;">PRO21</span>
with accumulator zero or positive to select enter mode.</li>
<li>With the accumulator negative use (only) one of <span
style="font-family: Courier New,Courier,monospace;">PRO14</span>,
<span style="font-family: Courier New,Courier,monospace;">PRO65</span>,
or <span style="font-family: Courier New,Courier,monospace;">PRO25</span>
to load the TRS ET, T<sub>R</sub>, or T<sub>X</sub> counter
value, respectively, into its transfer buffer.</li>
<li>Delay 9-15 ms.</li>
<li>Use the same <span style="font-family: Courier
New,Courier,monospace;">PRO</span> instruction from step 2,
but with the accumulator positive or zero.<br>
</li>
<li>25 repetitions of the following steps. (Yes, that's 25
repetitions, even though only 24 bits are involved.)<br>
</li>
<ol style="list-style-type: lower-alpha;">
<li><span style="font-family: Courier New,Courier,monospace;">PRO20</span>
to get the next bit from the TRS into the accumulator's M1
bit.<br>
</li>
<li><span style="font-family: Courier New,Courier,monospace;">SHR1</span>
to logically right-shift the accumulator by one place.<br>
</li>
</ol>
<li>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.<br>
</li>
</ol>
<h3><a name="Auxiliary_Tape_Memory_ATM"
id="Auxiliary_Tape_Memory_ATM"></a>Auxiliary Tape Memory (ATM)</h3>
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 <span style="font-weight: bold;">Auxiliary Tape Memory</span>
(ATM) and then transferred to the OBC. We are told by the <a
href="htDocuments/GeminiManualVol2Sec2.pdf#page=184">Gemini
Familiarization Manual</a> that<br>
<blockquote>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<tt>The Auxiliary Tape Memory (ATM) is a self-contained magnetic
tape recording system. It is used in spacecraft eight through
twelve to provide additional program storage for the digital
computer. It has a total storage capacity of over 85,000
thirteen-bit words. This is about seven that of the computer
core memory. The ATM is mounted on a cold plate in the adapter
section of the spacecraft ...</tt></blockquote>
From the Familiarization Manual's ATM specifications, we can figure
out about how long a program load from the ATM into the OBC must
have taken. With a total tape length of 525 feet and a
read/write speed of 1.5 inches/second, the total tape could be read
or written in 525×12/1.5 = 4200 seconds = 70 minutes. (If a
tape rewind were needed, the full operation would also require a
rewind at 8× speed, adding a maximum additional 8.75 minutes to the
total operation.) Since the tape has a 7× capacity relative to
the OBC core-memory capacity, any individual load, ignoring tape
wind/rewind, would then be about 70/7 = 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.<br>
<br>
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 I've already <a
href="#Evolution_of_the_Flight_Software">described them above</a>.<br>
<br>
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.<br>
<br>
<img style="width: 295px; height: 212px;" alt=""
src="GeminiPanelATM.png" width="295" height="212" align="right">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
interface works. <br>
<br>
Various of the <span style="font-family: Courier
New,Courier,monospace;">PRO</span>/<span style="font-family:
Courier New,Courier,monospace;">CLD</span> 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 <a href="Documents/Gemini12MissionReport.pdf">
Gemini XII Mission Report</a>. (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 <a href="#Aerospace_Ground_Equipment_AGE">Aerospace
Ground Equipment</a> (AGE), but only the STDBY, REWIND, WIND, and
PROG modes seem to have been useful during the mission. <br>
<ul>
<li>The position of the ATM mode switch can be read by combining
the two bits from <span style="font-family: Courier
New,Courier,monospace;">CLD14</span> and <span
style="font-family: Courier New,Courier,monospace;">CLD15</span>.
I
<span style="font-style: italic;">assume</span> that being in
STDY or not is what affects the repurposing of the <span
style="font-family: Courier New,Courier,monospace;">PRO</span>/<span
style="font-family: Courier New,Courier,monospace;">CLD</span>
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.<br>
</li>
<li>The ATM is commanded by the computer to wind (fast forward),
rewind, or to stop winding/rewinding with the <span
style="font-family: Courier New,Courier,monospace;">PRO15</span>,
<span style="font-family: Courier New,Courier,monospace;">PRO25</span>,
or <span style="font-family: Courier New,Courier,monospace;">PRO14</span>
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.<br>
</li>
<li>The ATM is commanded to verify/reprogram (i.e., to output
actual data or, I assume, to pause playback) with the <span
style="font-family: Courier New,Courier,monospace;">PRO44</span>
instruction.</li>
<li><span style="font-family: Courier New,Courier,monospace;">CLD33</span>
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.<br>
</li>
<li>When the ATM is outputting data, the data is provided in 3-bit
frames at a rate of 200 frames per second.</li>
<li>A new 3-bit data frame is ready to be used when <span
style="font-family: Courier New,Courier,monospace;">CLD41</span>
becomes active.</li>
<li>The 3-bit frame's data is retrieved using the commands <span
style="font-family: Courier New,Courier,monospace;">CLD44</span>,
<span style="font-family: Courier New,Courier,monospace;">CLD43</span>,
and <span style="font-family: Courier New,Courier,monospace;">CLD35</span>
to get the individual bits-positions of the frame.</li>
<li>The end or beginning of the tape is detected with <span
style="font-family: Courier New,Courier,monospace;">CLD34</span>.</li>
</ul>
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 <span style="font-family: Courier
New,Courier,monospace;">PRO14</span> will extinguish the lamp if
it is lit. <br>
<br>
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
extinguished if the beginning or end of the tape is reached.<br>
<br>
During an ATM search operation, the <a href="#IVI">IVI</a> 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.<br>
<br>
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.
<h2><a name="Gemini_Assembly_Language" id="Gemini_Assembly_Language"></a>OBC
Assembly Language</h2>
I've given a number of examples of OBC assembly-language above,
particularly where describing the various CPU instructions, but I'd
like to devote this section and its sub-sections to describing the
assembly language and its syntax a little more generally. I'll
try to describe the original language used by the OBC developers to
the extent possible, but since no documentation of the language or
the assembler other than the names of the instructions is known to
survive, nor any examples of OBC assembly-language contemporary to
Gemini, you can't assume that my description is completely
correct. <br>
<br>
On the other hand, my information has been gleaned from a lot of
communications with OBC developers, and by some rather extensive
modern (2011) recreations of sample code by OBC developers.
You can find the sample code here:<br>
<ul>
<li><a href="Documents/Alden.doc">Sample code by OBC programmer
Alden Minnick</a></li>
<li><a href="Documents/Charlie.doc">Sample code by OBC programmer
Charlie Leist</a></li>
</ul>
This sample code was produced with the intent of showing the coding
style that was employed, and was developed similarly to the way that
the original OBC code was developed: namely, by "slavishly"
duplicating the extremely detailed flowcharts known as the "math
flow". (I got the description "slavish" here from OBC
developer Don O'Neill, who was in charge of the assembler
program.) So I think that there's a pretty high degree of
authenticity. On the other hand, you have to recognize that
the sample code was developed 45 years after the end of Gemini, and
that Alden and Charlie had (at the time of creating the samples)
neither an assembler nor an OBC simulator, so you have to expect
that there's going to be some degree of inconsistency and
unavoidable error as well. Charlie has passed along the
following additional brief notes that he wrote while creating his
own code snippet that I think give a much fuller picture not merely
of the production of the sample code, but of the method by which the
original OBC software was produced ... not that all of the original
developers necessarily worked the same way, of course!<br>
<ul>
<li><a href="Documents/GeminiCharlieLeistRulesForCodeSnippets.pdf">
Some rules proposed prior to coding the samples</a>.</li>
<li><a href="Documents/GeminiCharlieLeistCodeSnippetMethod.pdf">
Explanation of the coding method</a>.</li>
<li><span style="font-style: italic;">Design diagrams</span>.
Charlie's sample code is supposed to be an implementation of
page 7 of the <a href="Documents/GeminiOBC-MathFlow-III.pdf">
1966 Catch-up & Rendezvous Math Flow</a>. This was
transformed into a <a
href="Documents/GeminiLeistSampleCodeFlowchart.png"> flowchart
more-directly related to OBC assembly language</a> and a <a
href="Documents/GeminiLeistSampleMemAssignments.pdf">
memory-allocation table</a> as a preliminary to actual coding.<br>
</li>
<li><a href="Documents/CharliesReview.txt">Code review of Alden's
code sample</a>.</li>
</ul>
Here also is a far briefer sample and explanation by Charlie of
coding a simple formula in OBC assembly language, slightly massaged
by me for typos:<br>
<br>
<table summary="" style="width: 80%; text-align: left; margin-left:
auto; margin-right: auto;" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td rowspan="1">
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span style="font-size:
10pt; font-family: Arial; color: black;">I will start
out with a simple equation like: Y=MX + B</span></font><font
size="2" color="black" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial; color:
black;">. Here goes:<br>
<br>
</span></font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span style="font-size:
10pt; font-family: Arial; color: black;">Let's assume
the numbers are small as that we won't have to do any
fixed point scaling.<br>
<br>
</span></font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span style="font-size:
10pt; font-family: Arial; color: black;">Let's define
B as a constant with the decimal value of +3. The 24
bit memory in binary word would be as. (0 00 000 000
000 000 000 000 011) There is no actual spaces between
the binary zeros - it makes it easier for me count the
bits and look at the sign bit! The sign bit was the
most significant bit while the the least significant
bit was the 1.<br>
<br>
</span></font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span style="font-size:
10pt; font-family: Arial; color: black;">Let's also
assume the program is in sector (00) - in octal
(zero). There were 16 sectors in octal that you could
program in. To change sectors you had to execute a HOP
instruction.<br>
<br>
</span></font></div>
<small><span style="font-family: Arial;">The first bit of
constant (+3) in memory is the sign bit of zero which
represents a positive number. A negative number would
have a 1 bit.<br>
<br>
</span></small>
<div style="font-family: Arial;"></div>
<div style="font-family: Arial;"><font size="2"
color="black"><span style="font-size: 10pt; color:
black;">The Gemini symbolic instructions on punch
cards fed in to the Assembler would look like this:<br>
<br>
</span></font></div>
<div style="margin-left: 40px; font-family: Courier
New,Courier,monospace;"><font size="2" color="black"><span
style="font-size: 10pt; color: black;">CLA X
Variable Comment</span></font></div>
<div style="margin-left: 40px; font-family: Courier
New,Courier,monospace;"><font size="2" color="black"><span
style="font-size: 10pt; color: black;">MPY
M Slope Comment</span></font></div>
<div style="margin-left: 40px; font-family: Courier
New,Courier,monospace;"><font size="2" color="black"><span
style="font-size: 10pt; color: black;">SPQ Temp1
Store the product in a memory location Temp1
comment</span></font></div>
<div style="margin-left: 40px; font-family: Courier
New,Courier,monospace;"><font size="2" color="black"><span
style="font-size: 10pt; color: black;">ADD
B Constant (+3)
comment</span></font></div>
<div style="font-family: Courier New,Courier,monospace;">
<div style="margin-left: 40px;"><font size="2"
color="black"><span style="font-size: 10pt; color:
black;">STO Y Store result in
Variable Y memory location</span></font></div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
To a certain extent, I have tried to get around some of the problem
of having no feedback for detecting coding errors by developing a <a
href="#yaOBCASM_the_OBC_Cross-Assembler">recreated version of the
OBC assembler, which I call <span style="font-weight: bold;">yaASM</span></a>,
and <a href="#yaOBC_the_OBC_CPU_Emulation">an OBC CPU emulator,
which I call <span style="font-weight: bold;">yaOBC</span></a>.
At this point, these programs are very much works in progress, and I
don't claim that they are fully debugged or even that they will run
on your computer. For this reason, they have not made their
way into the official Virtual AGC software source or binary
distribution. But for now you can download the cutting-edge
binaries from the <a href="#Downloads">temporary Gemini download
section</a> on this page.<br>
<br>
Finally, before starting, let me note that in contemplating the
original OBC assembly language, there was a small set of features
which (from a modern standpoint) seem to be absolutely necessary to
the language, but which don't seem to have existed originally;
perhaps they truly existed in some form but have simply been
forgotten over time. In those cases, I have taken the liberty
of adding those features to <span style="font-weight: bold;">yaASM</span>
and to the assembly-language syntax. In the description that
follows, <span style="color: rgb(153, 51, 0);">I have color coded
in this brown color any aspects of the language that seem to me to
be newly-added and not to have existed in this exact form in the
original OBC assembly language</span>.<br>
<h3><a name="General_format" id="General_format"></a>General format</h3>
The format of an individual line of code, corresponding to a single
punch-card from the point of view of the original OBC developers or
to a line of a source file from the current perspective, is<br>
<br>
<div style="text-align: center;"><span style="font-family: Courier
New,Courier,monospace;">LHS OPERATOR OPERAND COMMENT</span><br>
</div>
<br>
Note that these fields are not aligned on an particular column, and
are simply separated by white space of any kind. The total
number of characters in a line was originally limited to punch-card
length (80 characters), as the assembler did not allow for
continuation cards, <span style="color: rgb(153, 51, 0);">but the
current assembler extends that limit to 132 characters.
Moreover, since it's a little easier to compose source-code these
days (without having to use punch-cards), with newly-written code
I think it's nicer to align the columns attractively.</span><br>
<ul>
<li><span style="font-family: Courier New,Courier,monospace;">LHS</span>
an optional symbolic name for the memory address at which the
line of code or variable/constant allocation is located.
(The reason I call this "<span style="font-family: Courier
New,Courier,monospace;">LHS</span>" is that the OBC developers
referred to the symbolic name for a location holding a CPU
instruction as a "left-hand symbol". They didn't use that
term for names of variables or constants, though for the purpose
of describing syntax I'll symbolize all such things as <span
style="font-family: Courier New,Courier,monospace;">LHS</span>.)
<span style="font-family: Courier New,Courier,monospace;">LHS</span>
is limited to <span style="color: rgb(153, 51, 0);">8
characters or less</span>, and may contain any character which
is not white-space. I <span style="font-style: italic;">believe</span>
that the original OBC assembler accepted only up to 6
characters, and I further believe that the original OBC
developers conventionally used only upper-case characters and
digits. <span style="font-weight: bold; color: rgb(153,
51, 0);">yaASM</span><span style="color: rgb(153, 51, 0);">
also treats all words defined by the language itself (</span><span
style="color: rgb(153, 51, 0);">such as</span> <a
style="color: rgb(153, 51, 0);"
href="Gemini.html#CPU_Instructions">opcodes</a><span
style="color: rgb(153, 51, 0);">) as reserved, and doesn't
allow</span> <span style="font-family: Courier
New,Courier,monospace; color: rgb(153, 51, 0);"> LHS</span> <span
style="color: rgb(153, 51, 0);">to be a reserved word.</span></li>
<li><span style="font-family: Courier New,Courier,monospace;">OPERATOR</span>
is either an <a href="#CPU_Instructions">opcode</a> or else a <a
href="#Pseudo-ops">pseudo-op</a>.<br>
</li>
<li>Not all instructions have an <span style="font-family:
Courier New,Courier,monospace;">OPERAND</span>. Where
required, though, the nature of <span style="font-family:
Courier New,Courier,monospace;">OPERAND</span> differs by <span
style="font-family: Courier New,Courier,monospace;">OPERATOR</span>
type. The descriptions of the individual <span
style="font-family: Courier New,Courier,monospace;">OPERATOR</span>
types elsewhere on this page also list the allowed <span
style="font-family: Courier New,Courier,monospace;">OPERAND</span>
types for them.<br>
</li>
<li>The optional <span style="font-family: Courier
New,Courier,monospace;">COMMENT</span> is any string of
characters whatever. <span style="color: rgb(153, 51,
0);">It is unclear if the original assembler required the
comment to be preceded by any special character, and</span> <span
style="font-weight: bold; color: rgb(153, 51, 0);">yaASM</span><span
style="color: rgb(153, 51, 0);"> does not require it.
However, for convenience purposes,</span><span
style="font-weight: bold; color: rgb(153, 51, 0);">yaASM</span><span
style="color: rgb(153, 51, 0);"> does ignore any text from a
'#' character to the end of line, and following this
convention has the advantages both of allowing a full-line
comment and of allowing the assembler to detect certain syntax
errors that would otherwise be undetectable. In fact,
for</span> <span style="font-weight: bold; color: rgb(153,
51, 0);">yaASM </span><span style="color: rgb(153, 51, 0);">I
arbitrarily disallow comments in without leading '#' in
variable allocations since such comments would
indistinguishable from misspelled</span><span
style="font-family: Courier New,Courier,monospace; color:
rgb(153, 51, 0);"> OPERATOR</span><span style="color: rgb(153,
51, 0);">s. A full line containing only white-space is
also treated as a comment. The following additional
conventions related to comments are also useful, though not
enforced in any way:</span></li>
<ul style="color: rgb(153, 51, 0);">
<li>A comment made by the developer of the code should be
preceded by a single '#'.</li>
<li>A comment made by a downstream editor of the code (such as
the maintainer of this website) should be preceded by "##".</li>
</ul>
</ul>
The original OBC developers, I told, formatted the code for
submission to the assembler as follow:<br>
<ol>
<li>A list of all variables used, where a "variable" is the name a
memory location whose value can be changed at runtime. In
these lines, <span style="font-family: Courier
New,Courier,monospace;">LHS</span> is present but <span
style="font-family: Courier New,Courier,monospace;">OPERATOR</span>
and <span style="font-family: Courier New,Courier,monospace;">OPERAND</span>
are not. <span style="font-weight: bold; color: rgb(153,
51, 0);">yaASM </span><span style="color: rgb(153, 51, 0);">treats
such a line as an allocation for an uninitialized variable
named</span><span style="font-family: Courier
New,Courier,monospace; color: rgb(153, 51, 0);"> LHS</span><span
style="color: rgb(153, 51, 0);">, as the original OBC assembly
language doesn't seem to have had any other method of making
such an allocation.</span> I'm not sure, but I think
that lines of the form "<span style="font-family: Courier
New,Courier,monospace;">LHS SYN REFLHS COMMENT</span>" might
be included in this section.</li>
<li>A list of all constants used, where a "constant" is the name
of a memory location assigned a value at assembly-time.
They're not really "constant", though, since there's nothing to
stop the runtime program from changing the values later.
In modern terms, it's probably best to think of these as
allocations of initialized variables. To my understanding,
the OBC programmers used a naming convention in which if the
name of the constant began with 'K', the program was not
supposed to alter the value. (Interestingly, the original
assembler did not have a concept of a symbolic constant that was
used only at assembly time without corresponding to a memory
location. The pseudo-op <span style="font-family: Courier
New,Courier,monospace;">EQU</span> which would be used for
that purpose in many current assembly languages is, in fact,
used for something else.) In section, <span
style="font-family: Courier New,Courier,monospace;">OPERATOR</span>
is generally <span style="font-family: courier
new,courier,monospace;">DEC</span>, <span style="font-family:
courier new,courier,monospace;">OCT</span>, <span
style="font-family: Courier New,Courier,monospace;">EQU</span>,
<span style="color: rgb(153, 51, 0);">or</span> <span
style="font-family: Courier New,Courier,monospace; color:
rgb(153, 51, 0);"> HOPC</span>.<br>
</li>
<li>Instructions.</li>
</ol>
<span style="color: rgb(153, 51, 0);"><span style="color: rgb(0, 0,
0);">Curiously, I've been unable to ascertain how the original
assembler was told what areas of memory were to be used for
assembly of instructions or data. Perhaps each memory
region was assembled separately, along with job-control
directives giving the memory region, and all of the little
pre-assembled chunks were merged together later into a single
executable image. </span> At any rate, to overcome this</span><span
style="color: rgb(153, 51, 0);">, I've found it necessary to
invent my own syntax for such things. </span><span
style="color: rgb(153, 51, 0);">The following directives for that
purpose are completely new in</span> <span style="font-weight:
bold; color: rgb(153, 51, 0);">yaASM</span><span style="color:
rgb(153, 51, 0);"> and didn't exist in this form originally:</span><br
style="color: rgb(153, 51, 0);">
<br style="color: rgb(153, 51, 0);">
<table summary="" style="text-align: left; width: 100%; color:
rgb(153, 51, 0);" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="vertical-align: top;">Directive<br>
</th>
<th style="vertical-align: top;">Description<br>
</th>
</tr>
<tr>
<td style="vertical-align: top; font-family: Courier
New,Courier,monospace;"> HALF<br>
</td>
<td style="vertical-align: top;">Tells the assembler that the
half-word memory access mode is in effect in following block
of code. This remains in effect until a <span
style="font-family: Courier New,Courier,monospace;">NORM</span>
directive is encountered.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; font-family: Courier
New,Courier,monospace;"> NORM<br>
</td>
<td style="vertical-align: top;">Tells the assembler that the
normal memory access mode is in effect in following block of
code. This remains in effect unti a <span
style="font-family: Courier New,Courier,monospace;">HALF</span>
directive is encountered that overrides it.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; font-family: Courier
New,Courier,monospace; white-space: nowrap;"> CODE <span
style="font-style: italic;">M-PP-S-WWW</span><br>
</td>
<td style="vertical-align: top;">Tells the assembler that the
next instruction encountered should be assembled at address
<span style="font-style: italic; font-family: Courier
New,Courier,monospace;"> M-PP-S-WWW</span>, where <span
style="font-style: italic; font-family: Courier
New,Courier,monospace;"> M</span> is the module, <span
style="font-style: italic; font-family: Courier
New,Courier,monospace;"> PP</span> represents two octal
digits giving the memory sector, <span style="font-style:
italic; font-family: Courier New,Courier,monospace;"> S</span>
is the syllable, and <span style="font-style: italic;
font-family: Courier New,Courier,monospace;"> WWW</span>
represents three octal digits giving the word number.
The word number is incremented by the assembler on each
successive instruction encountered, but assumptions about
the selected sector and syllable are never changed until
another <span style="font-family: Courier
New,Courier,monospace;">CODE</span> directive is
encountered.<br>
<br>
The concept of a "module" (<span style="font-family: Courier
New,Courier,monospace; font-style: italic;">M</span>) is
completely different in Gemini OBC vs. Apollo LVDC, and yet
in some quirk of fate can be treated identically by the
assembler. In OBC, the program modules (I, II, III,
IV, V, and IV) can be loaded at runtime from the <a
href="#Auxiliary_Tape_Memory_ATM">Auxiliary Tape Memory</a>,
thus overlaying each other, although module I was intended
to always be present. In LVDC, in contrast, there were
up to 8 memory modules installed in the computer, each
equivalent to 2/3 of the total OBC memory, and there was no
ATM. But as far as the assembler is concerned, these
two very different types of "modules" can each be treated
simply as independent memory areas. To make the
handling consistent, <span style="font-weight: bold;">yaASM</span>
allows 8 modules numbered 0-7 for either case. For
OBC, module 0 corresponds to program module I, 1 corresponds
to II, and so on.<br>
<br>
The discussion that follows pertains solely to the Gemini
OBC.<br>
<br>
<span style="font-weight: bold;">yaASM</span> expects to
assemble a complete set of program modules as a single
operation, rather assembling the program modules separately
and merging them afterward ... which, I gather, was the
original procedure in Gemini itself. This makes it
easier for all program modules to be aware of the same set
of global variables. As a consequence of this feature,
however, <span style="font-weight: bold;">yaASM</span>
requires that program modules do <span style="font-style:
italic;">not</span> redefine left-hand symbols or
variable/constant names from one module to the next.
So (for example) if you had a variable named <span
style="font-family: Courier New,Courier,monospace;">X</span>
in module I, you couldn't define a different variable <span
style="font-family: Courier New,Courier,monospace;">X</span>
in module II, even though you could continue using <span
style="font-family: Courier New,Courier,monospace;">X</span>
from module I within module II, as long as module II hadn't
actually overlaid the portion of module I where <span
style="font-family: Courier New,Courier,monospace;">X</span>
was defined. <span style="font-weight: bold;">yaASM</span>
has no way of detecting runtime problems where code or data
are accessed that aren't actually loaded, so it is the
responsibility of the programmer to avoid it. <br>
<br>
One situation that may arise is that some memory location
may be used as a variable with two different interpretations
in two different modules, and therefore it's desirable to
assign two different symbolic names to it. For
example, we might desire a specific address to be the
variable <span style="font-family: Courier
New,Courier,monospace;">PHI</span> in module II and the
variable <span style="font-family: Courier
New,Courier,monospace;">EPSILON</span> in module
III. Using multiple names for the same address causes
no problems if module II and module III use the same region
of memory and hence don't coexist. In this case, the <span
style="font-family: Courier New,Courier,monospace;">SYN</span>
pseudo-op could be used to define <span style="font-family:
Courier New,Courier,monospace;">PHI</span> and <span
style="font-family: Courier New,Courier,monospace;">EPSILON</span>
as synonyms; module II would use only the symbol <span
style="font-family: Courier New,Courier,monospace;">PHI</span>
and module III would use only the symbol <span
style="font-family: Courier New,Courier,monospace;">EPSILON</span>.
The
same situation could occur with left-hand symbols as well;
for example, if there were two modules for the exact same
area of memory, and the entry points for both were at the
same address, then two different left-hand symbols would
refer to the same address but in two different
modules. But generally in this latter situation, the
left-hand symbols are all defined naturally just by
assembling the code, and therefore no explicit <span
style="font-family: Courier New,Courier,monospace;">SYN</span>
is needed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top; font-family: Courier
New,Courier,monospace; white-space: nowrap;"> DATA <span
style="font-style: italic;">M-PP-S-WWW</span><br>
</td>
<td style="vertical-align: top;">Tells the assembler that the
next variable or constant declaration encountered should be
assembled at address <span style="font-style: italic;
font-family: Courier New,Courier,monospace;"> M-PP-S-WWW</span>.
See the <span style="font-family: Courier
New,Courier,monospace;">CODE</span> directive for more
detail.<br>
</td>
</tr>
</tbody>
</table>
<br style="color: rgb(153, 51, 0);">
<span style="color: rgb(153, 51, 0);">These directives, with
whatever operands they may have, are expected to be placed on
lines by themselves, without any left-hand-symbol or
comment. However, any desired white-space can be added to
make them look pretty. Note that <span
style="font-family: Courier New,Courier,monospace;">CODE</span>
and <span style="font-family: Courier New,Courier,monospace;">DATA</span>
are completely separate and independent, so that they can
logically be use together or separately. I'd think that the
most normal usage, though, would be to issue both directives
together, like so:<br style="color: rgb(153, 51, 0);">
<br style="color: rgb(153, 51, 0);">
</span>
<div style="margin-left: 40px; color: rgb(153, 51, 0);"><span
style="font-family: Courier New,Courier,monospace;">CODE <span
style="font-style: italic;">M-PP</span>-2-000</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">DATA <span
style="font-style: italic;">M-PP</span>-0-000</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">... <span
style="font-style: italic;">all of the code, variables, and
constants for sector PP</span> ...</span><br>
</div>
<span style="color: rgb(153, 51, 0);"><br style="color: rgb(153, 51,
0);">
Because of the existence of these directives,</span> <span
style="font-weight: bold; color: rgb(153, 51, 0);">yaASM </span><span
style="color: rgb(153, 51, 0);">has no need to enforce the
original-OBC division into sections (VARIABLE/CONSTANT/CODE)
described earlier, and expects that variable- and
constant-specifications can be intermixed at random with
instructions. However, it is required that blocks of source
code be preceded by the appropriate directives <span
style="font-family: Courier New,Courier,monospace;">HALF/NORM/CODE/DATA</span>
describing the memory being used. It's very important to
understand that the directives only affect the assembler's
assumptions, but don't have any effect at runtime. While the
assembler can help to keep the assemble-time assumptions
consistent with the runtime conditions, it's still possible for
the programmer to fool the assembler and generate code that won't
actually execute. For example, for HOP constants generated with
HOPC, the runtime effect of a HOP will generally be consistent
with the assembler's assumptions about memory use; for HOP
constants generated instead by OCT, there's no such
expectation. It's ultimately up to the programmer to insure
consistency.</span><br style="color: rgb(153, 51, 0);">
<br style="color: rgb(153, 51, 0);">
<span style="color: rgb(153, 51, 0);">In order to allow relatively
clean organization of source code, <span style="font-weight:
bold;">yaASM</span> allows an OBC source file to include the
complete contents of another OBC source file within it by placing
the name, preceded by the character '$', by itself on a line, like
so:<br>
<br>
</span>
<div style="margin-left: 40px; color: rgb(153, 51, 0);"><span
style="font-family: Courier New,Courier,monospace;">...</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">$IncludeThisFile.obc</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">...</span><br>
</div>
<br style="color: rgb(153, 51, 0);">
<span style="color: rgb(153, 51, 0);">Multiple include-files can be
used in a single source file, and include-files can include other
files. This feature could be used, for example, to organize
a program in terms of pages in its math-flow diagram by putting
each page in a separate source file.</span> <br>
<h3><a name="Shorthands_for_some_instructions_"
id="Shorthands_for_some_instructions_"></a>Shorthands for some
instructions<br>
</h3>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="vertical-align: top; font-weight: bold;"> Shorthand<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
Description<br>
</th>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;
vertical-align: middle;"> SHR 1<br>
</td>
<td style="vertical-align: middle;">Same as an <span
style="font-family: courier new,courier,monospace;">SHF</span>
with X=1, Y=2.</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;
vertical-align: middle;"> SHR 2<br>
</td>
<td style="vertical-align: middle;">Same as an <span
style="font-family: courier new,courier,monospace;">SHF</span>
with X=0, Y=2.</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;
vertical-align: middle;"> SHL 1<br>
</td>
<td style="vertical-align: middle;">Same as an <span
style="font-family: courier new,courier,monospace;">SHF</span>
with Y=3. The value of X doesn't matter in this case,
but our assembler will use X=0.</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;
vertical-align: middle;"> SHL 2<br>
</td>
<td style="vertical-align: middle;">Same as an <span
style="font-family: courier new,courier,monospace;">SHF</span>
with Y=4. The value of X doesn't matter in this case,
but our assembler will use X=0.</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;
vertical-align: middle;"> NOP<br>
</td>
<td style="vertical-align: middle;">A no-operation instruction
that simply advances to the next instruction in
sequence. The assembler translates this to "<span
style="font-family: courier new,courier,monospace;">TRA
*+1</span>". The existence of <span
style="font-family: courier new,courier,monospace;">NOP</span>.</td>
</tr>
</tbody>
</table>
<br>
In discussions or in documentation you'll often see references to
things like "SHR1" or "PRO43" — in other words, to things that <span
style="font-style: italic;">look like</span> <span
style="font-family: Courier New,Courier,monospace;">SHR</span>, <span
style="font-family: Courier New,Courier,monospace;">SHL</span>, <span
style="font-family: Courier New,Courier,monospace;">SHF</span>, <span
style="font-family: Courier New,Courier,monospace;">PRO</span>, or
<span style="font-family: Courier New,Courier,monospace;">CLD</span>
instructions+operands, but without any space between the operator
and operand. Indeed, you'll find references like that on this
web page. <span style="color: rgb(153, 51, 0);">It remains
unclear to me whether the original OBC assembler accepted
constructs of this kind, but the</span> <span style="font-weight:
bold; color: rgb(153, 51, 0);">yaASM </span><span style="color:
rgb(153, 51, 0);">assembler does not:</span><span
style="font-weight: bold; color: rgb(153, 51, 0);"> yaASM</span><span
style="color: rgb(153, 51, 0);"> expects the instruction and
operand to be delimited by space(s) in all these cases.</span><span
style="color: rgb(153, 51, 0);"> Until/unless actual OBC
source code is found so that it can be fed into the assembler, the
point is (of course) not of overwhelming concern.</span><br>
<h3><a name="Pseudo-ops" id="Pseudo-ops"></a>Pseudo-ops</h3>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="vertical-align: top; font-weight: bold;"> Pseudo-op<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
Description<br>
</th>
<th style="vertical-align: top; font-weight: bold;"> Example<br>
</th>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;
vertical-align: middle;"> DEC<br>
</td>
<td style="vertical-align: middle;">Assembles a decimal
constant into memory. It can assemble either integer
values or else fractional values. The allowed range of
values is -33554432≤<i>Operand</i>≤+33554431. As with
all data, in normal mode the data was stored in syllables
0,1, while in half-word mode it was stored in syllable 2.<br>
<br>
If the literal decimal constant is an integer (i.e., if it
has no decimal point in it), then it is converted much as
you might expect: for example, a decimal 3 is stored as a
binary 11. <br>
<br>
But in converting fractional values in which the literal
decimal constant contains a decimal point, the value is
auto-scaled by whatever power-of-2 is required to make the
most-significant data bit (other than the sign) 1; in other
words, the value is left-shifted to maximally fill the range
-1.0<<span style="font-style: italic;">ScaledOperand</span><+1.0.
There
is no convention for storing values in memory with the
binary point at any location other than fully to the left or
fully to the right of all the bits; it's up to the
programmer to understand these conventions and explicitly
apply scaling to deal with it as the computation progresses.<br>
<br>
</td>
<td style="vertical-align: middle; font-family: courier
new,courier,monospace; white-space: nowrap;"><small>ANINT
DEC -12345678<br>
PI DEC 3.14159<br>
</small></td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;
vertical-align: middle;"> OCT<br>
</td>
<td style="vertical-align: middle;">Assembles an octal
constant into memory. Its operand is a set of octal
digits. The allowed range of values is 0 to
377777777. As with all data, in normal mode the data
was stored in syllables 0,1, while in half-word mode it was
stored in syllable 2. </td>
<td style="vertical-align: middle; font-family: courier
new,courier,monospace; white-space: nowrap;"><small>ANOCT
OCT 1234567<br>
</small></td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"><big><span
style="font-family: Courier New,Courier,monospace;">SYN</span><br>
</big></td>
<td style="vertical-align: top;">Creates a symbol referring to
the same memory address as a different symbol ... i.e.,
causes symbols to be synonyms for each other. This is
useful in cases where different programs which never run
simultaneously are sharing the same memory locations for
variable storage. Since the different programs would have
different interpretations for these same memory locations,
they'd naturally want to assign different symbolic names to
them. (I believe that the OBC programmers referred to such
variables as "timeshared" variables.) <span
style="color: rgb(153, 51, 0);">In</span> <span
style="font-weight: bold; color: rgb(153, 51, 0);">yaASM</span><span
style="color: rgb(153, 51, 0);">,</span><span
style="font-family: Courier New,Courier,monospace; color:
rgb(153, 51, 0);"> SYN</span> <span style="color:
rgb(153, 51, 0);">can be used to create a synonym for
instruction left-hand-symbols as well, though I'm not sure
if that feature was present in the original assembler or
would have had any use there.</span><br>
</td>
<td style="font-family: Courier New,Courier,monospace;"><small>A
SYN B<br>
</small></td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"><big>EQU<br>
</big></td>
<td style="vertical-align: top;">Creates a variable having the
same initial value as a different variable (presumably
created by <span style="font-family: Courier
New,Courier,monospace;">OCT</span> or <span
style="font-family: Courier New,Courier,monospace;">DEC</span>).
In
the example shown at right, two variables (<span
style="font-family: Courier New,Courier,monospace;">A</span>
and <span style="font-family: Courier
New,Courier,monospace;">B</span>) are allocated, each
having the same initial value of 21, but they're at two
different memory locations and may have different values
later in the program's execution.<br>
</td>
<td style="font-family: Courier New,Courier,monospace;"><small>A
DEC 21<br>
B EQU A<br>
</small></td>
</tr>
<tr>
<td style="color: rgb(153, 51, 0);"><span style="font-family:
Courier New,Courier,monospace;">HOPC</span><br>
</td>
<td style="vertical-align: top; color: rgb(153, 51, 0);">
Creates a HOP constant from an existing left-hand symbol for
an instruction. The constant is stored in the
currently-active <span style="font-family: Courier
New,Courier,monospace;">DATA</span> section at the
position where the <span style="font-family: Courier
New,Courier,monospace;">HOPC</span> pseudo-op is
encountered, but the constant itself is constructed using
the <span style="font-family: Courier
New,Courier,monospace;">CODE</span> and <span
style="font-family: Courier New,Courier,monospace;">HALF/NORM</span>
settings which exist at the location of the left-hand symbol
being targeted, which is exactly what's required to make the
constant usable. It's possible alternatively to create
a HOP constant manually using <span style="font-family:
Courier New,Courier,monospace;">OCT</span>, but it's
frankly difficult and error-prone to do so, and creates a
constant that's easily broken by future code changes.<br>
<br>
Because of the assembler's feature of implicitly creating
HOP constants when it finds code left-hand symbols used as
operands for <span style="font-family: Courier
New,Courier,monospace;">HOP</span>, <span
style="font-family: Courier New,Courier,monospace;">CLA</span>,
or <span style="font-family: Courier
New,Courier,monospace;">STO</span> instructions, it
actually turns out that there's little need to explicitly
use <span style="font-family: Courier
New,Courier,monospace;">HOPC</span> except in odd cases
which the assembler would handle implicit HOP constants
incorrectly, like half-word mode.<br>
</td>
<td style="color: rgb(153, 51, 0);"><small><span
style="font-family: Courier New,Courier,monospace;">HLAB
HOPC LAB</span><br style="font-family: Courier
New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">...</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">LAB
... code ...</span></small><br>
</td>
</tr>
</tbody>
</table>
<h3><a name="Software_Examples" id="Software_Examples"></a>Software
Examples</h3>
Above, you've seen various code snippets of OBC assembly-language
generated by me or original OBC developers in the absence of any OBC
programming manual or <span style="font-style: italic;">actual</span>
examples of OBC code contemporary to Gemini to work from. You
may also find the <a href="Pultorak_files/SGSCexample.pdf">short
programming example</a> created by John Pultorak
instructive. (In John's document, "SGSC" refers to a
Gemini-related project of his own, and not to anything that actually
existed in the true Gemini project.) Unfortunately, John is in
the same boat as I am, and is working without genuine code or code
samples.<br>
<br>
<h2><a name="Virtual_AGC_simulation_software"
id="Virtual_AGC_simulation_software"></a>Virtual AGC simulation
software</h2>
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. Some of the software discussed below exists,
but some of the description below is speculation about software that
I <span style="font-style: italic;">might</span> create in the
future, and how I might go about doing it. I apologise for
that. Nevertheless some significant software is available
already.<br>
<h3><a name="Downloads" id="Downloads"></a>Downloads</h3>
As mentioned earlier, I have created a new <a
href="Gemini.html#yaOBCASM_the_OBC_Cross-Assembler">version of the
OBC assembler, which I call <span style="font-weight: bold;">yaASM</span></a>,
and <a href="Gemini.html#yaOBC_the_OBC_CPU_Emulation">an OBC CPU
emulator, which I call <span style="font-weight: bold;">yaOBC</span></a>.
At this point, these programs are very much works in progress, and I
don't claim that they are fully debugged or even that they will run
on your computer. Therefore, they have not made their way into
the Virtual AGC software source or binary distribution as of
yet. But you can still download the source code for them from
our subversion repository, or you can download the binaries for
various platforms right here:<br>
<br>
<div style="text-align: center;"><span style="color: rgb(255, 0,
0);"><span style="font-style: italic;">Most recent update
builds: 2012-01-08</span></span><br>
</div>
<table summary="" style="text-align: left; width: 60%; margin-left:
auto; margin-right: auto;" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<th style="vertical-align: top;">Operating System<br>
</th>
<th style="vertical-align: top;">yaASM (Assembler)<br>
</th>
<th style="vertical-align: top;">yaOBC (Emulator)<br>
</th>
<th style="vertical-align: top;">Test source file<br>
</th>
</tr>
<tr>
<td style="vertical-align: top;">Linux 'x86<br>
</td>
<td style="vertical-align: top;"><a href="Downloads/yaASM">yaASM</a></td>
<td style="vertical-align: top;"><a href="Downloads/yaOBC">yaOBC</a><br>
</td>
<td style="vertical-align: top;"><a href="Downloads/Test.obc">Test.obc</a></td>
</tr>
<tr>
<td style="vertical-align: top;">Windows<br>
</td>
<td style="vertical-align: top;"><a href="Downloads/yaASM.exe">yaASM.exe</a></td>
<td style="vertical-align: top;"><a href="Downloads/yaOBC.exe">yaOBC.exe</a><br>
</td>
<td style="vertical-align: top;"><a href="Downloads/Test.obc">Test.obc</a></td>
</tr>
<tr>
<td style="vertical-align: top;">Mac OS X<br>
</td>
<td style="vertical-align: top;"><a
href="Downloads/yaASM-macosx">yaASM-macosx</a></td>
<td style="vertical-align: top;"><a
href="Downloads/yaOBC-macosx">yaOBC-macosx</a><br>
</td>
<td style="vertical-align: top;"><a href="Downloads/Test.obc">Test.obc</a></td>
</tr>
</tbody>
</table>
<br>
In brief, <span style="font-weight: bold;">yaASM</span> is a
command-line tool which:<br>
<ul>
<li>Reads OBC source code from a file</li>
<li>Creates a file called yaASM.bin to hold the assembled OBC
program executable</li>
<li>Outputs an assembly listing to the console, where you can pipe
it into a file<br>
</li>
</ul>
while <span style="font-weight: bold;">yaOBC</span> is a
command-line tool which:<br>
<ul>
<li>Reads the yaASM.bin OBC executable file created by <span
style="font-weight: bold;">yaASM</span></li>
<li>Reads the assembly listing created by <span
style="font-weight: bold;">yaASM</span></li>
<li>Emulates the behavior of the OBC CPU, so that the OBC program
can be executed<br>
</li>
</ul>
There's no nice setup program as of yet, so you have to do a few
manual steps to set up these programs before using them the first
time:<br>
<ol>
<li>Create an empty folder in some convenient place on your
computer.</li>
<li>Download the files specific to your computer type, and put
them in the folder you just created.</li>
<li>From a command-line, 'cd' to the folder.<br>
</li>
<li>On Linux or Mac OS X, you'll want to run the command "chmod +x
ya*" to make sure that the programs are marked as being
executable. (Since Windows has no security to speak of, it
will happily execute any file you download, so we don't have to
worry about this extra step.)<br>
</li>
<li>On Windows or Mac OS X, the download process may have renamed
your Test.obc file to Test.obc.txt. The instructions below
assume that the file is actually named Test.obc as I intended
it, so you might want to rename it back.<br>
</li>
</ol>
Having done these steps, the programs should be ready to run.
More-detailed explanations are available in the sections
specifically devoted to <span style="font-weight: bold;">yaASM</span>
and <span style="font-weight: bold;">yaOBC</span> below, but at its
most basic, here are the commands you'd use to assemble the test OBC
assembly-language source-code file, and then run the assembled
program in the emulator/debugger from the command-line in Windows:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family: Courier
New,Courier,monospace;">yaASM --input=Test.obc >Test.lst</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">yaOBC
--binary=yaASM.bin --symbols=Test.lst</span><br>
</div>
<br>
The commands above will present you with a debugger interface in
which you can do things like examine or modify OBC memory, set
breakpoints, run or single-step through the OBC test program,
etc. You can also view the assembly listing, Test.lst, in any
convenient text editor you happen to have handy, such as Notepad or
Wordpad.<br>
<br>
The steps are very slightly different if you're not using
Windows. On Linux, you'd have to replace <span
style="font-family: Courier New,Courier,monospace;">yaASM</span>
and <span style="font-family: Courier New,Courier,monospace;">yaOBC</span>
by <span style="font-family: Courier New,Courier,monospace;">./yaASM</span>
and <span style="font-family: Courier New,Courier,monospace;">./yaOBC</span>.
On
Mac OS X you'd have to replace them by <span style="font-family:
Courier New,Courier,monospace;">./yaASM-macosx</span> and <span
style="font-family: Courier New,Courier,monospace;">./yaOBC-macosx</span>.
But
otherwise, the programs should operate in exactly the same manner on
any of the platforms.<br>
<br>
By the way, I follow the convention that OBC source files have names
of the form *.obc, OBC executables have names of the form *.bin, and
OBC assembly-listings have names of the form *.lst. These
conventions are not enforced by <span style="font-weight: bold;">yaASM</span>
and <span style="font-weight: bold;">yaOBC</span>, though, and
you're free to do as you like.<br>
<br>
<h3><a name="The_Gemini_Catch-Up_and_Rendezvous"
id="The_Gemini_Catch-Up_and_Rendezvous"></a>The Gemini Catch-Up
and Rendezvous Simulation Program</h3>
<h4><a name="Background" id="Background"></a>Background<br>
</h4>
This is an <span style="font-style: italic;">actual existing
program</span> described in <a
href="Documents/GeminiCatchUpAndRendezvousAnalysisAndSimulationReport4.pdf">this
report</a>, 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!<br>
<br>
Although the report is dated slightly after the <a
href="http://en.wikipedia.org/wiki/Gemini_7">Gemini 7/6 mission</a>,
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. <br>
<br>
Gene comments, "<font style="color: rgb(0, 0, 0);" size="2"
color="navy" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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!)</span></font><span
style="color: rgb(0, 0, 0);">. </span> <font style="color:
rgb(0, 0, 0);" size="2" color="navy"
face="arial,helvetica,sansserif"><span style="font-size: 10pt;
font-family: Arial;">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.)</span></font>"<br>
<br>
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.<br>
<h4><a name="Source_Code" id="Source_Code"></a>Source Code</h4>
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/.<br>
<br>
The original program was really combined FORTRAN II and IBM
7090/7094 assembly-language. <span style="font-style:
italic;">Both</span> 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 <a
href="#Theory_of_Operation_for_the_Catch-Up_and">theory of
operation section</a> 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.<br>
<br>
In general, the following modifications have been made:<br>
<ul>
<li>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.</li>
<li>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).</li>
</ul>
<h4><a name="Building_the_Catch-Up_and_Rendezvous"
id="Building_the_Catch-Up_and_Rendezvous"></a>Building the
Catch-Up and Rendezvous Simulation Program</h4>
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:<br>
<br>
<div style="margin-left: 40px;"> cd
yaAGC/GeminiCatchUpandRendezvousProgram<br>
make<br>
</div>
<br>
This requires:<br>
<ul>
<li>GNU <span style="font-weight: bold;">make</span></li>
<li>GNU <span style="font-weight: bold;">gcc</span></li>
<li>GNU <span style="font-weight: bold;">gfortran</span></li>
<li>GNU <span style="font-weight: bold;">sed<br>
</span></li>
</ul>
Although the Makefile has provisions for using the earlier GNU <span
style="font-weight: bold;">g77</span> in place of <span
style="font-weight: bold;">gfortran</span>, but it's best not to
use it because I've found that with <span style="font-weight:
bold;">g77</span> 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. <span
style="font-weight: bold;">Note:</span> 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.<br>
<h4><a name="Running_the_Catch-Up_and_Rendezvous"
id="Running_the_Catch-Up_and_Rendezvous"></a>Running the
Catch-Up and Rendezvous Simulation Program</h4>
The batch-oriented simulation program, referred to in Report #4 as
the "static environment", is created as the executable named <span
style="font-weight: bold;">BENCH7</span>. The dynamic
simulation program, referred to in Report #4 as the "dynamic
environment", is created as <span style="font-weight: bold;">MAIN7</span>.
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.)<br>
<ul>
<li><span style="font-weight: bold;">BENCH7</span>: 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<<span style="font-style: italic;">Infile1</span>
6<<span style="font-style: italic;">Infile2</span> 9><span
style="font-style: italic;">Outfile</span>".<br>
</li>
<li><span style="font-weight: bold;">MAIN7</span>: 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<<span style="font-style: italic;">Infile</span> 9><span
style="font-style: italic;">Outfile1</span> 14><span
style="font-style: italic;">Outfile2</span>".</li>
</ul>
Both programs may also print some status messages on stderr, due to
my alterations rather than to any intention of the original
programmers.<br>
<h4><a name="Data_for_the_Catch-Up_and_Rendezvous"
id="Data_for_the_Catch-Up_and_Rendezvous"></a>Data for the
Catch-Up and Rendezvous Simulation Program</h4>
The input-data files needed to run the simulation program(s) are
described in Report #4. Actually generating such data is TBD.<br>
<br>
Gene's comments: "<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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.</span></font><font size="2"
face="arial,helvetica,sansserif"><span style="font-size: 10pt;
font-family: Arial;"> 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.</span></font>"<br>
<h4><a name="Theory_of_Operation_for_the_Catch-Up_and"
id="Theory_of_Operation_for_the_Catch-Up_and"></a>Theory of
Operation and Porting-Problems for the Catch-Up and Rendezvous
Simulation Program</h4>
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.<br>
<br>
TBD<br>
<h3><a name="yaOBC_the_OBC_CPU_Emulation"
id="yaOBC_the_OBC_CPU_Emulation"></a>yaOBC, the OBC CPU
Emulation</h3>
<h4><a name="Invoking_yaOBC_" id="Invoking_yaOBC_"></a>Invoking
yaOBC<br>
</h4>
<span style="font-weight: bold;">yaOBC</span> is a software-based
emulator for the OBC CPU. It is simply a command-line program
for Linux, Windows, or Mac OS X. It has no user-interface as
such, except for a debugger interface which can be used to perform
such operations as examining emulated memory, single-stepping
through instructions, setting breakpoints, and so on. However,
it can optionally be used to connect to other programs like <span
style="font-weight: bold;">yaPanel</span> <span
style="font-style: italic;">(not yet available!)</span> which do
provide a user interface; if not so connected, it simply uses the
CPU instructions <span style="font-family: Courier
New,Courier,monospace;">PRO</span> and <span style="font-family:
Courier New,Courier,monospace;">CLD</span> (which would otherwise
be used to communicate with peripheral devices) to read and write to
a dedicated memory area separate from the regular OBC memory, and
therefore remains usable for software debugging even without
peripheral devices.<br>
<br>
The command-line syntax for <span style="font-weight: bold;">yaOBC</span>
is as follows:<br>
<br>
<div style="text-align: center;"><big><span style="font-family:
monospace;">yaOBC [<span style="font-style: italic;">OPTIONS</span>]</span></big><br>
</div>
<br>
By default, <span style="font-weight: bold;">yaOBC</span> treats
OBC memory as persistent, and thus to have the same contents
whenever <span style="font-weight: bold;">yaOBC</span> starts as it
had on the last occasion <span style="font-weight: bold;">yaOBC</span>
stopped. It accomplishes this by means of an auxiliary file it
creates called yaOBC.bin, but in order to do this effectively
requires an orderly shutdown process by means of the debugging
interface it provides, in order to insure that yaOBC.bin is actually
saved. (More on this later.) However, if no such file as
yaOBC.bin exists, it instead requires a replacement file—generally
created by <span style="font-weight: bold;">yaASM</span>, since
both programs use the same file format—to be specified by means of
its <span style="font-style: italic;">OPTIONS</span>.<br>
<br>
The presently-accepted <span style="font-style: italic;">OPTIONS</span>
are:<br>
<br>
--help<br>
<div style="margin-left: 40px;"> Displays the available <span
style="font-style: italic;">OPTIONS</span> and exits.<br>
</div>
<br>
-v<br>
<div style="margin-left: 40px;"> Increases the verbosity of messages
displayed by <span style="font-weight: bold;">yaOBC</span>.
Multiple -v switches can be used. At present, the maximum
verbosity that has any observable effect is "-v -v -v -v -v -v".<br>
</div>
<br>
--lvdc<br>
<div style="margin-left: 40px;"> This switch causes the program to
emulate the Apollo LVDC computer. The default, when the
switch is missing, is the Gemini OBC is emulated.<br>
<br>
</div>
--binary=<span style="font-style: italic;">Filename</span><br>
<div style="margin-left: 40px;"> This specifies the name of a binary
file containing the complete contents of memory/ATM at startup,
along with the starting value of the HOP constant.
Typically, this file would be created by <span
style="font-weight: bold;">yaASM</span>, but it could be a
snapshot of the OBC system status created earlier by <span
style="font-weight: bold;">yaOBC</span> as well. If
present, it overrides the default yaOBC.bin file.<br>
</div>
<br>
--symbols=<span style="font-style: italic;">Filename</span><br>
<div style="margin-left: 40px;"> This is the name of a listing file
produced by <span style="font-weight: bold;">yaASM</span>.
If this option is used, then it gives <span style="font-weight:
bold;">yaOBC</span> knowledge of the source code and symbol
table associated with the OBC binary being used, and allows
symbolic debugging of the OBC program ... i.e., it allows memory
to be inspected or modified by variable/constant name rather than
just addresses, allows breakpoints to be put at left-hand symbols
rather than just addresses, allows source code to be displayed
when single-stepping or reaching a breakpoint (merely than being
disassembled from the contents of memory), and so on.<br>
</div>
<br>
--run<br>
<div style="margin-left: 40px;"> By default, <span
style="font-weight: bold;">yaOBC</span> starts in a paused state
at the starting HOP constant specified by the input binary
file. In other words, by default, no OBC instruction will be
executed until explicitly commanded via the debugging
interface. If the --run switch is used, it instead causes
OBC program execution to begin in real time without further
intervention.<br>
</div>
<br>
--ports=<span style="font-style: italic;">Port</span><br>
<div style="margin-left: 40px;"> Specifies the port number of a
network socket by which additional emulation programs such as <span
style="font-weight: bold;">yaPanel</span> can connect to the CPU
emulation and interact with it. By default, we use
"--port=19653" ... because the first Gemini mission was in March
1965 (in case you wondered). Because network sockets are
used, peripheral-emulating programs such as <span
style="font-weight: bold;">yaPanel</span> can reside on entirely
different computers from the one running <span
style="font-weight: bold;">yaOBC</span>, as long as there's a
network connection between them.<br>
</div>
<br>
--method=<span style="font-style: italic;">Peripheral</span>,<span
style="font-style: italic;">Driver</span><br>
<div style="margin-left: 40px;"> This switch relates to the method
by which emulated or physical peripheral devices connect to the
emulated CPU. In essence, it allows different types of device
drivers to be used for different <span style="font-style: italic;
font-family: Courier New,Courier,monospace;"> XY</span> ranges
for the <span style="font-family: Courier New,Courier,monospace;">PRO</span>
and <span style="font-family: Courier New,Courier,monospace;">CLD</span>
instructions of the CPU. The <span style="font-style:
italic;">Peripheral</span> field selects the <span
style="font-style: italic; font-family: Courier
New,Courier,monospace;"> XY</span> range by the designator of a
specific peripheral device, as follows:<br>
<ul>
<li><span style="font-style: italic;">Peripheral=</span>ALL
applies the Driver choice to the complete <span
style="font-style: italic; font-family: Courier
New,Courier,monospace;"> XY</span> range.</li>
<li><span style="font-style: italic;">Peripheral=</span>ACME</li>
<li><span style="font-style: italic;">Peripheral=</span>AGE</li>
<li><span style="font-style: italic;">Peripheral=</span>ATM</li>
<li><span style="font-style: italic;">Peripheral=</span>DCS</li>
<li><span style="font-style: italic;">Peripheral=</span>FDI</li>
<li><span style="font-style: italic;">Peripheral=</span>IMU</li>
<li><span style="font-style: italic;">Peripheral=</span>IS</li>
<li><span style="font-style: italic;">Peripheral=</span>IVI</li>
<li><span style="font-style: italic;">Peripheral=</span>MDIU</li>
<li><span style="font-style: italic;">Peripheral=</span>PCDP</li>
<li><span style="font-style: italic;">Peripheral=</span>RR</li>
<li><span style="font-style: italic;">Peripheral=</span>TRS</li>
</ul>
The <span style="font-style: italic;">Driver</span> field
specifies the the data-transport method for the <span
style="font-style: italic; font-family: Courier
New,Courier,monospace;"> XY</span> ranges associated with <span
style="font-style: italic;">Peripheral</span>, as follows:<br>
<ul>
<li>MEM, meaning that there is no emulated or physical
peripheral of type <span style="font-style: italic;">Peripheral</span>,
and so <span style="font-family: Courier
New,Courier,monospace;">PRO/CLD</span> are simply supposed
to read/write to a special memory buffer maintained by
yaOBC. This choice would typically be used when doing
pure debugging OBC software.</li>
<li>SOCK, meaning that a network socket (as with the --ports
switch described above) are used. This choice would be
used for emulated peripherals provided directly by the Virtual
AGC project, such as <span style="font-weight: bold;">yaPanel</span>.</li>
<li>COM1, COM2, etc., meaning that the RS232 port or
USB-to-RS232 converter converter designated as COM1, COM2,
etc., is used. (Note that these are designations used by
Windows and not by Linux or Mac OS X, so in those cases you
need to additionally use one or more of the --com1, --com2,
..., switches described below to link designations like COM<span
style="font-style: italic;">n</span> to an actual comport as
understood by those operating systems.) This choice
might be used (for example), if you had constructed a physical
simulation of an MDIU or IVI.</li>
<li>CUSTOM, meaning that a custom driver (of a type not
otherwise supported by Virtual AGC) is used. This choice
would be used if you were doing something I didn't know how to
help you with or had not otherwise envisaged. In
particular, I think this is the method that would be used to
interface yaOBC to the Orbiter spacecraft-simulation system.<br>
</li>
</ul>
</div>
<div style="margin-left: 40px;"> The default is
"--method=ALL,MEM". Note that regardless of the driver type,
all <span style="font-family: Courier New,Courier,monospace;">PRO/CLD</span>
ends up in the memory array, so all drivers ultimately build atop
the MEM driver.<br>
</div>
<br>
--io=<span style="font-style: italic;">Filename</span><br>
<div style="margin-left: 40px;"> When the MEM driver (see --method
above) is used, the dedicated memory area used for emulating the <span
style="font-family: Courier New,Courier,monospace;">PRO/CLD</span>
instructions defaults to being all zeroes at startup, or else is
populated with values from the preceding run of <span
style="font-weight: bold;">yaOBC</span>. It's possible
instead to load that area with different values using the --io
switch. <span style="font-style: italic;">Filename</span>
represents a simple ASCII file that can be created in any text
editor. The file has 128 lines, each of which is of the form
"PRO <span style="font-style: italic;">yx value</span>" or "CLD <span
style="font-style: italic;">yx value</span>". The first 64
lines are for <span style="font-family: Courier
New,Courier,monospace;">PRO</span> and the last 64 are for <span
style="font-family: Courier New,Courier,monospace;">CLD</span>.
Each of the two areas is in YX order: 00, 01, 02, ..., 77.
So while it may <span style="font-style: italic;">appear</span>
that you can rearrange the lines of the file however you like, you
actually cannot: the "PRO <span style="font-style: italic;">yx</span>"
and "CLD <span style="font-style: italic;">yx</span>" portions of
the lines are present simply to make it easier for you to know
which <span style="font-style: italic;">value</span> is which,
but cannot actually be changed and only the <span
style="font-style: italic;">value</span> fields should be
edited. The easiest way to get such a file to edit is to
start from the yaOBC.io file of a prior <span style="font-weight:
bold;">yaOBC</span> run, since such a file is automatically
created when <span style="font-weight: bold;">yaOBC</span> shuts
down. (This is the file which is loaded, if it exists, at <span
style="font-weight: bold;">yaOBC</span> startup unless
overridden by --io.) You can also manually create such a
file during a <span style="font-weight: bold;">yaOBC</span> run
via the COREDUMP command debugging interface as described below.<br>
</div>
<br>
--com1=<span style="font-style: italic;">ComportName</span>, --com2=<span
style="font-style: italic;">ComportName</span>, etc.<br>
<div style="margin-left: 40px;"> Optionally used with the --method
switch. The defaults are "--com<span style="font-style:
italic;">N</span>=COM<span style="font-style: italic;">N</span>",
but those defaults are meaningful only in Windows. On Linux,
the comport names are generally one of the following
instead: /dev/ttyS0, /dev/ttyS1, ..., /dev/ttyUSB0,
/dev/ttyUSB1, ..... So in Linux, you'd need switches like
"--com1=/dev/ttyS3", "--com2=/dev/ttyUSB1", and so forth,
depending on your setup. I don't know what they're typically
called in Mac OS X, but they'd be /dev/<span style="font-style:
italic;">something</span> as well.<br>
</div>
<br>
<h4><a name="Debugging_Interface_of_yaOBC"
id="Debugging_Interface_of_yaOBC"></a>Debugging Interface of
yaOBC</h4>
<h5>General Information About the yaOBC Debugger<br>
</h5>
The <span style="font-weight: bold;">yaOBC</span> debugging
interface is a method of controlling, examining, or altering the
emulation process at runtime by entering textual commands from a
command-line. The debugging interface is always present,
whether or not you choose to use it. By default, <span
style="font-weight: bold;">yaOBC</span> starts in a paused state,
so that the emulation won't even start unless you manually start it
with (for example), the debugger's RUN command; however, you can
override this behavior and start <span style="font-weight: bold;">yaOBC</span>
in a running state by using its "--run" command-line switch.
If you do the latter, and if there are physical or emulated
peripheral devices attached to the the CPU, you never need to use
the debugging interface at all. Conversely, if you have no
attached peripheral devices, you can never observe the behavior of
the emulation unless you use the debugger.<br>
<br>
At startup in a paused state, the <span style="font-weight: bold;">yaOBC</span>
command line will display something of this nature:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family: Courier
New,Courier,monospace;">HOP=000100000 (ADR=0-00-2-000 HWM=0
VAL=06400) ACC=000000000 PQ=000000000 (TMR:0)</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">Cycles=0
(0.00000 seconds)</span><br style="font-family: Courier
New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">0-00-2-000
START
CLA
KZERO
# Get 0 into accumulator</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">OBC
debugger paused></span><br>
<br>
</div>
It may not look exactly like this, but I'll describe some of what's
here just to give you the general idea. The first line shows
the values of various CPU registers:<br>
<ul>
<li>HOP register, in octal form. The HOP register is also
parsed into its constituent parts, namely the address ("0-<span
style="font-style: italic;">Sector-Syllable-Word</span>") and
half-word-mode bit. The leading "0-" is present, because
the debugger always includes the program module in the address,
but that field isn't present in the HOP register and hence will
always be 0. The "VAL" that's shown in the example above
is the 13-bit octal value stored in the memory location pointed
to by the HOP register. If that location happens never to
have been written to either by the assembler or the emulated
program, it will have the illegal value 77777.<br>
</li>
<li>Accumulator, in octal form.</li>
<li>PQ register, in octal form. The PQ register is used for
forming results of <span style="font-family: Courier
New,Courier,monospace;">MPY</span> and <span
style="font-family: Courier New,Courier,monospace;">DIV</span>
operations, and in the real OBC had the property that the
results weren't valid for several machine cycles after the
operation started. <span style="font-weight: bold;">yaOBC</span>
makes the result available immediately, but implements a small
countdown timer that is set to a non-zero value when the
multiplication or division commences and counts down by one for
every instruction thereafter until a value of 0 is
reached. In other words, while the results become
available immediately, they wouldn't have been valid in a real
OBC until the counter reaches 0. It's the value of that
counter that's shown as "TMR" above.</li>
</ul>
The second line shows the total number of instructions executed so
far, and the amount of real time those instructions would have
taken. Realize that <span style="font-weight: bold;">yaOBC</span>
cannot maintain the exact timing of 140 μsec. of the original OBC,
since even though the computer on which it is running is far, far
faster than the OBC, it is nevertheless not an embedded system and <span
style="font-weight: bold;">yaOBC</span> must share resources with
other software running on the computer. So <span
style="font-weight: bold;">yaOBC</span> merely tries to maintain
the same average instruction rate in a manner that's hopefully
transparent to the user. Under normal circumstances, the total
time listed by the debugger should correspond closely with the
actual real time consumed, except when the emulator is explicitly
commanded to run the emulation faster or slower than real time.<br>
<br>
The third line shows the source code of the line at which the
emulation is currently paused. This source line is taken from
the <span style="font-weight: bold;">yaASM</span> listing file,
where available, in which case it will be include left-hand symbols,
show the operand by name, and show comments. If the listing
file is not available, or the location is somehow absent from the
listing file, what will instead be shown is a disassembly of the
current location, which in the case of this example would be:<br>
<br>
<div style="margin-left: 40px;"><span style="font-family: Courier
New,Courier,monospace;">0-00-2-000
CLA 400</span></div>
<br>
Another interesting factoid about source-code lines is that since
the complete OBC software consists not only of program modules
loaded into main memory, but also program modules residing on the
ATM but not yet loaded, the source-code line associated with any
given address in memory is ambiguous: several different program
modules may use the same addresses for different purposes and
associate different source code with them. Unfortunately, the
debugger has no way of knowing which program modules are loaded or
are associated with which addresses. So it tries to match the
value stored at the address with the value that each of the program
modules think should be stored at that address, and then displays
the first source-code line that actually matches. But this
method can still be wrong and the wrong source-code line could be
displayed sometimes. The address printed with the source line
will show the module which the debugger thinks the source line is
from (for example "1-00-2-000") even though the code is actually
being run from main memory ("0-00-2-000") rather than from the ATM
directly.<br>
<br>
Finally, the fourth line is the debugger's prompt, and which is
where commands you input would appear. If <span
style="font-weight: bold;">yaOBC</span> starting in a running
state instead of a paused state, you'd have <span
style="font-style: italic;">only</span> this prompt, and wouldn't
have any of the other three lines. (By the way, any user input
to the debugger discards anything from an '#' character to the
end of the line. This isn't of much interest under normal
circumstances, but can be useful if input is piped into the debugger
from the command line from a prewritten script, since it allows the
addition of comments to such scripts.)<br>
<br>
When the emulation is in a running state, <span style="font-style:
italic;">any</span> command (legal or illegal, or even just
hitting the Enter key) at the debugger prompt will pause the
emulation. The emulation remains paused until commanded
otherwise.<br>
<h5>Commands Recognised by the yaOBC Debugger<br>
</h5>
The commands which can be entered at the prompt are the
following. Items in brackets (like so: [<span
style="font-style: italic;">Stuff</span>]) are optional. The
commands themselves are not case-sensitive.<br>
<ul>
<li>HELP or MENU or ? — display a list of available commands.</li>
<li>QUIT or EXIT — exits <span style="font-weight: bold;">yaOBC</span>,
saving the current state so that the emulation can be resumed
from where it stopped if <span style="font-weight: bold;">yaOBC</span>
is run again later. Resuming the emulation exactly is
really only feasible if using the MEM driver (see --method
switch above) for peripherals, because a physical or emulated
peripheral will have its own internal state not necessarily
accessible or controllable by <span style="font-weight: bold;">yaOBC</span>.<br>
</li>
<li>RUN or CONT or R — stop pausing and begin running the
program. The program will then run until encountering one
of the following conditions, in which case the emulation will
again pause:</li>
<ul>
<li>Reaching an instruction having a breakpoint</li>
<li>Modifying a memory location having a watchpoint</li>
<li>Encountering an illegal runtime condition such as executing
past the end of memory</li>
<li>Detecting user input from the debugger prompt</li>
</ul>
<li>STEP [<span style="font-style: italic;">N</span>] or NEXT [<span
style="font-style: italic;">N</span>] or S [<span
style="font-style: italic;">N</span>] or N [<span
style="font-style: italic;">N</span>] — executes the next <span
style="font-style: italic;">N</span> assembly-language
instructions. If <span style="font-style: italic;">N</span>
is omitted, then it defaults to 1. As a convenience, if
the <span style="font-style: italic;">previous</span> command
was STEP/NEXT/S/N, then simply hitting the Enter key without
inputting any command at all will do a "NEXT 1", so you can
simply advance through the program step-by-step by repeatedly
hitting the Enter key. The Enter key by itself has no
effect if the previous command was something other than
STEP/NEXT/S/N.<br>
</li>
<li>BREAK <span style="font-style: italic;">Location</span> — set
a breakpoint at a memory location, CPU register, or PRO/CLD <span
style="font-style: italic;">YX</span>. <a
href="#Location-Field_Parsing_by_the_Debugger">See the section
below on parsing the <span style="font-style: italic;">Location</span>
field</a>. Notice that a breakpoint can be set not only at an
instruction, but also at locations containing data (thus
corresponding to what some debuggers call a "watchpoint").
The behavior of a breakpoint is that it pauses emulation
whenever the debugger detects one of the following two
conditions:</li>
<ul>
<li>The next instruction to be executed would come from a
location marked with a breakpoint; or</li>
<li>The next instruction would access a data-location marked
with a breakpoint. The exact meaning of "access" depends
on the global WATCHMODE setting (see below). </li>
</ul>
<li>WATCHMODE <span style="font-style: italic;">Mode</span> —
This global setting determines what kinds of accesses of a data
location trigger a break. The behavior of breakpoints for
code locations is not affected. The choices for <span
style="font-style: italic;">Mode</span> are:</li>
<ul>
<li>ANY — Trying either to read or write the data
location with the breakpoint triggers a break.</li>
<li>WRITE — Trying to write the data location with the
breakpoint triggers a break.</li>
<li>CHANGE — (Default) Trying to <span style="font-style:
italic;">change</span> the value stored at the data location
triggers a break. For example, writing 0 to a location
already containing 0 would not trigger a break, but changing
it to 1 would. This concept only applies to memory; for
breakpoints on registers or PRO<span style="font-style:
italic;">YX</span> or CLD<span style="font-style: italic;">YX</span>,
<span style="font-style: italic;">Mode</span>=WRITE is used
even if CHANGE is selected.<br>
</li>
</ul>
<li>BREAKPOINTS — display all currently-defined breakpoints.<br>
</li>
<li>DELETE [<span style="font-style: italic;">Location</span>] —
delete the breakpoint from the designated <span
style="font-style: italic;">Location</span>, or delete all
watchpoints and breakpoints if no <span style="font-style:
italic;">Location</span> is specified. <a
href="Gemini.html#Location-Field_Parsing_by_the_Debugger">See
the section below on parsing the <span style="font-style:
italic;">Location</span> field</a>.</li>
<li>PRINT <span style="font-style: italic;">Location</span> —
displays the value stored at <span style="font-style: italic;">Location</span>.
<a href="Gemini.html#Location-Field_Parsing_by_the_Debugger">See
the section below on parsing the <span style="font-style:
italic;">Location</span> field</a>. Note that program
modules on the ATM but not loaded into memory can be accessed by
this method. <a
href="#Treatment_of_Program_Modules_by_the">See the section
below on program modules</a>.<br>
</li>
<li>EDIT <span style="font-style: italic;">Location Value</span>
— modifies the value stored at <span style="font-style:
italic;">Location</span>. <a
href="Gemini.html#Location-Field_Parsing_by_the_Debugger">See
the section below on parsing the <span style="font-style:
italic;">Location</span> field</a>. Note that program
modules on the ATM but not loaded into memory can be accessed by
this method. <a
href="Gemini.html#Treatment_of_Program_Modules_by_the">See the
section below on program modules</a>. Note also that this
command does little or no consistency checking, so you can
easily cause memory locations to be loaded with values that make
no sense contextually at all, such as loading the HOP register
from a variable. <span style="font-style: italic;">Value</span>
is one of the following:</li>
<ul>
<li>An octal number if it has a leading 0 and consists entirely
of octal digits.</li>
<li>A decimal number if it consists entirely of decimal digits,
an optional decimal point, and optional leading plus- or
minus-sign. Also:</li>
<ul>
<li>If there is no decimal point, then the value is treated as
an integer and is stored as-is.</li>
<li>If there is a decimal point, then the value is scaled to
have absolute value less than 1.0 but to retain the maximum
possible number of significant bits—i.e., so that the
most-significant bit other than the sign bit is 1 unless the
value is exactly 0.</li>
</ul>
<li>An existing left-hand symbol, in which case the value is
assembled as a HOP constant formed from that left-hand symbol.</li>
<li>An existing variable-name or constant-name, in which case
the value is <span style="font-style: italic;">the value
stored in that variable or constant</span>.</li>
<li>An address of the form "<span style="font-style: italic;">Module-Sector-Syllable-Word</span>",
in which case a HOP constant is formed with the half-word mode
flag reset to 0. (The value of <span style="font-style:
italic;">Module</span> is ignored, since the OBC HOP
constant has no field associated with it.)</li>
<li>An address of the form "H-<span style="font-style: italic;">Module-Sector-Syllable-Word</span>",
in which case a HOP constant is formed with the half-word mode
flag set to 1.<br>
</li>
</ul>
<li>COREDUMP <span style="font-style: italic;">Filename</span> [<span
style="font-style: italic;">IoFilename</span>] — creates a
snapshot file of the OBC into the file <span style="font-style:
italic;">Filename</span>. The snapshot contains all
memory and CPU registers. These snapshot files can be
loaded into yaOBC at startup via the --binary command-line
switch. Optionally, if <span style="font-style: italic;">IoFilename</span>
is present, the dedicated memory areas which the MEM driver (see
the --method switch) uses to emulate the <span
style="font-family: Courier New,Courier,monospace;">PRO/CLD</span>
instructions will be written out as well, and can be reloaded
into yaOBC later with the --io command-line switch.
However, this will have little or no effect in recreating the
states of the peripheral devices if drivers other than MEM are
used.</li>
<li>ATM <span style="font-style: italic;">Module</span> — Loads a
given program module from ATM into memory. Only values in
the range 1-7 are sensible. <a
href="#Treatment_of_Program_Modules_by_the">See the
program-modules section below</a>. What this command
does is to overwrite all of main memory, but only for those
addresses in which the selected <span style="font-style:
italic;">Module</span> has an initialized value —i.e., an
instruction or a constant. Variables and unused memory
locations are not initialized by the assembler, so any contents
of main memory at such locations remain intact. Other than
ignoring uninitialized locations, there is no provision for
loading subsets (such as restricted address ranges) from <span
style="font-style: italic;">Module</span> into main memory.<br>
</li>
</ul>
Notice that while no way is provided to directly do something like
jump to a given location and begin executing there, you can
indirectly achieve that by doing things such as "EDIT HOP <span
style="font-style: italic;">ExistingLeftHandSymbol</span>" and
then "RUN".<br>
<h5><a name="Treatment_of_Program_Modules_by_the"
id="Treatment_of_Program_Modules_by_the"></a>Treatment of
Program Modules by the Debugger</h5>
The assembler, <span style="font-weight: bold;">yaASM</span>,
expects to assemble a complete set of program modules as a single
operation, and hence the binary file loaded by <span
style="font-weight: bold;">yaOBC</span> contains not only the
contents of main memory but also the contents of all program modules
on the ATM but not yet loaded into main memory. This is why
the debugger treats full addresses as being of the form "<span
style="font-style: italic;">Module-Sector-Syllable-Word</span>".
A
numbering system is used in which <span style="font-style: italic;">Module</span>=0
corresponds to Program Module I, <span style="font-style: italic;">Module</span>=1
corresponds to Program Module II, and so on.<br>
<br>
However, this idealized numbering scheme pertains only to the
situation immediately after assembly and before any ATM modules have
been loaded into main memory, because the debugger really interprets
<span style="font-style: italic;">Module</span>=0 as being "the
contents of main memory" and not merely as Program Module I.
Therefore, as time progresses and various program modules are loaded
from ATM into main memory, <span style="font-style: italic;">Module</span>=0
becomes a mashup of not only Program Module I, but also a lot of
other program modules as well. However, <span
style="font-style: italic;">Module</span>=1-7 will always continue
to be the pure contents of ATM.<br>
<h5><a name="Location-Field_Parsing_by_the_Debugger"
id="Location-Field_Parsing_by_the_Debugger"></a><span
style="font-style: italic;">Location</span>-Field Parsing by the
Debugger</h5>
Several of the debugger's commands (BREAK, DELETE, PRINT, EDIT) have
a <span style="font-style: italic;">Location</span> field that
represents a location at which an operation is supposed to be
performed. For simplicity, the debugger uses the same parser
for this field in all cases, whether or not all possibilities
necessarily make sense for all commands. The <span
style="font-style: italic;">Location</span> field can be any of
the following:<br>
<ul>
<li>An existing left-hand symbol.</li>
<li>An existing constant's name.</li>
<li>An existing variable's name.</li>
<li>An address of the form "<span style="font-style: italic;">Module-Sector-Syllable-Word</span>",
with all fields being octal numbers, <span style="font-style:
italic;">accesses a 13-bit value</span> at the specified
address. <span style="font-style: italic;">Module</span>
is in the range 0-7, <span style="font-style: italic;">Sector</span>
is in range 0-17 octal, <span style="font-style: italic;">Syllable</span>
is in the range 0-2, and <span style="font-style: italic;">Word</span>
is in the range 0-377 octal. See the <a
href="#Treatment_of_Program_Modules_by_the">section on program
modules above</a> for more info on <span style="font-style:
italic;">Module</span>. <br>
</li>
<li>An address of the form "D-<span style="font-style: italic;">Module-Sector-</span>0<span
style="font-style: italic;">-Word"</span> is used to access a
26-bit value in <span style="font-style: italic;">Syllable</span>
0.<span style="font-style: italic;"><br>
</span></li>
<li>"HOP", for the HOP register.</li>
<li>"ACC", for the Accumulator register.</li>
<li>"PQ", for the PQ register.</li>
<li>"PRO<span style="font-style: italic;">YX</span>", where <span
style="font-style: italic;">YX</span> is a 2-digit octal
number. This is meaningful only for the MEM driver of the
<span style="font-weight: bold;">yaOBC</span> "--method"
command-line switch.<br>
</li>
<li>"CLD<span style="font-style: italic;">YX</span>", where <span
style="font-style: italic;">YX</span> is a 2-digit octal
number. This is meaningful only for the MEM driver of the
<span style="font-weight: bold;">yaOBC</span> "--method"
command-line switch.</li>
</ul>
<h4><a name="Protocol" id="Protocol"></a>Communications Protocol for
yaOBC</h4>
If, perchance, you are familiar with the socket protocol use for
Apollo-related software provided by the VirtualAGC project, such as
<span style="font-weight: bold;">yaAGC</span>, <span
style="font-weight: bold;">yaAGS</span>, <span
style="font-weight: bold;">yaDSKY</span>, etc., you'll find the
protocol and external tools used for the Gemini-related software
very different. There's no particular reason for this, other
than present convenience for me, though the new method does have
some points in its favor as compared to the old. <br>
<br>
As mentioned above, <span style="font-weight: bold;">yaOBC</span>
supports both network sockets or comports (RS-232, USB) for
connecting the emulated CPU to emulated or physical
peripherals. The protocol I envisage is basically the same in
either case, and is as follows:<br>
<ul>
<li>Messages are 7-bit ASCII text.</li>
<ul>
<li>For comports, messages are delimited by a line-feed (LF) or
carriage-return (CR) character, and empty messages are
discarded. Therefore, software can terminate messages
using newline characters from any of the major computing
platforms (CR-LF for Windows, CR for Mac, LF for Linux/UNIX)
without affecting the interpretation of the message by its
receiver. <span style="font-style: italic;">(If anyone
was really going to use this for comports, it might be
worthwhile to add CRC to the ends of the messages. I'm
not going to worry about this for now, since at the moment I
visualize it as extra complexity for a usage case that's not
terribly likely.)</span><br>
</li>
<li>For sockets, messages are interchanged via <a
href="http://enet.bespin.org/index.html">the cross-platform
<span style="font-weight: bold;">enet</span> library</a>,
and are "packets" as understood by that library. CR or LF
terminations are not expected to be present within the
messages. In this situation, the CPU emulator <span
style="font-weight: bold;">yaOBC</span> acts as an <span
style="font-weight: bold;">enet</span> server listening on
the port defined by its command line switches (defaulting to
"--port=19653), while peripheral emulators such as <span
style="font-weight: bold;">yaPanel</span> act as <span
style="font-weight: bold;">enet</span> clients connecting on
the defined port. I also provide a utility program (<span
style="font-weight: bold;">enetHost</span>) which can be
used either as a client or server, and hence can be used for
debugging or experimenting with the interface.<br>
</li>
</ul>
<li>The following message types are defined:</li>
<ul>
<li>"R <span style="font-style: italic;">X</span>" is a message
in either direction between the peripheral and CPU; if the CPU
receives the message from a peripheral, it relays it to all
peripherals. The message is a command to adjust the
passage of emulated time with respect to real-time by factor <span
style="font-style: italic;">X</span>, with <span
style="font-style: italic;">X</span> being a floating-point
number. If <span style="font-style: italic;">X</span>==1.0
(the default at startup), then emulated time is nominally
identical to real time. If <span style="font-style:
italic;">X</span>==2.0, then emulated time progresses twice
as fast as real time, and so on. If emulated time is
paused (for example, while OBC execution is paused at a
debugger prompt), then <span style="font-style: italic;">X</span>==0.0.</li>
<li>"S <span style="font-style: italic;">C</span>" is a message
from the server to peripherals, instructing them to
synchronize their internal timers to a nominal value of count
<span style="font-style: italic;">C</span> (decimal).
The synchronization is merely nominal, because it may need to
be adjusted for the delays in sending and interpreting the
command itself, and because the software's grasp of time is
only nominal anyway. <span style="font-style: italic;">C</span>
is actually the current number of OBC instructions executed by
<span style="font-weight: bold;">yaOBC</span> since startup,
and during debugging operations like single-step (when "R 0.0"
is in effect), the "S" message is updated after every
instruction. When "R 0.0" is not in effect, an "S"
message is sent to any newly-connected peripheral, but "S"
messages are sent only at several-second intervals thereafter.<br>
</li>
<li>"D<span style="font-style: italic;">YXB C</span>" is a
message from a peripheral emulator to the CPU emulator which
provides the current state of a discrete input. In this
case, <span style="font-style: italic;">Y</span> and <span
style="font-style: italic;">X</span> are octal digits which
are the same as would be used in a <span style="font-family:
Courier New,Courier,monospace;">"CLD <span
style="font-style: italic;">YX</span>"</span> CPU
instruction, while <span style="font-style: italic;">B</span>
is either 0 or 1. <span style="font-style: italic;">C</span>
is the timestamp (see the "S <span style="font-style:
italic;">C</span>" command above) at which the data is
valied. These messages are sent asynchronously, whenever
the peripheral wishes to change the state of the input.
<span style="font-weight: bold;">yaOBC</span> buffers the
message appropriately, and only makes the result available to
the CPU's actual CLD instruction when the appropriate
timestamp <span style="font-style: italic;">C</span> is
reached. If <span style="font-style: italic;">C</span>
is 0, it is interpreted as the current time and the data is
used immediately; this feature is primarily intended for
debugging using the <span style="font-weight: bold;">enetHost</span>
program mentioned above, and shouldn't be used by the CPU or
peripherals in most cases.<br>
</li>
<li>"P<span style="font-style: italic;">YX D C</span>" is a
message in either direction between the peripheral and the
CPU, representing a <span style="font-family: Courier
New,Courier,monospace;">"PRO <span style="font-style:
italic;">YX</span>"</span> CPU instruction input in one
case and an output in the other. <span
style="font-style: italic;">D</span> is a set of up to 9
octal digits representing the data and <span
style="font-style: italic;">C</span> is the timestamp at
which the data is valid. These messages are sent
asynchronously, and the receiving device is supposed to buffer
it until the time indicated by the timestamp has been
reached. If <span style="font-style: italic;">C</span>
is 0, it is interpreted as the current time and the data is
used immediately; this feature is primarily intended for
debugging using the <span style="font-weight: bold;">enetHost</span>
program mentioned above, and shouldn't be used by the CPU or
peripherals in most cases.</li>
<li>"A <span style="font-style: italic;">C</span>" (comports
only) is a message in either direction to repeat all messages
from timestamp <span style="font-style: italic;">C</span>
onward, and would presumably be used in case a corrupted
message had been detected. <span style="font-style:
italic;">(I don't intend actually implementing this
until/unless somebody asks me for it, since I don't
presently think that comports are a likely usage case.)</span></li>
</ul>
<li>The full set of messages which need to be sent over new
connections between the CPU and peripherals is presently
TBD. I'm not sure that there is any good answer to this
question. <span style="font-style: italic;"><br>
</span></li>
</ul>
For example: Part of the process of downlinking telemetry data
is outputting a data word via <span style="font-family: Courier
New,Courier,monospace;">"PRO 10"</span> to the <a
href="#Downlink">Instrumentation System</a> (IS). For the
sake of argument, we'll suppose that the word in the accumulator is
octal 123454321, and that the <span style="font-family: Courier
New,Courier,monospace;">PRO</span> instruction will be the 666'th
instruction executed. The message emitted by the CPU is "P10
123454321 666".<br>
<br>
The optional usage of the <span style="font-weight: bold;">enetHost</span>
program is very simple: To start a server, do "enetHost
--server"; only one server can be running on any given port, so if <span
style="font-weight: bold;">yaOBC</span> or another instance of <span
style="font-weight: bold;">enetHost</span> is running on the same
port, this operation will fail. To start a client, just
"enetHost" (or "enetHost --client", if you prefer). Up to 32
clients can connect to one server, as presently configured.
The switch "--port=<span style="font-style: italic;">PortNum</span>"
can be used to select a port other than the default 19653.
Message data which is supposed to be sent is accepted on stdin,
without any supplemental data. Received-message data is output
on stdout, accompanied by some helpful information:<br>
<ul>
<li>A leading field consisting of the number of characters in the
message.</li>
<li>A field uniquely identifying the sender of the message, by IP
address and dynamically-assigned port number.</li>
<li>The message itself is in double-quotes.</li>
</ul>
Additional information of a less-useful nature, like information on
connects and disconnects, user prompts, and so on, is output on
stderr. In theory, one could construct a Gemini peripheral
emulator from a language with no bindings for the <span
style="font-weight: bold;">enet</span> library, such Tcl/Tk or
some other interpreted language, by using <span style="font-weight:
bold;">enetHost</span> as a backend and redirecting/interpreting
stdin/stdout/stderr appropriately.<br>
<h3><a name="yaOBCASM_the_OBC_Cross-Assembler"
id="yaOBCASM_the_OBC_Cross-Assembler"></a>yaASM, the OBC
Cross-Assembler</h3>
<span style="font-weight: bold;">yaASM</span> has been discussed
above quite a bit, but a few unexplored details remain. This
program is presently functional for OBC, though not necessarily
debugged or tested.<br>
<br>
<span style="font-weight: bold;">yaASM</span> is an assembler for
Gemini OBC and <a href="LVDC.html">LVDC</a> assembly language
files, outputting a binary executable suitable for being used with <a
href="#yaOBC_the_OBC_CPU_Emulation"><span style="font-weight:
bold;">yaOBC</span></a> or <span style="font-weight: bold;">yaLVDC</span>
simulation software. The assembly language for OBC is as <a
href="#Gemini_Assembly_Language">defined above</a>, while the
assembly-language for LVDC is defined on the <a
href="LVDC.html#LVDC_Assembly_Language">LVDC page</a>. Of
course, the reason this combined approach is used is because of the
great similarities between the two computers and their instruction
sets.<br>
<br>
By convention, but not by any requirement of the assembler, Gemini
OBC and LVDC 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 extensions are.<br>
<br>
Note that at present, <span style="font-weight: bold;">yaASM</span>
simply aborts with an error message upon the first source-code error
it detects. I personally don't like that behavior—I'd like to
get a complete list of all errors—but I may or may not be too lazy
to ever change it.<br>
<br>
The command-line syntax for <span style="font-weight: bold;">yaASM</span>
is as follows<br>
<br>
<div style="text-align: center;"><big><span style="font-family:
monospace;">yaASM [<span style="font-style: italic;">OPTIONS</span>]
--input=<span style="font-style: italic;">SourceFilename
>OutputListing</span></span></big><br>
</div>
<br>
The assembled executable binary is always put into a file called
yaASM.bin.<br>
<br>
The presently-defined <span style="font-style: italic;">OPTIONS</span>
are:<br>
<br>
--help<br>
<div style="margin-left: 40px;"> Displays the available <span
style="font-style: italic;">OPTIONS</span> and exits.<br>
</div>
<br>
--lvdc<br>
<div style="margin-left: 40px;"><span style="font-style: italic;">(Option
present, but not currently correctly functional.)</span> This
switch causes assembly to occur for the LVDC computer. The
default, when the switch is missing, is to assemble for the Gemini
OBC.<br>
<br>
</div>
--hwm<br>
<div style="margin-left: 40px;"> Equivalent to putting the directive
<span style="font-family: Courier New,Courier,monospace;">HALF</span>
at the top of the input source file to set half-word mode.
The default is <span style="font-family: Courier
New,Courier,monospace;">NORM</span> to set normal mode
instead. The --hwm switch (or lack thereof) can be
overridden by the directives within the source file itself.<br>
</div>
<br>
--code=<span style="font-style: italic;">M-</span><span
style="font-style: italic;">PP-S-WWW</span><br>
<div style="margin-left: 40px;"> Equivalent to putting the directive
"CODE <span style="font-style: italic;">M-</span><span
style="font-style: italic;">PP-S-WWW</span>" at the top of the
input source file. The default for OBC is "CODE
0-00-2-000". Can be overridden by the directives within the
source file itself.<br>
</div>
<br>
--data=<span style="font-style: italic;">M-</span><span
style="font-style: italic;">PP-S-WWW</span><br>
<div style="margin-left: 40px;"> Equivalent to putting the directive
"DATA <span style="font-style: italic;">M-PP-S-WWW</span>" at the
top of the input source file. The default for OBC is "DATA
0-00-0-000". Can be overridden by the directives within the
source file itself.<br>
</div>
<br>
The formats of the binary output files are identical for Gemini OBC
vs. LVDC. The Gemini OBC has 3 syllables per memory word,
whereas the LVDC has 2 syllables per memory word, bus syllable 2 is
simply cleared to 0 for the LVDC binary output files. It's
true that the the LVDC has up to 8 memory modules, whereas the
Gemini OBC has only 1 ... but the OBC has up to 6 program modules
(which we logically extend to 8) while the LVDC has only 1; so we
economize and use the same output format for both. 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:<br>
<ul>
<li>The binary file consists of a sequence of 16-bit integers.</li>
<li>Most of the output integers contain a 13-bit syllable, aligned
at the least-significant bit of the 16-bit word.</li>
<li>The output words are ordered so that the first word is for
syllable 0 of address 0 of sector 0 of module 0.</li>
<li>Successive output words increment first the word number (0 to
255) next the syllable number (0,1,2), then the sector (0 to
15), then the module number (0 to 7).</li>
<li>At the end are the following additional 32-bit integers:</li>
<ul>
<li>The contents of the HOP register. The starting HOP
constant defaults to 0-00-2-000 with HWM=0, as far as <span
style="font-weight: bold;">yaASM</span> is concerned, but
can be changed within the source code: Just make sure
there's a constant named OBCENTRY defined like "<span
style="font-family: Courier New,Courier,monospace;">OBCENTRY
HOPC LHS</span>", where LHS is an existing left-hand symbol
for where you want the program execution to start.</li>
<li>The contents of the accumulator register. This is
always 0 for files created by <span style="font-weight:
bold;">yaASM</span>.</li>
<li>The contents of the PQ register (which is what's accessed by
the instruction <span style="font-family: Courier
New,Courier,monospace;">SPQ</span>). This is always 0
for files created by <span style="font-weight: bold;">yaASM</span>.</li>
</ul>
</ul>
There's no attempt by the assembler to make this binary file
portable to other computers, so if you assemble such a binary file
on a computer with a little-endian format (such as so-called 'x86
CPUs have) and try to emulate it on a computer with a big-endian
format (such as PowerPC), or vice-versa, you will find that it
doesn't work. However, if you stay within the 'x86 family of
computers, there should be no problem passing such files around
among Linux, Windows, and Mac OS X computers at will.<br>
<h3><a name="yaPanel_the_Control_Panel_Emulation_"
id="yaPanel_the_Control_Panel_Emulation_"></a><img alt=""
src="GeminiIVPilotPanel.gif" style="width: 633px; height:
514px;" width="633" height="514" align="right">yaPanel, the
Control Panel Emulation</h3>
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. <a
name="yaMDIU_the_MDIU_Emulation" id="yaMDIU_the_MDIU_Emulation"></a>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. <span style="font-weight: bold;"><br>
<br>
yaPanel</span> software would provide a simulated MDIU interface
to the <span style="font-weight: bold;">yaOBC</span> simulated-OBC
software ... if <span style="font-weight: bold;">yaPanel</span>
existed. Right now, it's merely a fairly-distant gleam in my
eye.<br>
<br>
Operation of the OBC via the MDIU follows a simple set of
conventions, as follows:<br>
<ul>
<li>Command/data entry into the computer is performed by entering
a 7-digit string of numbers.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>When entering digits, pressing the CLEAR key on the MDR will
erase all of the digits so that entry can be restarted.</li>
<li>When entering digits, it's necessary to wait until a digit is
displayed before entering the next digit. <br>
</li>
</ul>
Control of the OBC via the MDIU is very similar to control of the <a
href="yaAGS.html">Apollo AGS via its DEDA</a>. Here are the
operations which can be performed by the astronaut using the MDIU:<br>
<ul>
<li>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:</li>
<ol>
<li>Press the CLEAR button on the MDR.<br>
</li>
<li>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.<br>
</li>
<li>Press the ENTER button on the MDR to actually perform the
operation.</li>
</ol>
<li>The astronaut can verify data previously stored in the OBC as
follows:</li>
<ol>
<li>Press the CLEAR button on the MDR.<br>
</li>
<li>Enter just the 2 address digits on the MDK.</li>
<li>Press the READ OUT button on the MDR.</li>
<li>The requested data will be displayed and updated at
half-second intervals.</li>
</ol>
</ul>
<img alt="" src="GeminiSwitches.png" style="width: 605px; height:
341px;" width="605" hspace="10" height="341" align="right">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.)<br>
<br>
<a name="PCDP" id="PCDP"></a>As another example, <span
style="font-weight: bold;">yaPanel</span> would provide a
simulated Pilots' Control and Display Panel (PCDP). The
additional controls provided by the PCDP are:<br>
<ul>
<li>The COMPUTER mode selector—selects between the different
sub-programs the computer can run, such as "pre-launch",
"ascent", and so on.<br>
</li>
<li>The START switch—tells the computer to actually begin
executing the computation selected by the COMPUTER selector.</li>
<li>The COMP light—lit while the computation is in progress.</li>
<li>The MALF light—to indicate a malfunction.</li>
<li>The RESET switch—to reset the computer after a malfunction.</li>
<li>The ON-OFF switch.<br>
</li>
</ul>
<div style="text-align: center;"><br>
</div>
<br>
<img alt="" src="GeminiIVI.png" style="width: 600px; height: 524px;"
width="600" hspace="10" height="524" align="right"><a name="IVI"
id="IVI"></a>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.<br>
<ol>
<li>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.<br>
</li>
<li>Forward-aft display device. Displays the magnitude of
the forward or aft delta-V from the previously-set zero point,
in ft./sec.</li>
<li>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.</li>
<li>Left-right display device. Displays the magnitude of the
leftward or rightward delta-V from the previously-set zero
point, in ft./sec.<br>
</li>
<li>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.</li>
<li>Up-down display device. Displays the magnitude of the
upward or downward delta-V from the previously-set zero point,
in ft./sec.</li>
<li>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.</li>
<li>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.</li>
<li>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.<br>
</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ol>
<span style="font-weight: bold;">yaPanel</span> 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 <span style="font-weight: bold;">yaPanel</span> 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.<br>
<br>
<div style="text-align: center;"><img alt="" src="GeminiClocks.png"
style="width: 600px; height: 482px;" width="600" height="482"><br>
</div>
<br>
<div style="text-align: center;">
<div style="text-align: left;">
<h2><a name="Plea_for_Data" id="Plea_for_Data"></a>Plea for Data</h2>
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:<br>
<ul>
<li>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:</li>
<ul>
<li>Flight software.</li>
<li>Preflight software.</li>
<li>Test & checkout software.</li>
<li>Even sample code.</li>
</ul>
<li>Manuals explaining the syntax of Gemini assembly-language.</li>
<li>Any documents missing from the <a href="links2.html#OBC">Document
Library</a>.</li>
<li>Developers' notes.</li>
</ul>
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.<br>
<h2><a name="Reminiscences_and_Factoids_from_the"
id="Reminiscences_and_Factoids_from_the"></a>Reminiscences
and Factoids from the Original Developers</h2>
In this section, I provide distilled/edited material from
personal correspondence I've had (directly or indirectly) with
original OBC developers. The following are thus not direct
quotes, and you should attribute errors to me rather than to my
correspondents.<br>
<br>
<span style="font-style: italic;"><span style="font-weight:
bold;">From Eugene Mertz:</span></span><br>
<div style="margin-left: 40px;">
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; background-color:
rgb(204, 255, 255);">
<p class="MsoNormal"><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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.<br>
</span></font></p>
<p style="color: rgb(0, 0, 0);" class="MsoNormal"><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">Many
things were new in the 50s, 60s and 70s.
In the late 50s, I participated in a panel
discussion on local TV to explain to the public
what space, satellites, Sputnik, Vanguard, etc.,
were all about. Looking back on that
experience, I believe it was done to alleviate
small-town public fear that something bad was
about to happen soon. I'm not sure we
succeeded.</span></font><br>
</p>
<p class="MsoNormal"><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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).<br>
</span></font></p>
<p class="MsoNormal"><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">The
transcendental equations were written by an IBM
engineer<big><big>, <small><small>Connie
McClure,</small></small></big></big> who
was a professor formerly at GW University (I
believe) in Washington, DC. He</span></font>
<font size="2" face="Arial"><span style="font-size:
10pt; font-family: Arial;">also taught orbital
mechanics to the team very early in the
project. It was a tough course</span></font><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">.
I wish I had kept all his notes.</span></font><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">
The series expansion was verified and derived by
a number of analysts at IBM, other contractors
and sub-contractors, and probably NASA.</span></font><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">
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.</span></font><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">
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.<br>
</span></font></p>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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!<br>
</span></font><br>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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. [<span style="font-style: italic;">Ed.:
There are machine-dependent features, it seems,
so the program must either have been FORTRAN II
or a mix of II and IV.</span>]</span></font><br>
<br>
<font size="2" color="navy"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial; color:
navy;"><span style="color: rgb(0, 0, 0);">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). </span><br>
</span></font><br>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">Here
are a few tidbits which I believe are accurate:</span></font><br>
<br>
<ul style="margin-top: 0in;" type="disc">
<li class="MsoNormal" style=""><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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</span></font> <font
size="2" face="Arial"><span style="font-size:
10pt; font-family: Arial;">I don't recall
exactly what the translator encompassed. </span></font>
<font size="2" face="Arial"><span
style="font-size: 10pt; font-family: Arial;">Perhaps
someone else will come forward with
clarification.</span></font></li>
<li class="MsoNormal" style=""><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">A
lot of coordinate system transformations were
performed, especially during rendezvous.</span></font></li>
<li class="MsoNormal" style=""><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">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.</span></font></li>
</ul>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">I'm
beginning to learn things about the Gemini memory
I wish I had known in the 1960s. For
example, after many divide instructions were
executed in a row (I don't know how many), the
memory cores heated up and you would get the wrong
answer in the accumulator. This problem was
controlled by inserting a no-op instruction
between the divides, thus keeping the cores cool
enough to always give the right answer.
Wow! If I had known this, maybe I would have
structured the guidance equations
differently. But we had smart OBC
programmers who could figure out ways to get
around hardware problems, both in the OBC and in
external equipment (such as the on-board
radar). There were lots of lessons learned
in the early days of space flight. And there
wasn't much time to spend figuring out how to fix
problems.</span></font><br>
<br>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">The
MARS [type of memory element used] inventor was
probably <a
href="http://www.spoke.com/info/pFeUHpV/AlbertVinal">Al
Vinal</a>. </span></font> <font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">I
recall the core device as being called
Multi-Aperture Reluctance Switch.</span></font><small><small><font
style="font-family: Arial;" size="3" face="Times
New Roman"><small><small><span style="font-size:
12pt;"><small>Making the MARS devices was
an art, not a science. They were
made</small></span></small></small></font><font
style="font-family: Arial;" size="3" face="Times
New Roman"><small><small><span style="font-size:
12pt;"><small> using an "aspirin press"
and fired in an oven, a tray at a time.</small></span></small></small></font></small></small><br>
<br style="color: rgb(0, 0, 0);">
<font style="color: rgb(0, 0, 0);" size="2"
color="navy" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">The
OBC code listings were run through a detailed
manual check by a team of OBC programmers and
hardware experts, instruction by
instruction. All team members had to agree
100%. <br>
<br>
I recall (?) there was a processing module that
used input from OBC compiled instructions and
created a punched Mylar output tape. This
tape was run on the memory loader [6' x 19" rack
of equipment!] to program the OBC.</span></font><br
style="color: rgb(0, 0, 0);">
<br>
<font style="color: rgb(0, 0, 0);" size="2"
color="navy" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"><span
style="font-style: italic;">(On finding a memo
describing the three-term</span></span></font><small><span
style="font-family: Arial; font-style: italic;">
gravitational potential function describing the</span><span
style="font-family: Arial;"><span
style="font-style: italic;"> oblate Earth while
looking for material for this website.)</span></span><span
style="font-family: Arial;">It surprised me to
find the equation. Three</span><br
style="font-family: Arial;">
<span style="font-family: Arial;">terms were used
for the rendezvous mode, two terms used for the
orbital</span> <span style="font-family: Arial;">navigation
mode, and up to six terms were used for the
"environment"</span><span style="font-family:
Arial;">simulation and accuracy comparisons.
Obviously (?), the OBC couldn't handle</span> <span
style="font-family: Arial;">six terms along with
everything else in memory, or the speed required.
We</span> <span style="font-family: Arial;">needed
the
power of a modern TV remote.</span></small><span
class="moz-smiley-s1"><span>:-)</span></span>
<br>
<font style="color: rgb(0, 0, 0);" size="2"
color="navy" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"><span
style="font-style: italic;"><br>
(On the subject of recreating the complete OBC
assembly-language source code from Math Flow
diagrams.)</span> Charlie Leist, Alden Minnick,
and I discussed the possibility of recreating the
complete reentry and rendezvous modules but, as a
group, rejected the idea because the effort to do
so would have been too great. Instead, Alden
and Charlie each chose a section of code they felt
comfortable (?) coding. Comfort was relative
because neither was sure he could recall all the
details. A lot of reading of the programming
manual and discussion was necessary to recall what
it all meant. That's why it took so long to
complete the snippets. Further, the I/O
other subroutines were missing. They would
have had to be "reinvented." We just had the
names of the subroutines, not the actual code.</span></font><br
style="color: rgb(0, 0, 0);">
<br style="color: rgb(0, 0, 0);">
<font style="color: rgb(0, 0, 0);" size="2"
color="navy" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">Consider
this
\96 the OBC was the first attempt (to my
knowledge) by the company to develop a digital
computer to fly men into space. The memory
device, the same as was used in OAO, was designed
basically for collection of data from the
telescope, storing it until it could be sent via
telemetry to a ground station. No real
computer involved — until Gemini.</span></font><br
style="color: rgb(0, 0, 0);">
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"><br>
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.<br>
<br>
</span></font> <small><span style="font-family:
Arial;">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).</span><small><br>
</small></small><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"><br>
</span></font>
<table summary="" style="text-align: left; width:
100%;" cellspacing="2" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top; text-align:
center;"><a
href="MiniTrackMark-II-StationAtK2ERQ-002.jpg"><img
alt="Gene and friends at Vanguard tracking
station" title="Click to enlarge."
src="thm-MiniTrackMark-II-StationAtK2ERQ-002.jpg"
style="border: 2px solid ; width: 252px;
height: 200px;"></a><br>
</td>
<td style="vertical-align: top; text-align:
center;"><a
href="MiniTrackMark-II-AntennaAtK2ERQ-001.jpg"><img
alt="Partially-completed antenna for the
tracking station." title="Click to
enlarge."
src="thm-MiniTrackMark-II-AntennaAtK2ERQ-001.jpg"
style="border: 2px solid ; width: 235px;
height: 200px;"></a><br>
</td>
</tr>
</tbody>
</table>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"><br>
</span></font></td>
</tr>
</tbody>
</table>
<br>
</div>
<span style="font-style: italic;"><span style="font-weight:
bold;">From Charlie Leist:</span></span>
<div style="margin-left: 40px;">
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; background-color:
rgb(204, 255, 255);">
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"> The ATM magnetic tape was 550
feet long and about 1 inch wide. The magnetic
tape was loaded using test equipment run in the
IBM Owego test lab that read a 2000 ft mylar
tape with punched holes that contained the
memory load information for each program module.
The operational program modules had to be
placed on the magnetic tape twice in sequence
just in case there was a malfunction in loading
a program module. The second half of the
magnetic tape contained the same memory load
information as the first half of the tape. The
tape header for each program module was unique
so there would be no confusion on what program
module to load into the Gemini computer memory.<br>
<br>
</span></font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"> It was my job to generate the
2000 ft punch tape after each module programmer
had tested and peer code inspected their
operational program module. I do not
remember ever having to change a magnetic
tape from wear or breakage on a tape unit
for any of the flight programs in the test
lab. This tape unit was sealed and the magnetic
tape not easily changed.<br>
<br>
</span></font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"> The peer code inspection
included a scheduled meeting in a conference
with the appropriate system engineers and
operational programmers.<br>
<br>
</span></font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"> The inspection process included
the following reviews:<br style="font-family:
Arial;">
</span></font></div>
<div style="font-family: Arial;"></div>
<div style="font-family: Arial;"></div>
<ol style="font-family: Arial;">
<li><font size="2" color="black"><span
style="font-size: 10pt; color: black;">A
comparison of every block on a system math
flow diagram (developed by the system
engineer) with every
corresponding block on a detailed math
flow diagram (developed by a programmer).</span></font></li>
<li><font size="2" color="black"><span
style="font-size: 10pt; color: black;">A
comparison of every program instruction
(assembly listing generated on the IBM
7090 computer by the programmer) with
every block on the detail flow
diagram.</span></font></li>
</ol>
<div style="font-family: Arial;"></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"> When no errors were found the
program module was deemed ready for flight by
the inspection team of system engineers and
programmers.<br>
<br>
</span></font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"> This process took several
days and was always successful since to my
knowledge no flight operational program
problems were ever reported.<br>
<br>
</span></font></div>
<font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial; color:
black;">The time to generate a 2000 ft punch tape
took several hours and I spent many long nights in
the 7090 computer room being sure that no
problems occurred in the hole punching equipment.</span></font><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"><br>
<br>
</span></font>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"> I have often wondered how IBM
assembled this team of dedicated Gemini people
that came together and did so many creative
things.<br>
<br>
<span style="font-style: italic;">On
no-operation (NOP), memory overheating when
the wrong instruction sequence is used, and
waiting for multiplications or divisions to
complete:</span><br>
</span></font>
<table summary="" style="text-align: left; width:
80%; margin-left: auto; margin-right: auto;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;">
<div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family:
Arial; color: black;"> I will give
you an example of coding to prevent
overheating of memory. Lets say the
equations required the programmer to
make 3 divides in a row (
A=B/C, D=E/F, G=H/I).
Conceptually, it would be
programmed as:</span></font></div>
</div>
<div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family:
Arial; color: black;"> </span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">CLA B
Load the accumulator</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">DIV C
Start the division</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">SPQ
A Save the
computed quotient<br>
NOP
NOP
did not use any memory locations and
thus would not heat up the memory.</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">CLA E</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">DIV F</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">SPQ D</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP
Again
no heat up of the memory</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">CLA H</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">DIV I</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">SPQ G</span></font></div>
</div>
<div style="font-family: Courier
New,Courier,monospace;">
<div>
<div style="margin-left: 40px;"><font
size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP
Again
no heat of the memory</span></font></div>
</div>
</div>
<div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family:
Arial; color: black;"> </span></font></div>
</div>
<div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family:
Arial; color: black;"> You could do
as many divides in a row as you
wanted as long as you put the NOP
instruction after the SPQ
instruction. Those extra NOPs kept
the memory from heating up.</span></font></div>
</div>
<div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family:
Arial; color: black;"> </span></font></div>
</div>
<div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family:
Arial; color: black;"> Now, the real
interesting thing about the DIVide
instruction is that the answer was
only available to the memory
location specified by the SPQ
instruction after 4 instructions
were executed after the DIV
instruction. So the code
snippet above wouldn't actually have
worked. The example was <span
style="font-style: italic;">really</span>
programmed as below:<br>
</span></font> <br>
</div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">CLA B</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">DIV C</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">SPQ A</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP
Cool
memory</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">CLA E</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">DIV F</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP </span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">SPQ D</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP
Cool
Memory</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">CLA H</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">DIV I</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP</span></font></div>
</div>
<div style="margin-left: 40px; font-family:
Courier New,Courier,monospace;">
<div><font size="2" color="black"><span
style="font-size: 10pt; color:
black;">SPQ G</span></font></div>
</div>
<div style="font-family: Courier
New,Courier,monospace;">
<div>
<div style="margin-left: 40px;"><font
size="2" color="black"><span
style="font-size: 10pt; color:
black;">NOP
Cool
memory</span></font></div>
</div>
</div>
<div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family:
Arial; color: black;"> </span></font></div>
</div>
<div>
<div><b><font style="font-weight: normal;"
size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt;
font-family: Arial; color: black;">
Later on in the Gemini Program,
Jim Condell noticed that the 3 NOP
instructions between the DIV and
SPQ were not doing any useful work
and asked Pat Mooney if we the
programmers could use them for
something other than NOPs. Pat
checked with the Computer
designers and they said YES! This
was an Atta Boy for Jim on memory
use saving!!</span></font> <b><font
size="2" color="black"
face="Arial"><span
style="font-size: 10pt;
font-family: Arial; color:
black;"><br>
</span></font></b></b></div>
</div>
</td>
</tr>
</tbody>
</table>
<font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;
color: black;"><br>
</span></font>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"><span
style="font-style: italic;">On scaling of
numerical values during calculations:</span>
<font><font><font><font size="2" color="black"
face="arial,helvetica,sansserif"><font
size="2" color="black"
face="arial,helvetica,sansserif"><font
size="2" color="black"
face="arial,helvetica,sansserif"><font
size="2" color="black"
face="arial,helvetica,sansserif">Scaling
is something the programmer did by
hand calculations. You got no help
from the assembler on this topic.
Fixed point scaling of numbers in
Gemini made the programmer <b>always,
always, always</b> remember
where the decimal point and binary
point was at ALL times. Scaling
was a most difficult task in
Gemini programming.</font></font></font></font></font></font></font><br>
<br>
The assembler read and processed one 80 column
punch card (from the punch card deck) at a time
that card contained (Left Hand Symbol,
operation instruction, instruction address, and
comment preceded by a # sign). There was not a
second card that contained more information for
a single 80 column card just read by the
assembler.</font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"> </font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif">The assembler
provided a lot of pre and post
processed tables before and after the coded
program was assigned the binary 39 bit code
for each instruction.<br>
</font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"> </font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif">A program
listing generated by the assembler for Re-entry
and Ascent (just examples) would be about 3
inches thick each and contained: Pre and
Post processed tables for Constants, Variables,
Constants and Left hand symbols ( I showed this
in my code Snippets)</font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"> </font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif">A symbolic card
deck (punched from a key punch machine) for
either of these programs would contain a
complete box of IBM cards for each
program (80 columns per card);</font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"> </font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif">On power up of
the Gemini Computer the first instruction
executed would always start at
00-0-00 (sector zero, instruction zero and
address zero).</font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif"> </font></div>
<div><font size="2" color="black"
face="arial,helvetica,sansserif">In my Gemini
Re-entry mode and Touch Predict mode coding in
the Sixties (1962 to 1966), I did not
hardly ever use comments and probably
is why I did use the # in front my
Comments in the code Snippets. This was
added programming work in key punching and I did
see the value added comments. On the other hand,
Al was an excellent programmer and used many
comments for one to use in following his coding
techniques and the use of many Temp01, 02, 03,
04, 05 and 06 variables!! When I was reviewing
Al's code Snippets it took me 2 1/2 hour for
just one pass through the code!</font></div>
<br>
<small style="font-style: italic;"><span
style="font-family: Arial;">(On Don O'Neill, the
OBC assembler guru.)</span></small> <font
size="2" color="black" face="arial"><font
face="Arial, Helvetica, sans-serif">When we (the
less than 10 OBC programmers) were working
coding the operational programs in Owego you
could always count on Don stopping by your
desk at any time with Assembler in hand. He
would stay as long as he thought necessary to be
sure you knew another part of the Assembler and
its interface with the Gemini Simulator. He told
us it was necessary to know every part of the
Assembler and how it worked. He said we would be
better programmers if we knew how every part of
the Assembler operated on your code!!</font></font></div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<span style="font-style: italic;"><span style="font-weight:
bold;">From Dick Fisher:</span></span>
<div style="margin-left: 40px;">
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; background-color:
rgb(204, 255, 255);"><font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">The
OAO Program, the Gemini computer, and the Apollo
Program were such exciting space ventures that</span></font><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"> you
had to feel privileged to be working on
them. I have never been on a program again
like Apollo where you were working with so many
other companies and you were cheering them on for
their successes.<br>
<br>
</span></font> <font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">I
joined IBM in Harry Branning's Dept. in
1956. Al Vinal was there working on the MARS
device. I didn't have much to do with him
then as I was in the digital circuits group under
Bob Hildenbrandt. Bob had left for Glendale
[<font style="color: rgb(0, 0, 0);" color="red">an
IBM lab located near Endicott, NY]</font> by
1960 when we</span></font> <font size="2"
face="Arial"><span style="font-size: 10pt;
font-family: Arial;">bid on the OAO so I was the
senior circuits guy then in that dept. The
OAO was to last a year in orbit and there was no
technology with that kind of reliability.
Bob Urquhart and I came up with a new circuit
technology we</span></font> <font size="2"
face="Arial"><span style="font-size: 10pt;
font-family: Arial;">called quad-redundancy.
Grumman won the spacecraft contract but NASA</span></font>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">made
them take our design for the memory system instead
of Westinghouse, who had bid the memory system
with Grumman and made</span></font> <font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">Radiation
Inc. (who won the communications part) use our
design concept.</span></font> <font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">After
I finished the digital circuits design Harry put
me on the design of</span></font> <font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">all
the memory circuits for Al Vinal. The last
time I had checked on the status of the OAO in
orbit, it was still performing after three
years. I used that same design concept on
the switch selector for the Saturn Launch</span></font>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">Vehicle
in Huntsville as the switch selector had to have
the highest reliability as there were four of
those boxes on each rocket, one for the Instrument
Unit and one in each of the three stages of
propulsion and all</span></font> <font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">commands
for gimballing of the engines for control of the
rocket and for</span></font> <font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">stage
separation and ignition of the next stage from the
control computer</span></font> <font size="2"
face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">were
sent thru the switch selector. IBM got about
a 5 million dollar contract from that and I got an
OCA. I had often wondered where Al Vinal</span></font><font
size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;"> was
and what he was doing since the Gemini
program. Its hard to believe he's been dead
for the past 16 years [as of 2011] and he died so
young. I think the last I had heard of
him he and Connie something were working on a new
theory of relativity. He was a very bright
guy and very patient to work with as I</span></font>
<font size="2" face="arial,helvetica,sansserif"><span
style="font-size: 10pt; font-family: Arial;">knew
nothing of the MARS devices when I first started
working with him.</span></font><br>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<span style="font-style: italic;"><span style="font-weight:
bold;">From Don O'Neill:</span></span>
<div style="margin-left: 40px; font-family: Arial;">
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; background-color:
rgb(204, 255, 255);"><small><font style="font-style:
italic;"><font size="3" lang="0" color="#000000"><small>(In
response to "</small></font></font><font
style="font-style: italic;"><font size="3"
lang="0" color="black"><small>How much
programming could you do with 16 instructions
and 39 bits?</small></font></font><font
size="3" lang="0" color="black"><small><span
style="font-style: italic;">")</span> As
much as a Turing Machine and more!</small></font>
<font size="3" lang="0" color="#000000"><small>Limits
were imposed only by the lack of an interrupt
mechanism, sector addressability, the lack of
floating point, and 25-bit plus sign precision.
Some may recall when Jim Joachim demanded an
interrupt mechanism and the shoe banging
imitating the Nikita Kruschev action at the UN.<br>
<br>
<span style="font-style: italic;">(On the
question of "left-hand symbols" vs. "labels"
for naming lines of code.)</span> </small></font>
<font style="font-family: Arial;"
face="arial,helvetica"><font size="3" lang="0"
color="black"><small>Left-hand symbols were used
for navigation through the code. Variables and
constants were named. Left-hand symbols,
variable symbol, and constant symbols
(preceded with a K signifying a constant that
was not to stored into memory altered) might
be called labels, but the term label was not
used at the time.<br>
<br>
</small></font></font> <big><font
style="font-family: Arial;"><font size="2"
color="black"><font size="3" lang="0"
color="black"><small>Overall the
contemporary criteria for coding standard
of excellence can be found in the Software
Inspections checklists I have sent
you. [<span style="font-style:
italic;">The checklists mentioned were
ones Don developed while working on SEI
at CMU; I don't care to reproduce them
here, but if you're familiar with SEI
you'll get the idea.</span>] Ron,
you might want to conduct a software
inspection on one of your procedures [<span
style="font-style: italic;">alas! so
wise and yet so wrong!</span>] to see
how you stack up against the standard of
excellence or to see how the standard of
excellence stacks up as an actual quality
threshold</small>.<br>
<br>
<small style="font-style: italic;">(On the
question of very limited use of
subroutines in OBC code.)</small></font></font></font></big></small><font
face="arial,helvetica"><font size="2" color="black"
face="Geneva"><span style="font-family: Arial;">I
do not recall a subroutine mechanism. A number
of people on the Gemini Project worked on the
XB70 bombing and navigation computer, a drum
computer whose instructions were read and
executed from a rotating drum so there was no
subroutine mechanism possible. In addition, the
slavish attention to the Math Flow, literally a
flow chart, reinforced linear, sequential
thinking. This was reinforced by the fact that
there was no interrupt on the Gemini computer.</span></font></font>
<font size="2" color="black">All this was literally a
deterministic state machine.</font><br>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<span style="font-style: italic;"><span style="font-weight:
bold;">From Pat Mooney:</span></span>
<div style="margin-left: 40px; font-family: Arial;">
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; background-color:
rgb(204, 255, 255);"><small><font style="font-style:
italic;"><font size="3" lang="0" color="#000000"><small>(In
response to</small></font></font> <font
size="3" lang="0" color="black"><small><span
style="font-style: italic;">being presented by
Charlie Leist and Jim Condell</span></small></font></small>—<small><span
style="font-style: italic;">who had worked for him</span></small>—<small><font
size="3" lang="0" color="#000000"><small><span
style="font-style: italic;">with the Gemini
Programming Manual</span></small></font></small><small><font
size="3" lang="0" color="black"><small><span
style="font-style: italic;"> in 2011, rather
than the 1960's when it was written.</span></small></font></small><small><font
size="3" lang="0" color="black"><small><span
style="font-style: italic;">)</span> </small></font></small><font><font
size="2" color="black"
face="arial,helvetica,sansserif">"</font></font><font><font
size="2" color="black"
face="arial,helvetica,sansserif">Charlie and Jim,
I told you two guys to write this manual and to
bring it back to me for comment and sign off. I
always wondered why you did not follow my
direction and how did you get it out of Owego with
out my signature? ... Charlie, I am going to
review this document, make comments and sign off
on it. I expect you fix the errors I find!!</font></font><font><font
size="2" color="black"
face="arial,helvetica,sansserif">"</font></font></td>
</tr>
</tbody>
</table>
</div>
<br>
<span style="font-style: italic;"><span style="font-weight:
bold;">From various unidentified team members:</span></span>
<div style="margin-left: 40px; font-family: Arial;">
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; background-color:
rgb(204, 255, 255);"><small><small><small><font
style="font-family: Arial;" size="3"><small><small><small><span
style="font-size: 12pt;"><small>The
memory element was a non-destructive
readout (NDRO) device invented for
use in the Orbiting Astronomical
Observatory (OAO). The design
was based on the Multi-Aperture
Readout Sensing
(MARS) principle. The
MARS device principal used a
two-hole core (as opposed to
single-hole "donut" then commonly
used in memory designs). The
new principle was based on sensing
the logical state of a core at one
of the holes, and restoring the
state by electrically pulsing the
second hole (ed. that's my limited
understanding) thus achieving the
equivalent of non-destructive
readout -- a critical requirement
for space applications.</small></span></small></small></small></font></small></small><br>
</small><br>
<small><small><font size="3" color="black"><small><small><span
style="font-size: 12pt;"><small>The 7090
had a fixed point add, subtract,
etc. So, one could program the
Gemini OBC equations in assembly
language and execute them on the 7090
using a simulator. But you had to
mask off all 7090 bits over 26 to
contain the computation to the Gemini
OBC 26-bit format. We did that to
check function and accuracy</small>.</span></small></small></font><br>
<br>
<font size="3" color="black"><small><small><span
style="font-size: 12pt;"><small>Computational
step size in the simulation was
controlled using 7090 console
keys. A family of results could be
run to determine if the Gemini OBC
timing was adequate</small>.</span></small></small></font></small></small><br>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
<h2><a name="Homage" id="Homage"></a>Homage<br>
</h2>
<img style="width: 169px; height: 256px;" alt=""
src="SpaceWalkOfFamGemini1.jpg" align="right">Part of my
purpose on this web-page is to pay homage to the original Gemini
flight-software developers. I have little information
about them, so if you know things about them, feel free to pass
your information to me. What I <span style="font-style:
italic;">do</span> know follows: <br>
<ul>
<li>Here's a big list of 70-or-so names (and where recalled)
responsibilities of team members, put together by OBC
developers Gene Mertz, Charlie Leist, &co.: <a
href="Documents/GeminiDevelopers.pdf"> Gemini development
team.</a></li>
<li>And here are a few other names I got from Gene, which for
some reason or other didn't make it onto his official list:</li>
<ul>
<li>Marv Czarnik, of McDonnell, interface for rendezvous
guidance.</li>
<li>Scarborough (?), programmer (?)</li>
</ul>
<li>I'm also informed of the Gemini area of the U.S. Space
Walk of Fame, which includes an engraved list of names
(pictured at right). I'm given to understand that
(sadly) only a few of the names on the monument seem to from
the IBM Gemini flight-software software-development team.</li>
</ul>
<br>
</div>
</div>
<hr style="width: 100%; height: 2px;">
<center><br>
<span style="color: rgb(84, 89, 93); font-family: sans-serif;
font-size: 11.05px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
16.575px; orphans: auto; text-align: center; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display:
inline !important; float: none; background-color: rgb(255, 255,
255);"> This page is available under the <a
href="https://creativecommons.org/publicdomain/zero/1.0/">Creative
Commons
No Rights Reserved License</a></span><br>
<i><font size="-1">Last modified by <a
href="mailto:info@sandroid.org">Ronald Burkey</a> on 2021-11-19.<br>
<br>
<a href="http://www.ibiblio.org"><img style="border: 0px solid
; width: 300px; height: 100px;" alt="Virtual AGC is hosted
by ibiblio.org" src="hosted.png" width="300" height="100"></a><br>
</font></i></center>
<br>
<br>
</body>
</html>
Computing file changes ...
