swh:1:snp:79c9132b4a8931e989e318225e00e088ef6f383d
Tip revision: a8fa8f03b50a72034009439908f1339f4ce94518 authored by Ron Burkey on 06 June 2021, 12:28:21 UTC
Fixed more hyperlinks.
Fixed more hyperlinks.
Tip revision: a8fa8f0
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 occured when the
roll angle was too great.) On the other hand, at that
point the spacecraft was under manual control anyway, and I'm
sure that the notion that the IMU would have to be realigned
later would have been the least of Neil Armstrong and Dave
Scott's worries.<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="links.html#Gemini_spacecraft_computer">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 eventualy 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 redigesting 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 accessable,
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
orgainization 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 cabable 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-signficant 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\EFvely 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\EFve 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 parliance 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-langauge 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 subsitute 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 operand, and the address
embedded in the instruction points to the other
operand. Recall that A1-A8 select the offset within a
256-word sector, and A9 is the "residual bit" that selects
between the current sector and the "residual sector".
In both cases, the most-significant 24-bits of the operands
are used, and the least-significant 2 bits of the operand
are ignored. The result is available via the
<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>
MUL
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 subsitute 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 discretes</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;">
Simulaton 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 neverthless 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
acculator 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. The actual capacity of the tape was
"over 85,000 thirteen-bit words", which is about 7 times the
capacity of the ferrite array. I don't know exactly how
long it took to load programs from the ATM into the OBC, but the
total tape could be read in 67 minutes, so the maximum amount of
time a program load could have taken would be about 10
minutes. Since not all of the memory could be overwritten,
and since syllable 2 of the 39-bit memory words couldn't be
changed in flight anyway, the actual loads would have taken less
time, and is estimated at about 7 minutes.<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 inteface 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 extenguished 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:<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;">Lets
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;">Lets
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;">Lets
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 repents 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 unti 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 progam 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
instruciton 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 geniune 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 respository, 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-langage 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 desgnations 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 otherwised
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 insted 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 messge 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 LVCD source-code files have the filename
extensions .obc and .lvdc, respectively. This convention
arises from the existence (or potential existence) of
CPU-specific syntax highlighters when viewing such source
code. The assembler does not care what the filename
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="links.html">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 noticted 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 preceeded 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
necessay 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
2020-06-20.<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>
