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
LVDC.html
<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>The Launch Vehicle Digital 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@","Launch Vehicle Digital Computer (LVDC)").replace("@SUBTITLE@","Saturn IB and Saturn V Rockets"))
</script>
<h2>Contents</h2>
<ul>
<li><a href="#What_is_the_Launch_Vehicle_Digital_">What is the
Launch Vehicle Digital Computer (LVDC)?</a></li>
<li><a href="#Peripheral_Devices">Peripheral Devices</a></li>
<li><a href="#Interaction_with_the_AGC">Saturn Interaction with
the AGC</a><br>
</li>
<li><a href="#LVDC_Documentation">LVDC Documentation</a></li>
<li><a href="#LVDC_Software">LVDC Software</a></li>
<ul>
<li><a href="#Overall_Structure">Overall Structure</a></li>
<li><a href="#Preflight_Program">Preflight Program</a></li>
<li><a href="#Executive_Control_Program">Executive Control
Program</a></li>
<li><a href="#Flight_Program_in_General">Flight Program in
General</a><br>
</li>
<li><a href="#Evolution_of_the_Flight_Software">AS-206RAM Flight
Program Specifically</a></li>
<li><a href="#PTC_ADAPT_Self-Test_Program">PTC ADAPT Self-Test
(PAST) Program</a><br>
</li>
</ul>
<li><a href="#Architecture_of_the_LVDC">Architecture of the LVDC</a></li>
<ul>
<li><a href="#References_">References</a></li>
<li><a href="#General_Characteristics_of_the_Computer_">General
Characteristics of the Computer</a></li>
<li><a href="#Layout_of_Memory_Words">Layout of Memory Words</a></li>
<li><a href="#CPU_Instructions">CPU Instructions</a></li>
<li><a href="#IO_Ports_For_PIO_Instruction">I/O Ports (for
LVDC/PTC <span style="font-family: Courier
New,Courier,monospace;">PIO</span> Instructions)</a></li>
<li><a href="#IO_Ports_for_PTC_CIO_Instruction">I/O Ports (for
PTC <font face="Courier New, Courier, monospace">CIO</font>
Instructions)</a><br>
</li>
<li><a href="#Subroutine_Linkage">Subroutine Linkage</a><br>
</li>
<li><a href="#Interrupts">Interrupts</a></li>
<ul>
<li><a href="#Interrupts_of_LVDC">Interrupts of LVDC</a></li>
<li><a href="#Interrupts_of_PTC">Interrupts of PTC</a><br>
</li>
</ul>
<li><a href="#Telemetry">Telemetry</a></li>
<li><a href="#Up-data">Up-data</a><br>
</li>
</ul>
<li><a href="#LVDC_Assembly_Language">LVDC Assembly Language</a></li>
<ul>
<li><a href="#Basic_Factoids">Basic Factoids</a></li>
<li><a href="#Preprocessor_Pass">Preprocessor Pass</a></li>
<li><a href="#Assembly_Pass">Assembly Pass</a></li>
<li><a href="#Pseudo-ops">Pseudo-ops</a><br>
</li>
<li><a href="#ANATOMY">Program Structure</a><br>
</li>
</ul>
<li><a href="#MIT_Instrumentation_Laboratory_vs_IBM">MIT
Instrumentation Laboratory vs IBM Federal Systems Division</a></li>
<li><big><a href="#yaLVDC_the_LVDC_CPU_Emulation"><small><small><big><small><big><span
style="font-weight: bold;">yaLVDC</span>, the
LVDC/PTC CPU Emulation</big></small></big></small></small></a></big></li>
<li><a href="#yaLVDCASM_the_LVDC_Cross-Assembler"><span
style="font-weight: bold;">yaASM.py</span>, the LVDC/PTC
Cross-Assembler</a></li>
<li><a href="#Running_the_PTC_ADAPT_Self-Test_Program">Running the
PTC ADAPT Self-Test Program in the LVDC/PTC Emulator</a><br>
</li>
<li><a href="#Plea_for_Data">Plea for Data</a></li>
<li><a href="#Homage">Homage</a><br>
</li>
</ul>
<h2><a name="What_is_the_Launch_Vehicle_Digital_"
id="What_is_the_Launch_Vehicle_Digital_"></a>What is the Launch
Vehicle Digital Computer (LVDC)?<br>
</h2>
<a href="lvdc_upper.jpg"><img alt="" title="Click to enlarge"
src="lvdc_upper-small.jpg" style="border: 2px solid ; width:
288px; height: 165px;" width="288" height="165" align="right"></a>The
Launch
Vehicle Digital Computer (LVDC) was a computer that resided in the
Instrument Unit (IU) that perched above the Saturn IVB that was the
second stage in a Saturn IB rocket and the third stage in a Saturn V
rocket. The LVDC was a completely separate computer system
from the AGC, with a different architecture, different
instruction-set, and different runtime software. The purpose
of the LVDC was to precisely control the Saturn from shortly before
liftoff until the point at which the Saturn was discarded by the
CSM. <br>
<br>
<table summary="" style="text-align: left; width: 60%; margin-left:
auto; margin-right: auto;" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td style="vertical-align: top;">
<div style="text-align: center;"> <span style="font-weight:
bold; text-decoration: underline;">Factoid</span><br>
</div>
People generally think that the guidance computer (AGC) of
the command module controlled the Saturn rocket, but it
isn't true. During burns of the S-II and S-IVB rocket
stages, it <span style="font-style: italic;">was</span>
possible for the CSM's AGC to control the steering, as a
backup to the LVDC. That backup capability was never
used in a mission. This was not possible during burns
of the first stage (S-IB or S-IC). However, the
AGC's ability to directly control the Saturn IVB was used
for other purposes during the mission. <a
href="#Interaction_with_the_AGC">Also, see below</a>.<br>
</td>
</tr>
</tbody>
</table>
<br>
<div align="center"><img title="LVDC and friend." alt=""
src="LVDCandFriend.jpg" width="443" height="377"><br>
<br>
</div>
The LVDC has a less-visible role in people's eyes than the AGC, not
only because it was used for only a very small portion of the
individual missions, but also because it had no user interface as
such. In other words, it was a black box that responded to
inputs from sensors in the Saturn and to ground telemetry, but there
was no panel into which astronauts could enter commands or get
feedback from it. One might well call the LVDC "The Forgotten
Computer", even more so that the computer of the <a
href="yaAGS.html">LM's Abort Guidance System</a>.
Nevertheless, the LVDC's importance is great, because you need to
actually get the Command Module and Lunar Module into space and
headed toward the moon if you expect any landings to occur! As
I understand it, the folks that actually worked on the Saturn
referred to the Instrument Unit as "The Brain", and that term might
as well be applied to the LVDC, since it was the brain of The Brain.<br>
<br>
<table summary="" style="text-align: left; margin-left: auto;
margin-right: auto;" cellspacing="2" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;"><img style="width: 175px;
height: 900px;" alt="" src="SaturnV-simple.jpg"
width="175" height="900"><br>
</td>
<td>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: middle;"><img style="width:
600px; height: 336px;" alt="" src="IU-simple.jpg"
width="600" height="336"><br>
</td>
</tr>
<tr>
<td style="vertical-align: top;"><img style="width:
600px; height: 255px;" alt=""
src="SaturnNavigationScheme-simple.jpg"
width="600" height="255"><br>
</td>
</tr>
</tbody>
</table>
</td>
<td><img style="width: 290px; height: 500px;" alt=""
src="Saturn1B-simple.jpg" width="290" height="500"><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
The LVDC was developed by IBM Federal Systems Division, rather than
by the MIT Instrumentation Lab that developed the AGC, so there was
no overlap in development personnel between the LVDC and AGC
systems. Furthermore, there was almost no overlap in
engineering technique, other than that both groups of necessity were
generally constrained by the technology available at the time.
For example, both needed to use memory based on ferrite-core
technology. Moreover, there was no interaction between the
LVDC and AGC systems.<br>
<br>
Actually, there was <i>some</i> interaction between the development
groups, in the sense that at some point in 1963 or before the idea
arose that the LVDC might be used in place of the AGC in the CM and
LM, and that this move might save some time and money. In
fact, IBM produced a 300+ page report detailing the differences
between the two systems with the apparent object of arguing this
point, and the MIT Instrumentation Laboratory's antibodies flooded
in to destroy the invader with critiques and reports negative of the
IBM report. In the end, the Instrumentation Lab won this
particular battle, relegating the LVDC to the relatively small share
of public attention that it presently enjoys.<br>
<br>
<div style="text-align: center;"> <img style="width: 586px; height:
354px;" alt="" src="SaturnNav-simple.jpg" width="586"
height="354"><br>
</div>
<br>
<h2><a name="Peripheral_Devices" id="Peripheral_Devices"></a>Peripheral
Devices</h2>
As with any of the other computer systems we cover here at Virtual
AGC, the LVDC does not stand alone and do its computing in a
computing vacuum (so to speak). The subsystems involved are:<br>
<ul>
<li>The Launch Vehicle Data Adapter (LVDA) interfaced the LVDC's
digital signals to the analog world of the Instrument Unit's
sensors. Actually, the LVDA is so closely coupled to the
LVDC that it may make more sense to consider them as forming a
single unit, though packaged separately.<br>
</li>
<li>The ST-124-M Inertial Platform Assembly—catchy name!—was an
inertial measuring unit that supplied the LVDC with information
about the rocket's orientation and acceleration. It had 3
integrating accelerometers that measured acceleration with
respect to the stable (space-fixed as opposed to rocket-fixed)
platform, as well as angular sensors to measure the orientation
of the stable platform with respect to the rocket. Like
the AGC IMU, it was a 3-gimbal system and therefore
theoretically subject to "gimbal lock", but because the range of
motion of the rocket during the burn phase, I suppose that
avoidance of gimbal lock must have been somewhat easier than in
the CM or LM.<br>
</li>
<li>The "Control Computer" or "Flight Control Computer" was an
analog computer that translated attitude-correction commands,
angular change, and vehicle lateral acceleration information
into propulsion-system thruster nozzle and/or engine actuator
positioning commands. As such, it is of little interest in
simulation of the LVDC (which is our primary concern at Virtual
AGC). If the naming of this device seems odd, note
that it follows the general convention of the word "control"
being defined to mean the execution of an action that has been
decided upon elsewhere, and not the act of decision-making.<br>
</li>
<li>The Control-EDS Rate Gyros.</li>
<li>The Control Accelerometers (Saturn IB only).</li>
<li>The propulsion engine actuators.</li>
<li>The auxiliary propulsion system. This was a set of 6
nozzles mounted on the aft end of the S-IVB stage which were
used to provide attitude control in coasting (non-burn)
periods. I believe that it may also have provided roll
control during the S-IVB turn during boost. (The engines
of the S-IC and S-II stages could provide complete
pitch/yaw/roll control, but the engine of the S-IVB state could
only control pitch and yaw, and therefore needed to be
supplemented to provide control of roll.) The auxiliary
propulsion system was directly controlled by the Flight Control
Computer, but the Flight Control Computer was commanded by the
LVDC.</li>
<li>Telemetry downlink.</li>
<li>Command uplink.<br>
</li>
</ul>
At the end of the preceding section was an illustration of a very
simplified logical view of the interconnection of the LVDC to
various peripherals. Here is a somewhat more complete
illustration for the Saturn IB:<br>
<br>
<div style="text-align: center;"> <img style="width: 794px; height:
600px;" alt="" src="LVDC-Peripherals.jpg" width="794"
height="600"><br>
<div style="text-align: left;"> and for the Saturn V:<br>
<div style="text-align: center;"> <img style="width: 800px;
height: 600px;" alt="" src="LVDC-Peripherals-V.jpg"
width="800" height="600"><br>
<div align="left">
<h2><a name="Interaction_with_the_AGC"
id="Interaction_with_the_AGC"></a>Saturn Interaction
with the AGC</h2>
<p>The LVDC and the AGC did not actually have any direct
interaction, so we may as well talk about how the AGC
interacted with the Saturn before immersing ourselves in
too much detail about the LVDC.<br>
</p>
<p><a href="IUFlightControlComputer.jpg"><img alt="Flight
Control Computer"
src="small-IUFlightControlComputer.png" title="Click
to enlarge" width="286" height="285" border="0"
align="right"></a><img
src="Saturn-I-Flight-Control-Computer.png" alt=""
width="400" height="285" align="right">If you look at
either of the graphics at the end of the preceding
section, you'll see the four ways that the Instrumentation
Unit (IU) in the Saturn IVB and the Spacecraft (i.e, the
Command Module) — which are separated by a horizontal
dotted line near the tops of the two graphics —
interacted:<br>
</p>
<ol>
<li>The Abort Decision signal.</li>
<li>The Status signal.</li>
<li>The Mode Command signal.</li>
<li>The Alternate Steering Commands signals.</li>
</ol>
The Saturn was always steered by the so-called Flight
Control Computer (depicted in the picture at the right), an
analog computer whose salient characteristic for our
purposes is that it was <i>not</i> the LVDC. However,
the flight-control computer did not operate on its own, and
thus itself needed to be supervised. Normally, that
supervision was performed, by default, by the LVDC,
indirectly through the LVDA, the Launch Vehicle Data
Adapter. <br>
<p>However, it was also possible for the spacecraft to send
the flight control computer a signal, the Mode Command,
which instructed it to accept Alternate Steering Commands
from the AGC rather than the default steering commands
from the LVDC/LVDA. Thus, the AGC could steer the
Saturn IVB (but not some of the other Saturn stages) by
this mechanism.<br>
</p>
<p>Of course, it was also desirable for the spacecraft to be
able to monitor the activity of the Saturn, even under
normal conditions when the LVDC was controlling the
rocket. Since the spacecraft had its own Inertial
Measurement Unit (IMU), it knew its own orientation and
acceleration — and hence the Saturn's — at all times, and
the AGC could integrate these quantities to know the
velocity and position at all times. Thus it was not
necessary for the IU to communicate that information to
the spacecraft in order for the AGC to monitor the
physical motion of the rocket and to display it for the
astronauts on the DSKY.<br>
</p>
<p>I actually have an interesting graphic of the monitoring
process to show you. This graphic is not from
physical system. Rather, Riley Rainey has used the
"equation defining document" which specified how the
Instrumentation Unit (IU) was <i>supposed</i> to behave,
to model the physical behavior of the rocket and the
spacecraft's IMU, allowing Virtual AGC to monitor the
launch behavior on a simulated DSKY. Here's a short
movie he has created of that simulation. It's
admittedly a little fuzzy, since I blew it up by about 2×,
but perhaps we'll be able to get a better one sometime in
the future:</p>
<div align="center"> <a
href="RileyRainey/ApolloA%202009-08-05%2022-43-27-68-1200x800-20.mp4"><img
alt="Riley Rainey's simulation video" title="Click to
play video" src="playRiley.jpg" width="300"
height="200" border="2"></a> </div>
<br>
Of course, at the left in the video, you can see the
simulated FDAI and DSKY. At the right, you can see
telemetry from the AGC. You'll notice that at the
beginning of the movie, the DSKY's UPLINK indicator is
on. That's apparently because Riley's simulated DSKY
(which is his own, and not the simulated DSKY we provide)
isn't fully functional in the sense of accepting keypad
input, so Riley is instead feeding the AGC commands via the
digital uplink.<br>
</div>
</div>
</div>
</div>
<h2><a name="LVDC_Documentation" id="LVDC_Documentation"></a>LVDC
Documentation</h2>
Sadly, documentation we've been able to collect for the LVDC lags
far behind that of the AGC or even that of the Abort Guidance
System, though it's getting better over time. What little
survives that we have been able to access can be found in our <a
href="links.html#LVDC">Document Library</a>.<br>
<br>
I'm also told that there are a number of published (but not
necessarily free-of-charge) research papers about the LVDC.
These may be of assistance if you're an enthusiast, but I cannot
provide any of them for you, for legal reasons. Specifically,
you can go to <a href="http://arc.aiaa.org/">the AIAA's website</a>,
and search for "LVDC". Or as another example, via the IEEE's
website, you can get an article about the "<a
href="https://ieeexplore.ieee.org/abstract/document/5388320">Interactive
Saturn Flight Program Simulator</a>", as pointed out to me by one
of the article's authors. (Thanks, Tom Dillon!)<br>
<h2><a name="LVDC_Software"></a>LVDC Software</h2>
<h3><a name="Overall_Structure"></a>Overall Structure</h3>
<p>Describing the overall structure of the software loaded into the
LVDC is a bit tricky at the present time. That's because
documentation is scarce, our cache of original LVDC software is
sparse, and the original development process seemed quite
compartmentalized. By the latter, I mean that programmers
concentrated on the specific areas to which they were assigned,
and often seem to have had little cognizance of even the most
basic features of the software when those features happened to be
outside their narrow specialization. Plus the set of LVDC
programmers available to me is limited, so I don't have
representatives of all of those specializations to consult
with. Of course, it's also possible that the many decades
between the time they spent working on the project and the time I
was able to quiz them about it may also have acted to erase some
of the information.<br>
</p>
<p>In short, important aspects of my descriptions in these sections
concerning the gross structure of the software are based on
my own inferences and on the recollections of developers not
entirely familiar with the details. So my comments about the
program structure with a large grain of salt.<br>
</p>
<p>With that said, let's contrast the overall structure of the LVDC
code vs the software source code for the Apollo Guidance Computer
(the programs <a href="Colossus.html">COLOSSUS</a>, <a
href="Luminary.html">LUMINARY</a>, and so on) and for the <a
href="yaAGS.html">Abort Guidance System</a>. All of these
non-LVDC programs were <i>monolithic</i> in nature. What I
mean by that is that although the AGC and AGS software was
structured into various semi-independent sections, for which the
development of each was presided over by specialists in those
specific areas, the source code for them was nevertheless
presented to the programmers in a single large chunk — i.e., a
single, unified program listing. Every AGC or AGS developer
saw the entire source code, regardless of whether it pertained to
them or not. The natural result was that it was possible
(and even likely) for an AGC or AGS developer to have some grasp
of the large-scale structure of the software, beyond his or her
own narrow area of specialization. Similarly, every word
stored in the AGC or AGS core memory came from that source
code. In that sense, each AGC or AGS program listing was
entirely self-contained. If you were able to assemble those
program listings, then you obtained a rope image that could be
loaded into the computer and run. Conversely, every word in
core-memory either came directly from the associate program
listing or from some action taken by the code in that program
listing. When you look at a program listing for (say)
LUMINARY, you see the <i>entire</i> contents of the Lunar
Module's AGC's core memory.<br>
</p>
<p>The overall structure of the LVDC software, however, is
fundamentally different. Simultaneously loaded into the LVDC
core memory were <i>several</i> different logically-distinct
"programs", each with <i>different</i> sets of source code,
assembled <i>separately</i> from each other, and having different
areas of specialization. Thus assembly of any given one of
these programs did not produce a full core-rope image: merely a
partial rope image. A full rope image could be obtained only
by merging all of the partial core-rope images from the different
assemblies of the several sets of source code. The separate
programs I'm aware of are discussed individually in the sections
that follow, but in brief, they were:<br>
</p>
<ul>
<li>The Preflight Program</li>
<li>The Executive Control Program</li>
<li>The Flight Program<br>
</li>
</ul>
<p>A similar situation arises in modern computer systems, where you
typically have an "operating system" program and "application
programs" running in the computer at the same time. The
application programs rely on the operating system for certain
functionality, but have no understanding of how the operating
system provides that functionality. All the application
program needs to know is the exact method for requesting the
desired function from the operating system. Similarly, the
operation system stands ready to provide the desired
functionality, but has no knowledge of the internal workings of
the application program requesting service.<br>
</p>
<p>In the LVDC, the method by which interaction between independent
but simultaneously-loaded programs worked was for there to be an
agreed-upon set of specific memory addresses hard coded into the
programs. For example, one program would know that to obtain
a certain type of service, it had to call a routine at a certain
fixed address in memory. Another program would know that it
had to put code providing certain types of services at certain
fixed addresses, but have no other knowledge of the program(s)
utilizing that functionality.<br>
</p>
<p>Because of this much higher degree of compartmentalization,
programmers working on (say) the Flight Program might have no
cognizance at all of the Preflight Program, the developers of
which might have no cognizance of the Executive Control Program,
and so on. And unfortunately, that means that <i>we</i>
don't, either.<br>
</p>
<h3><a name="Preflight_Program"></a>Preflight Program</h3>
<p>I don't know anything at all about the Preflight Program at
present. I.e., there is no surviving documentation or source
code for it as far as I know. I will provide information
about it if/when it becomes available.<br>
</p>
<p>As it relates to the <a href="#Evolution_of_the_Flight_Software">AS-206RAM
Flight Program</a>, however, I do have a couple of reasons to
believe that the AS-206RAM Flight Program would have been used in
conjunction with a Preflight Program:<br>
</p>
<ol>
<li>In the AS-206RAM Flight Program (1967), there are jumps to
various memory locations in regions of core memory at which
AS-206RAM itself does not define any code or variables. It
stands to reason that <i>something</i> is stored there. <a
href="#Evolution_of_the_Flight_Software">This is discussed in
more detail below</a>.<br>
</li>
<li>One of the original LVDC software developers (thanks, Pat
Woods!) tells me that he believes that the Flight Program shared
memory with a Preflight Program that ran before liftoff.</li>
</ol>
<h3><a name="Executive_Control_Program"></a>Executive Control
Program</h3>
<p>Original LVDC software developer Pat Woods tells me that there
was no Executive Control Program (ECP) in use until the Apollo 12
mission. This anecdotal information is backed up by the fact
that the Saturn Launch Vehicle Astrionics Systems Handbook has 14
pages of descriptive material about the ECP in its <a
href="http://www.ibiblio.org/apollo/Documents/AstrionicsSystemsHandbook_Nov69.pdf">November
15 1969 release</a> (see section 11.2.1 in particular), but does
not even mention the ECP at all in its <a
href="http://www.ibiblio.org/apollo/Documents/MSFC-IV-4-401-1-AstrionicsSystemHandbookSaturnLaunchVehicles.pdf">November
1 1968 release</a>.<br>
</p>
<p>I won't describe the ECP further here, since we have no source
code for it, but if you are interested you should consult the
later release of the Astrionics Systems Handbook mentioned above.<br>
</p>
<p>It is unfortunately not clear from the description whether the
ECP constituted a program <i>separate</i> from the Flight Program
with which it was used — i.e., whether it had a separate set of
source code that was assembled separately from the Flight Program
— or whether the two had an integrated code base that was
assembled as a single operation.<br>
</p>
<h3><a name="Flight_Program_in_General"></a>Flight Program in
General</h3>
<p>The software was apparently known simply as the Flight Program,
and didn't have a catchy name such as "Luminary".<br>
</p>
<p>You may also see references to the Generalized Flight Program
(GFP) or generalized Flight Program System, in use from Apollo 12
onward. You may recall from <a
href="#Executive_Control_Program">the preceding section</a> that
the Executive Control Program also came into use from Apollo 12
onward. My supposition would be that this simply means that<br>
</p>
<blockquote>GFP = ECP + FP<br>
</blockquote>
Was the software classified? No. Or at least it was not
classified at the time period from which we begin to have any
information. Several people associated with the development
have stated to me that it was classified. But classified
material must be stamped with one of the designations <tt>CONFIDENTIAL</tt>,
<tt>SECRET</tt>, or <tt>TOP SECRET</tt>. The available
software listing is not so stamped, and therefore should not be
considered classified. Undoubtedly IBM Federal Systems
Division considered it confidential at the time, under the common
usage of the word, but that doesn't make it classified.
<p> </p>
<h2> </h2>
<h3><a name="Evolution_of_the_Flight_Software"
id="Evolution_of_the_Flight_Software"></a>AS-206RAM Flight
Program<br>
</h3>
To a computer programmer, the most important thing about any
computer program is its source code, and at present a single
revision of the flight program is available to us. (For
non-flight software, though, see the PAST program described in <a
href="#PTC_ADAPT_Self-Test_Program">the next section</a>.)
The flight program at issue is an engineering revision of the
software, from September 1967, designated "AS-206RAM LVDC FLIGHT
PROGRAM". If you were to Google this (<b>don't do it!</b>),
you may unnecessarily excite yourself by noting that Saturn IB
launch vehicle AS-206 was used for the Skylab 2 mission
(Conrad/Weitz/Kerwin). You may then be chagrined to realize
that the Skylab 2 mission was in 1973, far past the 1967 time frame
in which this revision of the program is developed. What
gives? The answer, is that AS-206 was <i>originally</i>
intended for an unmanned mission that was canceled after the Apollo
1 fire. The software we have is not even for that canceled
early AS-206 mission, but rather for a proposed backup to the
canceled mission. So whatever software the LVDC had when
AS-206 eventually launched as Skylab 2, is not <i>this</i>
software. That doesn't alter the fact that this software is
ancestral to the versions that followed it ... or at least a very
close cousin to the ancestor of the versions following it.
There are some references in the software to AS-205, which is what
would have been Apollo 2 (the 2nd manned Apollo mission) had the
tragic Apollo 1 fire not occurred; naturally, Apollo 2 was canceled
thereafter. The designation AS-205 was <i>later</i> used
instead for Apollo 7, though considering the time-frames involved,
it's likely that the reference in the source code is to Apollo 2
rather than Apollo 7. In other words, the AS-206RAM flight
program we have had likely been branched off from the LVDC software
being developed for the never-flown Apollo 2 mission.<br>
<br>
From the preceding sections and from the date of the software,
you'll note that there is likely no Executive Control Program (ECP)
associated with this software, but that there should be a separate
Preflight Program (which we know essentially nothing about)
interacting with it through shared memory. Thus the AS-206RAM
Flight Program we have does <i>not</i> completely describe the
contents of LVDC core memory, and thus is not a complete LVDC
program as it stands. More on this below.<br>
<br>
As far as an AS-206RAM mission specifically is concerned, "RAM"
stands for Restart Alternate Mission. We have the document "<a
href="Documents/19680007324.pdf">AS-206 S-IVB RESTART ALTERNATE
MISSION LAUNCH VEHICLE OPERATIONAL FLIGHT TRAJECTORY</a>", which I
expect would be pretty invaluable in understanding the expected
operation of the flight program. To quote the document itself,<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<blockquote><small>The basic purpose of the Apollo Saturn 206 S-IVB
Restart Alternate Mission is to place the S-IVB stage into orbit
and test its restart capability, simulating the AS-501 mission
profile. In the event S-IVB restart problems occur in the early
Saturn V flights, this mission will be flown to help correct or
solve the problems. The primary objective of the SA-206 Launch
Vehicle is to insert the S-IVB/IU/Payload configuration into a
near earth 100 nautical mile circular orbit. The payload
consists of a Spacecraft LM Adapter (SLA) and a 25° Nose Cone
(NC #2).</small><br>
</blockquote>
As usual in these matters, what <i>we</i> have is not the punch
cards on which the assembly-language source code was originally
provided to the assembler program, but the "assembly listing" output
by the assembler. Unfortunately, the status of the assembly
process for it found 41 warnings and 7 errors — meaning that there
were problems in the source code and that the assembly process <i>failed</i>.
Thus the program wouldn't actually work as-is anyway, even assuming
we had an LVDC or a simulation of an LVDC in which to run it.
That doesn't reduce its instructional value any, though, and it
doesn't mean that some enterprising individual couldn't fix it up
now to make it work!<br>
<br>
<div align="center"><a href="LVDC-206RAM-teaser.jpg"><img alt=""
title="Click to enlarge" src="small-LVDC-206RAM-teaser.jpg"
width="830" height="612" border="2"></a><br>
</div>
<br>
<a name="Skype"></a>When I say "we" have a copy of this assembly
listing, however, there's an unfortunate proviso. In the U.S.
there is something called the International Traffic in Arms
Regulations (ITAR), which prevents export of certain technologies
from the U.S. except under strict controls. Under my
non-expert, non-lawyer reading of the ITAR, the LVDC would be such a
device whose export is prohibited. However, I cannot
personally figure out whether the LVDC's <i>software</i> would also
therefore be restricted. If it were restricted, then freely
providing the software online would be regarded as "exporting" it,
and would therefore also be prohibited!<br>
<p>As it happens, the source code from the assembly-listing printout
has been entirely transcribed into machine readable form.
That's a lot more convenient to deal with that scanned page
images, since you can do things like text searches on it, or even
assemble it using the nifty new LVDC assembler I've written (<a
href="LVDC.html#yaLVDCASM_the_LVDC_Cross-Assembler">see below</a>).
The problem, of course, is that the transcribed source code is
just as much subject (or hopefully, it will eventually turn out, <i>not</i>
subject) to ITAR export restrictions as the scanned images are, so
this LVDC source code is not presently available in our software
repository.<br>
</p>
Yes, I know that all sounds very silly, since there haven't been any
Saturns since 1973, so nobody is likely to load one of them up with
a warhead and fire it at anybody ... and never would have anyway,
due to the tremendous cost involved. And this software
couldn't target anything on the ground anyway, since its sole
purpose is to get stuff into orbit. Nevertheless, although the
law may be an ass (with apologies to Charles Dickens), it is still
the law. Until this uncertainty about the ITAR status of the
LVDC software is cleared up, I am forced to regard it as being
restricted. According to wikipedia, that means that I am
allowed to give it to only a "<a
href="https://en.wikipedia.org/wiki/United_States_person">United
States person</a>". Therefore, if you want the program
listing, you must obtain it from me personally and provide <a
href="https://www.uscis.gov/us-citizenship/proof-us-citizenship-and-identification-when-applying-a-job">proof</a>
that you are a United States person as just described. I will retain
a record of everyone to whom I the program listing. <br>
<br>
With all that unpleasantness out of the way, it doesn't seem to me
that suitably-abridged subsets of the assembly listing would be
restricted by ITAR, if they do not pertain to guidance, control, or
other technical aspects of the launch vehicle. <a
href="https://github.com/virtualagc/virtualagc/blob/master/yaASM.py/sample-1967.lvdc">Such
an abridged transcription of the source code does indeed appear in
our software repository</a>. The transcribed code, unlike
the full program, assembles without error and could actually be run
on an LVDC or LVDC simulator ... or at least could be run once I
flesh it out enough to do something useful. That's an evolving
effort, so feel free to take or leave the abridged LVDC code as you
see fit.<br>
<br>
(Alternately, some of the points I make in the following discussion
are probably illustrated equally well by the non-flight PAST program
discussed in <a href="#PTC_ADAPT_Self-Test_Program">the next
section</a>, which is not restricted by ITAR and hence can be
viewed in full by everybody. Unfortunately, I didn't have a
copy of the PAST program, or even know of its existence, when I
wrote the following description.)<br>
<br>
Since the abridged source code is, as I mentioned, a work in
progress, I can't really base a discussion on it without the burden
of having to update the discussion frequently. So for the sake
of discussion, let's just work with the scanned page image.
Here are various images of pages of the assembly listing that
illustrate things like how constants and variables are defined by
the software, how some standard mathematical functions are encoded,
and some of the tabular data generated by the assembler:<br>
<br>
<p align="center"><a href="LVDC-1967/LVDC-1967-057.jpg"><img
src="small-LVDC-1967-057.jpg" title="Click to enlarge" alt=""
width="320" height="240" border="2"></a> <a
href="LVDC-1967/LVDC-1967-058.jpg"><img
src="small-LVDC-1967-058.jpg" title="Click to enlarge" alt=""
width="320" height="240" border="2"></a><br>
</p>
<div align="center"><a href="LVDC-1967/LVDC-1967-273.jpg"><img
alt="" title="Click to enlarge" src="small-LVDC-1967-273.jpg"
width="320" height="240" border="2"></a> <a
href="LVDC-1967/LVDC-1967-274.jpg"><img alt="" title="Click to
enlarge" src="small-LVDC-1967-274.jpg" width="320"
height="240" border="2"></a> <a
href="LVDC-1967/LVDC-1967-275.jpg"><img alt="" title="Click to
enlarge" src="small-LVDC-1967-275.jpg" width="320"
height="240" border="2"></a> <a
href="LVDC-1967/LVDC-1967-276.jpg"><img alt="" title="Click to
enlarge" src="small-LVDC-1967-276.jpg" width="320"
height="240" border="2"></a><br>
<br>
<a href="LVDC-1967/LVDC-1967-278.jpg"><img alt="" title="Click to
enlarge" src="small-LVDC-1967-278.jpg" width="320"
height="240" border="2"></a> <a
href="LVDC-1967/LVDC-1967-279.jpg"><img alt="" title="Click to
enlarge" src="small-LVDC-1967-279.jpg" width="320"
height="240" border="2"></a> <a
href="LVDC-1967/LVDC-1967-280.jpg"><img alt="" title="Click to
enlarge" src="small-LVDC-1967-280.jpg" width="320"
height="240" border="2"></a><br>
</div>
<div align="center"><br>
<a href="LVDC-1967/LVDC-1967-310.jpg"><img
src="small-LVDC-1967-310.jpg" title="Click to enlarge" alt=""
width="320" height="240" border="2"> </a><a
href="LVDC-1967/LVDC-1967-327.jpg"><img
src="small-LVDC-1967-327.jpg" title="Click to enlarge" alt=""
width="320" height="240" border="2"></a><a
href="LVDC-1967/LVDC-1967-327.jpg"> </a><a
href="LVDC-1967/"><img alt="" src="small-LVDC-1967-more.jpg"
width="320" height="240" border="2"></a><a href="LVDC-1967/"><br>
</a></div>
<br>
There's some additional <a href="#ANATOMY">description of the
anatomy of these assembly listings</a> farther down on this page.<br>
<p>The middle group of pages above shows a few auxiliary subroutines
for computing the sine, cosine, arctangent, and spare root
functions, plus a 3×3 matrix-multiply routine. Note that
these are some of the very algorithms described in section 13 of <a
href="https://www.ibiblio.org/apollo/Documents/satinstunitibm_5.pdf">the
EDD (LVDC Equation Defining Document)</a>, so the source code
can actually be compared to the defining documentation if one so
desired. The two images at the top show an area of the
program where some constants are defined, while the two at the
bottom show a portion of the assembly listing's cross-reference
table. <br>
</p>
Additionally, each of the flown Saturns is associated with a report
known as its "launch vehicle flight evaluation report", and <a
href="links.html#lvfea">these reports are available for <i>most</i>
of the missions</a>, though there are a few gaps. Chapter 2
of each of the reports divides the mission into a set of "time
bases", called T<sub>0</sub>, T<sub>1</sub>, ..., T<sub>5</sub>, T<sub>5A</sub>,
T<sub>6</sub>, ..., T<sub>9</sub>, and each time base itself
consists of a series of events that are supposed to occur at
different times. For example, time base T<sub>0</sub> is
always the "Guidance Reference Release", and comprises events such
as "S-IC Engine Start Sequence Command", "S-IC Engine No. 1 Start",
and so on. But in general, not all missions use all of the
time bases, and the time bases aren't necessarily used for the same
thing on different missions.<sub><br>
<br>
</sub> As noted above, we're pretty sure that for Apollo 12 and
beyond, a single Generalized Flight Program (GFP) was used, but we
have no good information about preceding missions. By
examining the time bases on a mission-by-mission basis, it's
possible to roughly deduce which missions <i>may</i> have flown
with the same LVDC software (though with differing preloaded
constants) vs the missions which must necessarily have used a
different revision of the LVDC software. Thanks to Nik Beug
for pointing this out. While such an analysis has not been
done comprehensively, a rough analysis of the gross similarities in
the time bases might indicate the need for at least the following
additional LVDC software revisions other than the GFP:<br>
<ul>
<li>... prior? ...<br>
</li>
<li>AS-501 (Apollo 4)<br>
</li>
<li>AS-502 (Apollo 6)<br>
</li>
<li>AS-503 (Apollo 8)<br>
</li>
<li>AS-504 (Apollo 9)<br>
</li>
<li>AS-505 and 506 (Apollo 10-11)<br>
</li>
</ul>
<p>Regarding preloaded constants for LVDC memory, all missions (I
think!) were associated with a report called the "launch vehicle
operational flight trajectory", and these documents (among other
things) listed the LVDC preload settings. Unfortunately,
most of these reports are presently unavailable, though <a
href="links.html#Miscellaneous_Mission_Documents">we do have a
few of them</a>. For example, the AS-202 report says that
"LVDC symbol" T<sub>1i</sub>, the time-to-go for first IGM stage,
is preloaded with 299.25 sec, while Vex<sub>1</sub>, the J2
exhaust velocity for first IGM stage, is loaded with 4165.45
m/sec, and so on.<br>
</p>
<p>Finally, I claimed earlier that the AS-206RAM Flight Program is
not, of itself, a complete program. In that assessment, I'm
not referring to the fact that when you try to assemble it you
find that there are a few missing symbols, associated with
variables that haven't been allocated. <i>That</i> problem
is simply due to the fact that the listing we have is an
engineering version of the code that had never been debugged to
the point of being released. It's quite easy, I think, to
fix up the assembly-time errors and warnings in the AS-206RAM so
that it assembles error-free, and is entirely self-contained in
that sense. But it is still not complete in the larger sense
I mean.<br>
</p>
<p>Rather, when I say that AS-206RAM is incomplete, I mean that it
references code at specific hard-coded addresses which are not
defined by the AS-206RAM program. Indeed, there are large
areas of core memory left undefined by the program. Even the
location in memory at which the power-up entry point should be
stored is left undefined. But for example, consider the
concrete example of the code necessary for processing commands
uploaded to the LVDC from mission control, as described in <a
href="#Up-data">the Up-data section of this web-page</a>.
When such a command is uploaded to the LVDC, an interrupt
occurs. The software then looks in an interrupt-vector
table, which appears on p. 207 of the program listing, and looks
like the following:<br>
</p>
<p align="center"><img src="iptable206RAM.jpg" alt="" width="957"
height="242"><br>
</p>
What the interrupt-vector table contains is <tt>HOP</tt>
instructions that cause control to be transferred to the routines
for servicing the various interrupt types ... in this case, an
uploaded-command interrupt, the instruction that will be executed is
<tt>HOP HCCMDC</tt>. The symbol <tt>HCCMDC</tt> refers to a
variable that holds a HOP constant defining the location in memory
and the data-memory setup for the appropriate interrupt-service
routine, as defined on p. 20 of the listing:<br>
<br>
<div align="center"><img src="hccmdc206RAM.jpg" alt="" width="885"
height="93"><br>
<div align="left"><br>
In other words, the interrupt-service routine for a
command-upload is in memory module 4, sector 17, and its entry
point is syllable 1 of location 267. Similarly, the
data-memory environment associated with that interrupt-service
routine is module 4, sector 17.<br>
<br>
And yet ... the source code contains no code in module 4, sector
17. Indeed, module 4 sector 17 does not even appear at all
in the octal listing of the assembled AS-206RAM code. Some
initialization routines do actually <i>dynamically</i>
initialize a handful of constants in that sector, but they
certainly do not seem to put any code at those locations.
<br>
<br>
Thus if a command-upload interrupt were to occur, the result
would be that the software jumped into the middle of a no-man's
land of uninitialized memory. And it's not just the
command-upload interrupt, you can see from the image above that
other no-man's-land jumps could occur as well: to the
self-test program, to the hardware evaluation program, or upon
telemetry-station acquisition.<br>
<br>
My inference from all that is that there is a separately
assembled program which provides the code in those locations,
and <a href="#Preflight_Program">as discussed earlier</a>, the
best candidate for that at the moment is the Preflight Program
... for which we have no source code and no description
whatsoever.<br>
<br>
That's not to say that AS-206RAM cannot be run, if LVDC emulator
software were to become available. One workaround for this
specific problem is to simply modify the interrupt-vector table
to contain a <tt>HOP HCIRTN</tt> instruction in place of the <tt>HOP
HCCMDC</tt> instruction it contains now. Another
workaround would be to simply disable the command-upload
interrupt. But alas, that's just one example of the
potential range of problems the missing Preflight Program might
cause. Until a complete survey of all jumps into no-man's
land is made, it's impossible to know yet whether all of them
can be worked around so easily.<br>
<h3><a name="PTC_ADAPT_Self-Test_Program"></a>PTC ADAPT
Self-Test (PAST) Program</h3>
<p><i><a href="PTC.jpg"><img src="PTC-small.jpg" title="Click to
enlarge" alt="Programmable Test Controller" width="427"
height="351" border="2" align="right"></a></i>This
section concerns the "PTC ADAPT Self-Test Program", the only
LVDC program other than the AS206-RAM Flight Program of which
we have a copy. Since "PTC ADAPT Self-Test Program" is
quite a mouthful, I'll just refer to it as the PAST
program. Not only is that nice and short, it's also apt
since the PAST program chronologically preceded the AS206-RAM
Flight Program discussed in the preceding section. <img
src="smiley.png" alt="" width="16" height="16"> But
beware: The acronym "PAST" is mine, and doesn't come
from the contemporary Apollo documentation.<br>
</p>
<p>Strictly speaking, the PAST program is actually not "LVDC"
software, and it is certainly not <i>flight</i>
software. But it's really quite significant in spite of
that, and shouldn't be ignored if you're interested
technically in the LVDC itself, rather than merely how the
LVDC fits into the context of the launch vehicle. The
PAST program fills in an important gaps in our understanding
of the LVDC and it is technically so close to being "LVDC
software" that it's really a matter of opinion as to whether
you want to label it as LVDC software or not.
(Hint: I <i>do</i> want to call it that.) Let's
begin the explanation with a little acronym-rich terminology:<br>
</p>
<ul>
<li>The PTC ("Programmable Test Controller"), pictured to the
right, was ground-based IBM Federal Systems Division
equipment for evaluating the LVDC and/or LVDA, using either
the ADAPT or the ASTEC laboratory test equipment. <br>
</li>
<li>The ADAPT ("Aerospace Data Adapter/Processor Tester"), in
turn, was equipment to evaluate the LVDA.</li>
<li>The ASTEC ("Aerospace System Test And Evaluation Console")
was equipment to evaluate the LVDC and LVDA separately or to
evaluate the LVDC/LVDA integration.</li>
</ul>
<p><a href="Documents/19730064346_1973064346.pdf">The PTC is
documented here</a>. (<a
href="Documents/19730064186_1973064186.pdf">A tiny bit of
ADAPT and ASTEC documentation is here</a>.) This PTC
documentation includes (in Chapter 7) a printout of the
assembly listing of the PAST program and is our only-known
source for it. <br>
</p>
<p>But it's not necessary to go into great detail about the PTC,
ADAPT, and ASTEC at the moment. Indeed, for our
immediate purposes, we can ignore the ADAPT and ASTEC entirely
and the only important things to know about the PTC are:<br>
</p>
<ol>
<li>The PTC contains a CPU ... <i>which is a modified LVDC</i>.
In saying this, I don't mean that the PTC has a modified
LVDC mounted in it, but rather that the PTC's CPU is a
reimplementation (albeit modified) of an LVDC CPU.<br>
</li>
<li>The PTC's CPU runs software ... in this case, the PAST
program.</li>
</ol>
<p>In some sense, you can think of the PTC as a large LVDC that
has been fixed up to allow various kinds of debugging
activities. For example, the PTC provides support via
circuitry enabling things like single-stepping through the
software. (In the PTC documentation, see section 2-80,
"External Control Element"; section 2-216, "External Control
Logic Circuits".) It's the fact that the PTC's CPU is a
"modified" LVDC which means the PAST program is not strictly
LVDC software. Rather, it's modified-LVDC
software. Still, except for small list of differences
I'll list in a minute, the PAST program matches LVDC Flight
Program syntax. Indeed, its assembly listing has clearly
been produced by the LVDC assembler program, although there
are a few differences in the way some of the output is
formatted. In terms of how the PTC's CPU has been
"modified" relative to the LVDC, those changes are described
in detail later but here's a list of some of the differences
visible at the software level, though admittedly it may not be
too meaningful to you until you study more about how the LVDC
works (and particularly its instruction set) later on:<br>
</p>
<ul>
<li>The HOP register is parsed into fields slightly
differently.<br>
</li>
<li>LVDC CPU instructions eliminated in the PTC CPU: <tt>MPY</tt>
and <tt>MPH</tt> (both of which are multiplication
instructions), <tt>DIV</tt> (divide), and <tt>EXM</tt>
("execute modified").</li>
<li> Instructions added to the PTC but not present in
LVDC: <tt>PRS</tt> (printer operation) and <tt>CIO</tt>
(CPU i/o control).</li>
<li>Instructions that are a little different:</li>
<ul>
<li><tt>CDS</tt> (set data sector) and <tt>RSU</tt>
(reverse subtract) have the same functionality as for
LVDC, but their instruction words coded slightly
differently.</li>
<li><tt>SHF</tt> (logical shift) remains similar, but no
longer has a "clear accumulator" function and can shift by
up to 6 positions (rather than just by 1 or 2).</li>
<li><tt>XOR</tt> and <tt>RSU</tt> (reverse subract) use
different opcodes than the LVDC does, but are otherwise
identical.<br>
</li>
</ul>
<li>Other:</li>
<ul>
<li>There is a single "residual" memory sector, in memory
module 0, serving all memory modules. (Whereas the
LVDC has a separate residual sector for each memory
module.)<br>
</li>
<li>Boot: Execution begins at memory module 0, sector
0, syllable 0, location 0. (Whereas for the LVDC,
module 0, sector 0, location 0 contains an address at
which execution should begin.)</li>
<li>The assembler has a few non-LVDC pseudo-ops it
recognizes, and few LVDC pseudo-ops which it does
not. For example, the PTC has an <tt>ORG</tt>
(origin) pseudo-op where the LVDC has the
functionally-equivalent <tt>ORGDD</tt> pseudo-op. <br>
</li>
</ul>
</ul>
<p>How can I justify my claim that the PAST program is
"significant" and thus deserves your attention? There
are actually quite a few reasons to think so:<br>
</p>
<ul>
<li>As self-test software, significant chunks of the program
are devoted to testing the CPU instructions themselves;
i.e., deep, system-level self-test code which is not present
in the AS206-RAM Flight Program. In AGC terms, the
PAST program most resembles our "Validation Test Suite"
program ... except that being instead of being written by
the Virtual AGC Project (as the Validation Test Suite was,
because MIT/IL itself hadn't left us any AGC self-test
software as far as we could determine at the time), the PAST
program was actually supplied by the IBM Federal Systems
Division itself. This will obviously be very helpful
in validating any eventual LVDC CPU emulator we may be able
to come up with, since developers of emulations are always
faced with uncomfortable questions about the accuracy those
emulations. Unfortunately, experience with the AGC
suggests that the <i>most</i>-interesting CPU instructions
to check would have been the very instructions which the PTC
omits from its repertoire, and therefore the PAST software
cannot test them. But that's a minor quibble. <br>
</li>
<li>Indeed, speaking of LVDC-CPU emulation, running the PAST
program in an LVDC emulation should in some ways be even
more convenient than running an LVDC flight program, since
(as a black box) the LVDC itself has no user interface as
such, although you could consider its telemetered data
streams as being a kind of "user interface". Whereas
the PTC <i>does</i> have a user interface of sorts,
including a plotter, printer, typewriter (keyboard), various
electronic displays, and switches. Thus the learning curve
for seeing an emulated LVDC actually <i>do something</i> is
much gentler for the PAST program than it would be for an
LVDC flight program, since the normal behavior of the PAST
program is already to interact with the test
technician. <br>
</li>
<li>Nor is the PAST program a light-weight in terms of size,
being nearly 60% the size of the AS206-RAM Flight Program,
both in terms of page-count of source code and in terms of
the size of the assembled executable. The structure of
the PAST program is quite simple, which means that much of
its bulk is related to repetition and variation of simple
blocks of code rather than to complexity of software
structure. Pedagogically, I suppose you could argue
the latter point as being either an disadvantage or an
advantage, depending on your point of view.<br>
</li>
<li>And there's no question of the PAST program's "export"
being restricted by ITAR: It isn't, since it can't
even be run within the launch vehicle's computer! So
it can be freely provided to you, and you need not (please
don't!) apply personally to me to get access to it (as you
still have to do for the AS206-RAM Flight Program).
Just follow the links given below.<br>
</li>
<li>An additional bonus is that while the AS206-RAM assembly
listing we've obtained is simply a snapshot of work of
ancient work in progress, which cannot even be assembled
error-free without a bit of massaging, the PAST program is
unambiguously a mature, debugged, working program.<br>
</li>
</ul>
<p>As far as the versioning of the software, there is nothing
embedded within the assembly listing itself which dates
it. However, given that it is printed in the PTC
document mentioned above, which is dated 5 MARCH 1965, I think
we can tentatively suppose that the PAST program too is from
early 1965. (Whereas the AS206-RAM program is from late
1967.)<br>
</p>
<p>Beyond that, there's also the academic question of the
versioning of the LVDC assembler used. Both the feature
set and the format of the output is more primitive in the PAST
assembly than in the AS206-RAM assembly. For all these
reasons, it's fair to infer that an earlier version of the
assembler was used for the PTC assembly, in which various
more-advanced convenience features did not yet exist.<br>
</p>
<p>The PAST program's source code has been transcribed into
textual form, so that it can be <a
href="#yaLVDCASM_the_LVDC_Cross-Assembler">assembled</a>.
You can get that source code from our software repository:<br>
</p>
<p align="center"><a
href="https://github.com/virtualagc/virtualagc/tree/master/PTC-ADAPT-Self-Test-Program">Folder
in our GitHub repository for PAST program source-code files</a></p>
<p>I should note that while this code assembles 100% correctly —
i.e., without errors, and producing octal executables 100%
identical to those of the original scanned assembly listing —
there were nevertheless some behaviors (and perhaps bugs) of
the original assembler that I've not yet been able to figure
out how to mimic in the modern assembler. Thus to get an
assembled output identical to the original, some workaround
code consisting of a handful of <tt>ORG</tt>, <tt>DOG</tt>,
and <tt>TRA</tt> pseudo-ops and instructions have been
inserted into the source code. Hopefully it will be
possible to update the modern assembler at some point in the
future, and thus eliminate the workarounds.<br>
</p>
<p>You can also look at the scanned assembly listing created by
the Apollo-era assembler. To make it a little more
convenient to work with, I've extracted the listing from the
original scanned PTC document linked earlier, so that it can
be viewed as a set of image files, one per scanned page of the
listing:<br>
</p>
<div align="center">
<blockquote>
<p><a
href="ScansForConversion/PTC%20ADAPT%20Self-Test%20Program.zip">Zipfile
of scanned page images for the PAST program</a></p>
</blockquote>
</div>
<p>Here's a quick index to the zipfile:<br>
</p>
<ul>
<li>The source-code listing: pp. 1-171</li>
<li>The symbol table: pp. 172-220</li>
<li>The assembled octal listing: pp. 221-284</li>
</ul>
<p>These images correspond to the original PTC document's pages
434-717. In general, the entire Chapter 7
("Calibration") of that document is relevant, as it contains
detailed flowcharts for the program, in addition to operating
instructions. Chapter 2 ("Theory of Operation") contains
detailed information about the PTC CPU and its peripheral
devices.<br>
</p>
</div>
</div>
<h2><a name="Architecture_of_the_LVDC" id="Architecture_of_the_LVDC"></a>Architecture
of
the LVDC</h2>
<h3><a name="References_" id="References_"></a>References<br>
</h3>
Unlike the AGC or AGS/AEA, there is no single document or couple of
documents we've discovered so far that pull together the complete
details of how the LVDC operates. You can look at the full set
of <a href="links.html#LVDC">LVDC documents we've collected in our
document library</a>. But the specific documents helpful for
piecing together this section, none of which were originally
intended as documentation for developers, are the following:<br>
<ol>
<li>1 October 1963: <a
href="Documents/IBMStudyReport-63-928-130-Volume2.pdf"> <span
style="font-style: italic;">Apollo Study Report, Volume II</span></a>,
which was part of IBM's feasibility study for using the LVDC in
place of the AGC in the LM and CM.</li>
<li>31 October 1963: IBM's <a
href="Documents/IBM-63-928-137-SaturnVGuidanceComputer-SemiannualProgressReport.pdf"><span
style="font-style: italic;">Saturn V Guidance Computer,
Semiannual Progress Report</span></a>.</li>
<li>30 November 1964: <a
href="Documents/LaboratoryMaintenanceInstructionsForLVDC-Volume1-GeneralDescriptionAndTheory.pdf"><span
style="font-style: italic;">Laboratory Maintenance
Instructions: Saturn V Launch Vehicle Digital Computer,
Simplex Models, Volume I: General Description and Theory</span></a>.
This
is IBM's documentation for the LVDC "breadboard model II"
system. (I'm not presently aware of any existing
documentation of the production "TMR" LVDC.) <br>
</li>
<li>1 February 1966: "<a
href="Documents/TM-X-53384-TheAstrionicsSystemOfSaturnLaunchVehicles-Decher.pdf">The
Astrionics
System of Saturn Launch Vehicles</a>" by Rudolf Decher.</li>
<li>1 November 1968: <a style="font-style: italic;"
href="Documents/MSFC-IV-4-401-1-AstrionicsSystemHandbookSaturnLaunchVehicles.pdf">Astrionic
System Handbook, Saturn Launch Vehicles</a>, chapters 11 and
15.</li>
<li>1 November 1968: <a style="font-style: italic;"
href="Documents/MSFC-MAN-503-SaturnFlightManual-SA503.pdf">
Saturn Flight Manual, SA-503</a>, chapter VII, particularly
data on interrupts and i/o.</li>
<li>30 September 1972: <a
href="Documents/MSFC-MAN-206-SkylabSaturnIBFlightManual.pdf"><span
style="font-style: italic;">Skylab Saturn IB Flight Manual</span></a>,
chapter VI, again for data on interrupts and i/o.</li>
</ol>
Among these, it would be fair to state that reference #3 was used
primarily (the instruction set is covered in table 2-8 on pp. 2-16
through 2-20), and the others were used to cross-check or to provide
guidance or information missing from reference #3. (In
retrospect, however, I would recommend reference #4 as a better
starting point to those readers who don't find <i>my</i> musings
amusing, though it does not cover the instruction set.) Where
there were discrepancies between earlier documents and later
documents, the later documents were treated as definitive.
<h3><a name="General_Characteristics_of_the_Computer_"
id="General_Characteristics_of_the_Computer_"></a>General
Characteristics of the Computer<br>
</h3>
<div style="text-align: center;"> <img style="width: 1371px;
height: 771px;" alt="" src="LVDC-block-diagram.jpg" width="1371"
height="771"><br>
<br>
<div style="text-align: left;"> The illustration above shows a
simplified block diagram of the LVDC. The device itself
was designed and manufactured by IBM Federal Systems
Division. Mechanically, the LVDC had dimensions of about
29.5"×12.5"×10.5", and weighed about 72.5 pounds. A number
of different power supplies were needed: +6V, -3V, +12V,
and +20V, at roughly 150W. <br>
<br>
However, the LVDC and the Launch Vehicle Data Adapter (LVDA)
really operated as a pair, and neither is of use without the
other, so in considering the mechanical and electrical
characteristics of the LVDC one really needs to include those of
those of the LVDA into their thinking. The LVDA had
dimensions of about TBD"×TBD"×TBD", and weighed about 214
pounds. Its electrical budget was about 320W and it
accepted +28V power. The purpose of the LVDA was basically
to intermediate between the LVDC and the remainder of the
rocket.<br>
<br>
In computer terms, LVDC had the following characteristics:<br>
<ul>
<li>The computer was triply redundant, with 3 identical
circuits conforming to the block diagram shown above.
There was a "voting" circuit not shown, and any two of the 3
sub-systems could outvote the other on every output control
signal.<br>
</li>
<li>Memory was ferrite core and was entirely RAM. In
other words, there was no ROM memory as there was in the
AGC. This meant that the flight program could
theoretically be changed much closer to flight time than
could the program of the AGC, but it also meant that the
program contained within the computer could be destroyed
much more easily than with the AGC. (But remember, the
operating life of the LVDC was very short compared to that
of the AGC.) Actually, reading RAM based on ferrite
cores is inherently destructive, so every read must be
accompanied by a write-back operation to restore the
contents of memory.<br>
</li>
<li>Memory words were 28 bits, with 2 of those bits being for
parity, and thus the data portion of memory words was only
26 bits. Memory was accessed serially, at a 512K
bits/second rate, though this fact is not relevant as far as
software coding is concerned.</li>
<li>Each memory word was logically subdivided into two 14-bit
"syllables" (13 data bits + 1 parity bit), and computer
instructions were encoded in 13 bits. Therefore, each
memory word could hold two computer instructions, one in
each syllable. Data, on the other hand, required a
complete word.<br>
</li>
<li>The total amount of memory varied from mission to mission,
I believe. The LVDC could be populated with up to 8
modules of memory, with each module comprising 16 "sectors"
of 256 words each (4096 words), for a maximum of 32768
words. One word in each block wasn't memory as such
but was a mirror of the CPU's Product-Quotient Register (see
below), so the usable memory in each block was really only
4095 words. <br>
</li>
<li>Memory could be operated in two different modes, under
program control, called "simplex" and "duplex". In
"duplex" mode, the memory was divided into two banks, each
of which was an identical mirror of the other in order to
improve reliability, whereas in "simplex" mode the memory
wasn't redundant in this way (though it was still triply
redundant as mentioned above) but the number of memory words
was double. In duplex mode, the odd-numbered modules
mirrored the even-numbered modules, so that one would
typically used only modules 0, 2, 4, and 6 in duplex
mode. For the AS-206RAM LVDC Flight Program, a simplex
model was required.<br>
</li>
<li>The basic CPU clock was 2048 KHz, but computer
instructions were executed in a "computer cycle" time which
was 82.03125μs. The latter may seem like an unusual
number, but where it comes from is that each instruction
required reading/writing 3 syllables (1 holding the
instruction and 2 holding the data) of 14 bits each, with
each bit requiring 4 clocks to process. 3×14×4=168, so the
computer cycle was 168/(2.048MHz)=82.03125μs. Although
most instructions took a single computer cycle, some
instructions (particularly multiplication and division) took
longer. The longest instruction, <span
style="font-family: Courier New,Courier,monospace;">MPH</span>,
took 5 cycles. The <span style="font-family: Courier
New,Courier,monospace;">MPY</span> and <span
style="font-family: Courier New,Courier,monospace;">DIV</span>
instructions (see below) theoretically took only a single
cycle, but could only begin their operations in that amount
of time, and the results weren't accessible until later (4
cycles total for <span style="font-family: Courier
New,Courier,monospace;">MPY</span> and 8 cycles total for
<span style="font-family: Courier New,Courier,monospace;">DIV</span>).<br>
</li>
<li>Arithmetic was 2's complement, integer only.</li>
<li>There were two arithmetic units, one of which could
perform addition, subtractions, and logical operations,
whilst the other could perform multiplication and
division. The two units could be operated
independently, which is significant because multiplications
required 4 computer cycles and divisions required 8 computer
cycles, and instruction execution could continue while the
multiplication or division proceeded. In other words,
one could begin a multiplication or division, proceed to
execute some unrelated instructions, and then later fetch
the results of completed multiplication or division.<br>
</li>
</ul>
</div>
</div>
The CPU had the following additional registers not addressable as
normal memory:<br>
<ul>
<li>The Accumulator Register.</li>
<li>The Product-Quotient Register (or just P-Q Register) can be
accessed at address 0775 (octal) regardless of which memory
modules and sectors were currently selected. (This happens
to be an address in the "residual sector", as described below,
so it represents a single address in each memory module rather
than an address within each memory sector.) However, it is
used by the <span style="font-family: Courier
New,Courier,monospace;">MPY</span> and <span
style="font-family: Courier New,Courier,monospace;">DIV</span>
instructions (see below) and therefore cannot be treated as an
ordinary memory location.</li>
<li>The HOP Register, discussed further below.</li>
<li>... and various hidden registers not directly relevant to
software: the Transfer Register, the Address Register, the
Data Module Register, the Data Sector Register, the Instruction
Sector Register, the Operation Code Register, and the Memory
Buffer Registers.</li>
</ul>
There are some memory words in the "residual sector" (see below)
that are real memory (unlike 0775), but nevertheless have special
purposes and so should be avoided for general usage:<br>
<ul>
<li>0400 stores a HOP Register code (see below) for vectoring to
interrupts.<br>
</li>
<li>0600, 0640, 0700, 0740 are used for the <span
style="font-family: Courier New,Courier,monospace;">EXM</span>
instruction (see below).</li>
<li>0776, 0777 are used for the "HOP save" feature (see below).</li>
</ul>
Finally, at boot-up time:<br>
<ul>
<li>LVDC: Address 000—I believe, in module 0 sector 0 but am
not sure—stores a HOP Register code loaded at reset. <br>
</li>
<li> PTC: Execution seems to simply begin at module 0,
sector 0, syllable 0, location 0.<br>
</li>
</ul>
<h3><a name="Layout_of_Memory_Words" id="Layout_of_Memory_Words"></a>Layout
of
Memory Words</h3>
<br>
<div style="text-align: center;"> <img style="width: 896px; height:
166px;" alt="" src="LVDC-BitPositions.jpg" width="896"
height="166"><br>
</div>
<br>
The illustration above depicts the data organization within a memory
word. For numeric data, there is a sign bit (designated
"S" in the illustration), with the bit labeled "1" being the
most-significant bit and the bit labeled "25" being the
least-significant bit. For non-numeric data, the bits were
designated instead as "1" through "26", with no overlap between the
designation of the bits for numeric data. A very curious
system indeed, in modern thinking!<br>
<br>
The situation is even curiouser, to paraphrase Alice, when
considering instructions stored in the syllables in place of numeric
data. In those cases the bits are interpreted as in the
following illustration:<br>
<div style="text-align: center;"> <img style="width: 899px; height:
169px;" alt="" src="LVDC-InstructionPositions.jpg" width="899"
height="169"><br>
</div>
<br>
In the normal processing of a block of code, the syllable remains
constant. For example, if syllable 0 is currently selected,
then all of the instructions executed are in syllable 0, at
consecutive addresses, and none of the instructions in syllable 1
are processed. In particular, the instruction at syllable 1 is
<i>not</i> the next one processed after the instruction at syllable
0 ... unless of course, the instruction in syllable 0 is a <tt>TRA</tt>
or a <tt>HOP</tt> to the instruction in syllable 1! Indeed,
syllable 1 need not even store an instruction at all. Thus the
instructions stored in syllables 0 and 1 are generally unrelated to
each other, since they often belong to independent blocks of
code. Of course, it also happens <i>sometimes</i> in a long
routine that the instruction at syllable 0 may be used early in the
routine and that the instruction at syllable 1, at the same address,
may be used much later in the same routine; but don't count on it. <br>
<br>
In most cases, the bits labeled OP1-OP4 contain an instruction code
and the bits A1-A9 contain an address in the range 0-511 on which
the instruction operates. There are, however, a few
instructions in which A9 and/or A8 also form a part of the
instruction code, in which case the addressable range is
smaller. Note that bits A1-A9 are neither in consecutive order
within the memory word, nor are they in an order which would be
consistent with the ordering of bits in data words.<br>
<br>
These oddities in bit-ordering are due to the fact that memory was
read serially into the CPU, so the ordering of the bits is optimized
to mimic the order in which the CPU needed to use them.<br>
<br>
For the purpose of executing instructions, memory is considered as
being divided into "sectors" of 256 words each. Address bits
A1-A8 select an offset into a sector, while A9 (known as the
"residual bit") selects which sector is being addressed. When
A9 is 0, the currently-selected sector is being addressed, while
when A9 is 1 a special sector called the "residual sector" is being
addressed. <span style="font-style: italic;">The "residual
sector" is always sector 017 (octal)</span>, in the current memory
module for LVDC, or in module 0 for PTC. (I.e., the LVDC has a
separate residual sector in each module, whereas the PTC simply has
a single residual sector, in module 0, no matter which memory module
is selected.) Incidentally, the "residual sector" can only be
used for addressing memory, and there's no way to access
instructions in it unless it happens to be the currently-selected
instruction sector as explained in the paragraph that follows.
In essence, the "residual sector" is good for storing global
variables whilst the currently-selected data sector is good for
storing local variables.<br>
<br>
Memory-sector selection and the "residual sector" become clearer
when contemplating the HOP Register mentioned earlier. Here is
the LVDC's version of the HOP Register:<br>
<br>
<div style="text-align: center;"> <img style="width: 868px; height:
293px;" alt="" src="LVDC-HopRegister.jpg" width="868"
height="293"><br>
</div>
<br>
The PTC is simpler than the LVDC, in that it contains a maximum of 2
memory modules, and has no duplex vs simplex configuration.
The LVDC's and PTC's HOP Registers are compatible, though at first
glance it may not seem that they are, due to different numbering
conventions for the positioning — sign bit vs no sign bit — in the
images above and below. Here is the PTC's version of the HOP
Register:<br>
<br>
<div align="center"><img src="PTC-HOP.png" alt="" width="846"
height="163"><br>
</div>
<br>
The meanings of these fields may already be clear to you, but just
in case they are not:<br>
<ul>
<li>Bits IM1-IM3 (not contiguous) select the memory module from
which instructions are fetched. (Recall that there are up
to 8 memory modules installed in the LVDC. The PTC has
only 2.)</li>
<li>Bit DUPIN selects whether the portion of memory from which
instructions are fetched is accessed in duplex mode or in
simplex mode. (Recall that in duplex mode there is only
half the addressable memory as in simplex mode, because the
memory is dual-redundant and half of the memory mirrors the
other half.)</li>
<li>Bits IS1-IS4 select the 256-word sector within the selected
memory module from which instructions are fetched.</li>
<li>Bits A1-A8 (the Instruction Counter) point to the next
instruction word to be fetched from the selected sector in the
selected block.</li>
<li>Bit SYL indicates the next instruction syllable in the next
instruction word.</li>
<li>And similarly, bits DM1-DM3, bit DUPDN, and bits DS1-DS4 serve
analogous purposes except for data words rather than instruction
words.</li>
</ul>
Upon reset, the LVDC's CPU loads the HOP Register with the value
stored at address 000 (presumably in memory module 0 sector 0), and
this determines where LVDC program execution starts. The PTC's
CPU simply loads the HOP Register with a literal 000000000, so PTC
program execution always starts at 0-00-0-000.<br>
<br>
<a name="Dimitris"></a>Below are some photos sent to us by Dimitris
Vitoris of an LVDC "page assembly". Unfortunately, I don't
know exactly what this particular page assembly does, but don't be
fooled by the array-like regularity of the design into supposing
these are memory. They're not, since LVDC memory consisted of
ferrite cores and not surface-mounted flatpacks.<br>
<br>
The term <i>page assembly</i> refers to plug-in modular circuit
boards used to build the LVDC and LVDA, and not to the specific
functionality the individual module provides. Each page
assembly contains a printed circuit board with up to 35 "Unit Logic
Devices" (ULD) on the top side, and another 35 on the bottom
side. The ULDs were themselves designed by IBM, rather than
being off-the-shelf components from other manufacturers; as a
consequence, there aren't ULD datasheets floating around, and
there's not a lot of information about them. But here's a
little info we've been able to glean. Most of the explanations
about their functionality came from the "Logic Symbols" Appendix of
<a
href="Documents/LaboratoryMaintenanceInstructionsForLVDC-Volume1-GeneralDescriptionAndTheory.pdf">this
document</a>, which also describes a number of other symbols that
may or may not be ULDs as well.<br>
<ul>
<li>AA — a network which can provide several combinations of logic
functions, depending on wiring: e.g., 4 2-input AND gates,
2 4-input AND gates, etc.<br>
</li>
<li>CDR — a pull-up/down resistor.<br>
</li>
<li>CLI — TBD<br>
</li>
<li>CLN — a resistor-divider network.</li>
<li>DD — logical disagreement detector. (Detects if any 1 of
3 inputs differs from the other 2 inputs.)</li>
<li>DDI — TBD</li>
<li>FP 2412 — a pair of PNP transistors. This is technically
not a "ULD", but can be installed in a ULD location.<br>
</li>
<li>HCI — high-current inverter.</li>
<li>INV — an AND gate and a NAND gate.<br>
</li>
<li>TMV — a logical majority detector. (Output is the
majority of the 3 inputs.)<br>
</li>
<li>VI — a logical inverter, capable of driving 10 AND-get inputs.</li>
<li>VIP — TBD</li>
<li>... and presumably a number others, although the documentation
suggests that an effort was made to minimize the number of
types.<br>
</li>
</ul>
(I'm not really sure which is the best photo from Dimitris, so I've
just included them all.)<br>
<br>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="0">
<tbody>
<tr align="center">
<td style="vertical-align: top;"><a href="P9280522.JPG"><img
alt="LVDC page assembly, end view" title="Click to
enlarge" src="small-P9280522.JPG" style="border: 2px
solid ; width: 640px; height: 100px;"></a><br>
</td>
</tr>
<tr align="center">
<td style="vertical-align: top;">
<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="P9280508.JPG"><img alt="LVDC page assembly"
title="Click to enlarge"
src="small-P9280508.JPG" style="border: 2px
solid ; width: 213px; height: 160px;"></a><br>
</td>
<td style="vertical-align: top; text-align: center;"><a
href="P9280512.JPG"><img alt="LVDC page assembly,
top view" title="Click to enlarge"
src="small-P9280512.JPG" style="border: 2px
solid ; width: 213px; height: 160px;"></a><br>
</td>
<td style="vertical-align: top; text-align: center;"><a
href="P9280515.JPG"><img alt="LVDC page assembly,
top view" title="Click to enlarge"
src="small-P9280515.JPG" style="border: 2px
solid ; width: 213px; height: 160px;"></a><br>
</td>
<td style="vertical-align: top; text-align: center;"><a
href="P9280516.JPG"><img alt="LVDC page assembly,
top view" title="Click to enlarge"
src="small-P9280516.JPG" style="border: 2px
solid ; width: 213px; height: 160px;"></a><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
<h3><a name="CPU_Instructions" id="CPU_Instructions"></a>CPU
Instructions</h3>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th><br>
<br>
Mnemonic<br>
</th>
<th><br>
A<br>
8<br>
</th>
<th><br>
A<br>
9<br>
</th>
<th>O<br>
P<br>
4<br>
</th>
<th>O<br>
P<br>
3<br>
</th>
<th>O<br>
P<br>
2<br>
</th>
<th>O<br>
P<br>
1<br>
</th>
<th style="vertical-align: top; text-align: center;"> Timing<br>
(computer<br>
cycles)<br>
</th>
<th><br>
<br>
Description of the instruction<br>
</th>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> HOP<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td>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;">CDS</span> and <span
style="font-family: Courier New,Courier,monospace;">TRA</span>.<br>
<br>
Although the machine instruction requires the address of the
HOP constant to be provided as its operand, the assembler is
flexible enough to allow the operand to instead be a
left-hand symbol for the target location in the code.
When it encounters this situation, the assembler
transparently performs a workaround. For the sake of
discussion, imagine assembly-language code something like
the following:<br>
<blockquote><tt> </tt><tt>HOP
HIGTHR<br>
.<br>
.<br>
.<br>
HIGTHR ... <i>more code</i> ...<br>
</tt> </blockquote>
What the assembler does in a case like this is:<br>
<ul>
</ul>
<ol>
<li><strike>If the target address </strike><strike>is in
the current instruction-memory sector (either in the
same or the opposite syllable), transparently replace
the </strike><strike><tt>HOP</tt></strike><strike>
instruction by a </strike><strike><tt>TRA</tt></strike><strike>
instruction. Otherwise, proceed to step 2.</strike><strike><br>
</strike> </li>
<li>Allocate a data word in the current data sector.
Do this by searching upward in the data sector, looking
for the first unused location. The residual sector
is searched if there's no room left in the current
sector.<br>
</li>
<li>Create a HOP constant for the target location<tt></tt>,
and store it in the newly-allocated data word.</li>
<li>Use the address of the newly-allocated data word as
the operand for the <tt>HOP</tt> instruction.</li>
</ol>
Whenever such a substitution was performed by the assembler,
it noted it in the assembly listing by printing "<tt>HOP*</tt>"
as the name of the instruction rather than "<tt>HOP</tt>" as
what would have been used on the actual punch card.
<ul>
</ul>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> MPY<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td style="text-align: center;">1<br>
(results<br>
available after 4)<br>
</td>
<td>LVDC only ... <i>not</i> PTC.<br>
<br>
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. A partial product (24 bits from the
addressed memory times the 12 less-significant bits from the
accumulator) can be fetched from the P-Q Register (0775
octal) on the 2nd instruction (or more accurately, two
computer cycles) following <span style="font-family:
Courier New,Courier,monospace;">MPY</span>, though there
is no need to do so if that value isn't desired by the
program. The full product is available from the
accumulator or from the P-Q Register on the 4th instruction
(more accurately, 4 computer cycles) following <span
style="font-family: Courier New,Courier,monospace;">MPY</span>.
However,
the result will remain in the P-Q register until the next <span
style="font-family: Courier New,Courier,monospace;">MPH</span>,
<span style="font-family: Courier New,Courier,monospace;">MPY</span>,
or <span style="font-family: Courier
New,Courier,monospace;">DIV</span>. </td>
</tr>
<tr>
<td valign="middle"><font face="Courier New, Courier,
monospace">PRS</font><br>
</td>
<td valign="middle"><br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle" align="center">TBD<br>
</td>
<td valign="middle"><a name="PRS"></a>PTC only ... <i>not</i>
LVDC<br>
<br>
This is a "print store" operation. Here's what <a
href="Documents/19730064346_1973064346.pdf">the PTC
documentation (see p. V-2-22)</a> has to say about
it: Initiates a printer operation. That rather
laconic description is trying to tell you that the <tt>PRS</tt>
instruction can send either 4 or 12 characters to the
printer peripheral, for printing.<br>
<br>
In assembly language, the operand of the instruction is
always a literal 3-digit octal number or else a symbolic
label representing a memory address in the range 000<sub>8</sub>
to 773<sub>8</sub>. Recall that addresses in the range
400<sub>8</sub> to 777<sub>8</sub> refer to addresses 400<sub>8</sub>
to 777<sub>8</sub> in the residual memory sector. <br>
<blockquote>
<table cellspacing="2" cellpadding="2" align="center">
<tbody>
<tr>
<td valign="middle" align="center"><u>Address</u><br>
</td>
<td valign="middle" align="center"><u>Operation</u><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">000<sub>8</sub>
to 773<sub>8</sub><br>
</td>
<td valign="middle">Data word in the specified
memory address specified is transferred to the
printer <i>and</i> to the accumulator.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">774<sub>8</sub><br>
</td>
<td valign="middle">A group mark is sent to the
printer.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">775<sub>8</sub><br>
</td>
<td valign="middle">Data word in the accumulator is
transferred to the printer.<br>
</td>
</tr>
</tbody>
</table>
</blockquote>
See also the discussion of the <a href="#BCI"><tt>BCI</tt></a>
pseudo-op, farther down on this page, which is a convenient
way in assembly language to encode memory-operand data for <tt>PRS</tt>.<br>
<br>
Each <tt>PRS</tt> instruction conveys 26 bits of data to
the printer, and that 26-bit word is capable of encoding
either 4 or 12 characters. The number of characters
encoded depends on whether the printer is in "octal mode"
(activated by the <tt>CIO 164</tt> instruction) or "BCD
mode" (activated by the <tt>CIO 170</tt> instruction). The
term "BCD mode" is a misnomer, in modern terms, since it
would seem to imply that it covers only Binary Coded
Decimals, whereas in fact it covers the complete repertoire
of printable characters. Besides those, see also <tt>CIO
160</tt>, which conveys certain control commands to the
printer.<br>
<br>
In octal mode, the 26 data bits comprise 8 octal character
encoded as 3 bits each (000="0", 001="1", ..., 111="7"),
plus a single "2-bit character", plus three blanks (which
are always present, and thus require no bits to
encode). So far, I've found no written explanation of
what these "2-bit characters" are, but due to the way 26-bit
data words are invariably represented in LVDC/PTC assembly
listings — namely, as 9 octal digits with the final one
being <i>even</i> — I feel confident that the 9th character
is encoded as 00="0", 01="2", 10="4", 11="6". <br>
<br>
In BCD mode, the 26 data bits comprise 4 6-bit character
code, left-aligned in the data word. In other words,
the first character's most-significant bit appears at the
SIGN bit of the 26-bit word. The least-significant 2
bits of the data word are not used as far as I can
tell. (That's a pity, because it seems to me that it
would be reasonable to use them to indicate <i>how many</i>
characters the word contained, rather than just always being
4. Alas, that doesn't seem to be the case.) The
6-bit encoding scheme, called "BA8421", is covered in the
discussion of the <a href="#BCI"><tt>BCI</tt></a>
pseudo-op.<br>
<br>
The <tt>PRS</tt> instruction has a side effect: It
overwrites the interrupt latch. This potentially
triggers interrupts if not inhibited; or, more usefully, the
interrupt latch can be read back using the <tt>CIO 154</tt>
instruction for self-test purposes. Which particular
bits are set depends on which characters are being
printed. I can't give you too satisfactory a rationale
as to the particular bit patterns used. Nor are they
documented (unless they can be deduced from the 2nd-level
schematics, which I've failed at so far). So all I can
do is infer the bit patterns from how the PAST program
source code uses them. But take what I say with <i>a
<u>big</u> grain of salt</i>, because there's no unique
way of making these inferences! With that said, here
are the rules for deriving the interrupt-latch patterns that
I've built into the PTC emulation software. The bit
patterns are all 12-bit codes (stored in SIGN and bits 1-11
of the interrupt latch) as follows:<br>
<ul>
<li>A group mark (<tt>CIO 774</tt>): 0047<sub>8</sub>
</li>
<ul>
</ul>
<li>Character data (<tt>CIO 775</tt>, or <tt>CIO 000</tt>
through <tt>CIO 773</tt>):</li>
<ul>
<li>Bits SIGN, 1-5: Logical OR, bitwise, of the
6-bit BA8421 codes for all characters encoded in the
data. In octal mode, this is additionally OR'd
with 12<sub>8</sub>.<br>
</li>
<li>Bit 6: Parity bit. Computation of this
can't be easily described concisely, so there's an
extended explanation below.<br>
</li>
<li>Bits 7-11: 03<sub>8</sub>.</li>
<li>Bits 12-25: 0.</li>
</ul>
</ul>
<p>The parity bit for character data appears to be an odd
parity bit for the <i>most-recently</i> processed
character of the 4 (BCD mode) or 12 (octal mode) encoded
in the 26-bit data word at the time <tt>CIO 154</tt> is
issued to read back the interrupt latch. The
characters are processed sequentially after the <tt>PRS</tt>
instruction is executed. The 4 characters in BCD
mode can be processed within a single CPU instruction
cycle, but the 12 characters in octal mode cannot be, and
require two instruction cycles to fully process. I
think that the timing for this processing is not
synchronized with the CPU clock, and indeed has some
tolerance in terms of frequency, so that it cannot be
known deterministically how many characters have been
processed until enough machine cycles have elapsed to
guarantee that <i>all</i> characters have been
processed. I suspect that's why all octal-mode <tt>PRS</tt>
test cases in the PAST program consist of strings of
characters having all the <i>same</i> parity; that way,
it doesn't matter which specific character has just been
processed, because the parity of each character is the
same anyway.<br>
</p>
<p>This leaves many questions unanswered about the precise
original behavior of the PTC panel. Therefore,
ignoring the original behavior and thinking just in terms
of how the PTC <i>emulation</i> implements the parity in
the face of this indeterminacy, I recognize 3 distinct
cases:<br>
</p>
<ol>
<li>Immediate readback. In this case the emulation
returns the parity for the 2nd character in the data
word:</li>
</ol>
<blockquote>
<blockquote><tt>PRS <i>something</i></tt><tt><br>
</tt><tt>CIO 154</tt><br>
</blockquote>
</blockquote>
<ol start="2">
<li>Readback after 1 machine cycle. In this case,
the emulation returns the parity for the 7th character
in the data word in octal mode, or simply the last of
the 4 characters in BCD mode:</li>
</ol>
<blockquote>
<blockquote><tt>PRS <i>something</i></tt><tt><br>
</tt><i><tt>... a single instruction to expend 1 machine
cycle ...</tt></i><tt><br>
</tt><tt>CIO 154</tt><br>
</blockquote>
</blockquote>
<ol start="3">
<li>Readback after 2 or more machine cycles. In this
case, the emulation returns the parity for the final
character. In BCD mode that's pretty
straightforward, but in octal mode the interpretation of
"final" will depend on what has previously been done
with the <tt>CIO 250</tt> instruction. If <tt>CIO
250</tt> has been used to inhibit the check bit for
the 3 implicit blank spaces, then the "final" character
will be the last character <i>explicitly</i> encoded in
the data word, namely the octal digit encoded with just
2 bits. Conversely, if those check bits have not
been inhibited, then the parity will be that of an
implicit blank space, namely 1.<br>
</li>
</ol>
<blockquote>
<blockquote><tt>PRS <i>something</i></tt><tt><br>
</tt><i><tt>... 2 or more instructions to expend 2 or
more machine cycles ...</tt></i><tt><br>
</tt><tt>CIO 154</tt><br>
</blockquote>
</blockquote>
Any intervening <tt>CIO</tt> or <tt>PIO</tt> instructions
that result in a modification of the interrupt latch will
prevent the parity-check bit from appearing in <tt>CIO 154</tt>.<br>
<blockquote>
<blockquote> </blockquote>
</blockquote>
<ul>
<ul>
</ul>
<ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> SUB<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td>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>
Regarding borrow from the operation, the CPU provides no
direct way of accessing it, and thus no easy way to perform
multi-precision subtraction. Refer to the notes for
the <tt>ADD</tt> instruction for more information.<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> DIV<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td style="text-align: center;">1<br>
(results<br>
available<br>
after 8)</td>
<td>LVDC only ... <i>not</i> PTC.<br>
<br>
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 in the P-Q Register
(0775 octal) on the 8th instruction (more accurately, 8
computer cycles) following the <span style="font-family:
Courier New,Courier,monospace;">DIV</span>. However,
the result will remain in the P-Q register until the next <span
style="font-family: Courier New,Courier,monospace;">MPH</span>,
<span style="font-family: Courier New,Courier,monospace;">MPY</span>,
or <span style="font-family: Courier
New,Courier,monospace;">DIV</span>.</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> TNZ<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td>This is a conditional jump instruction, which branches to
the address embedded in the instruction if the accumulator
is not zero, but simply continues to the next instruction in
sequence if the accumulator is zero. Bits A1-A8 of the
embedded address represent the new offset within the
currently selected 256-word instruction sector, while bit A9
gives the syllable number within that word. The
"residual sector" cannot be accessed. See also <span
style="font-family: Courier New,Courier,monospace;">TMI</span>.<br>
<br>
As mentioned, the target address for the machine instruction
itself had to be within the current sector, because its
8-bit address offset is embedded within the
instruction. However, the assembler would
transparently work around this problem, allowing essentially
<i>any</i> target address to be used. For the sake of
discussion, imagine an assembly language instruction,<br>
<blockquote><tt>TNZ OINIT</tt><br>
</blockquote>
in which the target location <tt>OINIT</tt> is not in the
current memory sector. The workaround procedure used
by the assembler was this:<br>
<ol>
<li>Working downward from the top of the current
instruction-memory sector, find an unallocated memory
location.</li>
<li>In that newly-allocated memory location, put a "<tt>HOP
OINIT</tt>" instruction.</li>
<li>Use the newly-allocated memory location as the target
of the <tt>TNZ</tt> instruction.</li>
<li>In the assembly listing, display the operator as "<tt>TNZ*</tt>"
rather than "<tt>TNZ</tt>". (But "<tt>TNZ</tt>" is
nevertheless what actually appeared on the punch cards.)<br>
</li>
</ol>
Of course, this workaround preserves the intended logic, at
the cost of an extra instruction word and a couple of extra
machine cycles.<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> MPH<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td style="text-align: center;">5<br>
</td>
<td>LVDC only ... <i>not</i> PTC.<br>
<br>
This is a multiplication instruction. It is exactly
like <span style="font-family: Courier
New,Courier,monospace;">MPY</span> except that the program
"holds" until the multiplication is complete, so that the
product is available from the accumulator or from the P-Q
Register at the next instruction following <span
style="font-family: Courier New,Courier,monospace;">MPY</span>.
However,
the result will remain in the P-Q register until the next <span
style="font-family: Courier New,Courier,monospace;">MPH</span>,
<span style="font-family: Courier New,Courier,monospace;">MPY</span>,
or <span style="font-family: Courier
New,Courier,monospace;">DIV</span>.<br>
</td>
</tr>
<tr>
<td valign="middle"><font face="Courier New, Courier,
monospace">CIO</font><br>
</td>
<td valign="middle"><br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle" align="center">TBD<br>
</td>
<td valign="middle">PTC only ... <i>not</i> LVDC. There
is no LVDC equivalent for this instruction, which can be
viewed as a way of extending the LVDC/PTC <tt>PIO</tt>
instruction (see below) to a wider range of uses.<br>
<br>
Here's what the original PTC documentation has to say about
<tt>CIO</tt>:
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
"Controls the input, output operations of the CPU. The
operand address bits specify the operation to be
performed." <br>
<br>
<a href="#IO_Ports_for_PTC_CIO_Instruction">A list of the <tt>CIO</tt>
i/o ports is given below</a>. As far as I know, only
ports 154, 214, and 220 are for input, and they load the
accumulator when used. Other ports are for output
only, and the accumulator should to be loaded, prior to the
<tt>CIO</tt> itself, with any additional data the specific
operation requires, but is not affected by the
operation. Note that most output operations do not
require any such supplemental data, and therefore ignore
whatever value is stored in the accumulator. Many of
the operations relate to inhibiting or enabling interrupts
(as you can see from the table above!), sending commands to
the PTC's printer or plotter, etc.<br>
<br>
In assembly language, the operand of the instruction is
always a literal 3-digit octal number.<br>
<p>
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
</p>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> AND<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td>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".</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> ADD<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;">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>
What about the carry bit? As far as I can tell, the
CPU has no provision for carry bit that's useful at the
software level. If you want to do multi-word precision
arithmetic (say, 52-bit addition instead of just 26-bit
addition), then you have to find some indirect,
software-only way of detecting carry rather than on relying
on the CPU to provide you with some easy way of handling
it. It's certainly mathematically possible to do
so: When adding two addends of the <i>same</i> sign
using 2's-complement arithmetic, you can detect carry
because the sum has the opposite sign of the addends,
whereas adding two addends of <i>opposite</i> signs cannot
result in carry anyway. But the coding to exploit this
mathematical possibility is obviously going to be cumbersome
and inconvenient. (The low-level adder circuit itself
can deal with a carry bit, of course. The adder
performs additions serially, starting with the
least-significant bit and moving upward to the
most-significant, and at each bit-stage there's a carry bit
from the previous stage to worry about. However, the
final carry bit is not accessible to software, and the
carry-bit latch is cleared by any <tt>CLA</tt> instruction,
making it very tough to transfer the carry-bit latch's
contents from one word-addition to the next. In
theory, if you could figure out a way to do multi-precision
arithmetic without using <tt>CLA</tt>, perhaps you could
exploit that hidden carry bit. But I'm having trouble
seeing any way you might do it. That could just be my
failure of imagination, of course.)<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> TRA<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;"><tt>TRA</tt> is an
unconditional jump instruction, which branches to the
address embedded in the instruction. Bits A1-A8 of the
embedded address represent the new offset within the
currently selected 256-word instruction sector, while bit A9
gives the syllable number within that word. The
"residual sector" cannot be accessed.<br>
<br>
Note, however, that the <i>assembler</i> transparently
worked around the limitation that the target address had to
be in the same sector. The assembler would
automatically insert a <tt>HOP</tt> instruction instead of
a <tt>TRA</tt> whenever it found that it was necessary to
do so. For example, consider the instruction "<tt>TRA
ETCBTC</tt>". If the target location <tt>ETCBTC</tt>
is within the current instruction sector, the assembler
would indeed assemble this exactly as expected, using a <tt>TRA</tt>
instruction with opcode <tt>1000</tt>. Actually, the
assembler would refuse to directly do a <tt>TRA</tt> to a
target in the same instruction sector under some
circumstances, presumably to help guard the programmer from
easy-to-make errors. The condition I've noticed in
which this occurs is if the target address has been tagged
by the assembler as being in a region with a different
setting for the <i>data</i> module or sector, since unlike
a <tt>HOP</tt> instruction, a <tt>TRA</tt> instruction
doesn't alter the DM/DS settings. Whereas if a <tt>CDS</tt>
instruction (which changes the DM/DS settings in the
processor itself) happens to be at the target location, it
doesn't trigger a replacement by <tt>HOP</tt>. Quite
a complicated set of conditions! One wonders if the original
programmers actually had much awareness at the time (or
cared!) that these substitutions were being made for them.<br>
<br>
But if the target location (<tt>ETCBTC</tt> in this example)
wasn't within the current instruction sector or failed the
DM/DS conditions, then the assembler would instead perform
the following complicated maneuver which preserves the
expected program logic, at the cost of an extra machine
cycle and an extra word of memory:<br>
<ul>
<li>Allocate a data word in the current data sector.
This is done by searching upward through the current
data sector (or the residual sector, failing that) until
an unallocated word is found.<br>
</li>
<li>Create a HOP constant for the target location <tt>ETCBTC</tt>,
and store it in the newly-allocated data word.</li>
<li>Assemble a <tt>HOP</tt> instruction with the
newly-allocated data word as its operand.</li>
<li>Whenever such a substitution was performed by the
assembler, it noted it in the assembly listing by
replacing "<tt>TRA</tt>" with "<tt>TRA*</tt>".
However, I think that "<tt>TRA</tt>" is always what
would have originally been used on the punch card.</li>
<li><i>Workaround for PTC</i>: For the PTC version
of the original assembler, I've unfortunately been
forced to provide hints to the modern assembler
(yaASM.py) by <i>explicitly</i> using "<tt>TRA*</tt>"
in the source code when necessary. With either of
"<tt>TRA</tt>" or "<tt>TRA*</tt>", the modern assembler
provides a behaviorally-correct fixup, but when "<tt>TRA</tt>"
is used rather than "<tt>TRA*</tt>", the
automatically-allocated memory words are at different
addresses than originally, thus preventing validation of
the assembler. Deducing the original PTC algorithm
and thus allowing universal use of "<tt>TRA</tt>" in PTC
source code is a reverse-engineering problem I have been
unable to solve so far. (Although, for all <i>I</i>
know, the PTC programmers may themselves have had to
explicitly use "<tt>TRA*</tt>" as well. There's no
available original documentation to answer that question
one way or the other.)</li>
</ul>
This in so far as the assembly-language source code is
concerned, it seems that one may as well always use <tt>TRA</tt>
rather than <tt>HOP</tt>, since <tt>TRA</tt> is more
economical than <tt>HOP</tt>, and the assembler will always
substitute <tt>HOP</tt> anyway whenever some limitation of
<tt>TRA</tt> necessitates it.<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> XOR<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>1<br>
1<br>
</td>
<td>0<br>
1<br>
</td>
<td>0<br>
0<br>
</td>
<td>1<br>
1<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;">Logically exclusive-ORs 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>
<b>Note</b>: The opcode bits for <tt>XOR</tt> are 1001 (11<sub>8</sub>)
for LVDC, but 1101 (15<sub>8</sub>) for PTC. However,
the PTC documentation <i>incorrectly</i> indicates that the
coding is 1001. (Either that, or the assembler
assembled the instruction incorrectly; take your pick of
explanations.)<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> PIO<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;">Reads or writes an i/o
port. Bits A1-A9 select the source and
destination of the i/o. A table of the i/o ports
vs. addresses is given in the <a
href="#IO_Ports_For_PIO_Instruction">following section</a>.<br>
<br>
In so far as assembly-language syntax is concerned, the
operand of the instruction is always a literal octal
numerical constant.<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> STO<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;"> 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 following addresses are
special, as described in <a
href="Documents/LaboratoryMaintenanceInstructionsForLVDC-Volume1-GeneralDescriptionAndTheory.pdf">the
documentation of the STO instruction (see p. 2-17)</a>:<br>
<ul>
<li>Residual sector, location 0375<sub>8</sub> (often
referred to simply as 775):</li>
<ul>
<li>LVDC: Stores into the Product-Quotient
register rather than to normal memory.</li>
<li>PTC: Just a normal memory store (into 0375<sub>8</sub>
of the residual sector).<br>
</li>
</ul>
<li>Residual sector, locations 0376<sub>8</sub> and 0377<sub>8</sub>
(often referred to simply as 776 and 777):</li>
<ul>
<li> LVDC:</li>
<ul>
<li>During a multiplication or division operation,
stores the contents of the Multiplicand-Divisor
register (rather than the accumulator) to the
selected address.</li>
<li>Otherwise (i.e., normally), store the contents of
the (otherwise inaccessible) HOP-saver register to
the selected address.<br>
</li>
</ul>
<li>PTC: Store the contents of the (otherwise
inaccessible) HOP-saver register to the selected
address.<br>
</li>
</ul>
</ul>
<p>The LVDC and PTC cases appear to be very different, but
the difference is really just that the PTC has no
multiplication and division instructions, and hence has no
product-quotient or multiplicand-divisor register.<br>
</p>
<p>Nevertheless, the description of 776 and 777 above is
admittedly a bit tricky to understand, so let's try to get
at it another way. It's mainly about return
addresses for subroutines and interrupt-service
routines. Most modern CPU's have a "CALL"
instruction for calling subroutines, and part of what CALL
would do is to push the return address onto a dedicated
"stack" in memory; a subsequent "RET" instruction would
then pop the return address out of the stack and jump to
that return address. But the LVDC/PTC CPU has no
such features ... no CALL, no RET, no stack. What it
does instead is this: During the process of
executing any given LVDC/PTC instruction, a HOP constant
for the LVDC instruction at the <i>next successive memory
address</i> is formed. Keep in mind that the next
instruction successively in memory is not necessarily the
next instruction sequentially executed. Whatever the
next instruction executed, the previously-generated HOP
constant is temporarily shoved into a register called
"HOP-saver". Thus if the very next instruction <i>executed</i>
after a transfer instruction (<tt>HOP</tt>, <tt>TRA</tt>,
<tt>TMI</tt>, or <tt>TNZ</tt>) is <tt>STO 776</tt> or <tt>STO
777</tt>, what ends up getting stored in location 776 or
777 is the HOP constant for the memory address that
follows the previously executed transfer instruction
instruction in memory. Or in brief, for a transfer
instruction to a subroutine, what gets saved at 776 or 777
is the return address of the subroutine. In fact,
this is the only easy method for accessing such return
addresses, and the only way at all for accessing return
addresses of interrupt-service routines.<br>
</p>
As an example, here's a simple framework for calling an
LVDC/PTC subroutine:<br>
<blockquote><tt>
...<br>
HOP
SUB
# Call a subroutine.<br>
...<br>
<br>
# The subroutine.</tt><br>
<tt> SUB
STO
776
# Save the return address.</tt><br>
<tt> </tt><tt>
...
# ... do stuff ...</tt><br>
<tt> </tt><tt>HOP
776
# Return from SUB.</tt><br>
</blockquote>
<tt> </tt>This becomes trickier if you have <i>nested</i>
subroutine calls, because the nested routines can't each use
the same storage buffers for their return addresses, and
there's no way to temporarily replace the contents of
776/777 while still being able to restore the original
contents afterward. (You can certainly <i>read</i>
776/777, for example with <tt>CLA 776</tt>, but you can't
save an arbitrary value into either 776 or 777
afterward.) In other words, if you have a nested
subroutine, you have to manage the return address of the
parent subroutine manually. Here's an example I've
constructed to illustrate the method:<br>
<blockquote>
<p><tt> ...<br>
HOP
SUB
# Call a subroutine.<br>
...<br>
</tt></p>
<p><tt>SUBRET BSS
1
# Variable for saving a return address.<br>
# A subroutine.<br>
SUB
STO
776
# Save the return address.<br>
CLA
776
# Move the return address to SUBRET,<br>
STO
SUBRET
# thus freeing up 776.<br>
...<br>
HOP NESTED
#
Call a nested subroutine.<br>
...<br>
HOP SUBRET
#
Return from SUB.</tt></p>
<p><tt># Another subroutine, called by SUB.<br>
NESTED STO 776<br>
...<br>
HOP 776
#
Return from NESTED.<br>
</tt></p>
</blockquote>
You can, of course, perform the same trick with multiple
levels of nesting, at the cost of allocating more and more
variables to store the manually-managed return addresses.<br>
<br>
It is perhaps obvious as well that the same address (776 vs
777) should not be used for interrupt-service routines and
and for regular subroutines, even for the few instruction
cycles needed for manual management, or else tremendous care
needs to be taken to insure that no interrupt can occur
during a subroutine with conflicting storage requirements
for the return addresses. The safest thing would be to
use 776 for interrupt-service routines (and their
subroutines) and 777 for non-interrupt subroutines, or
vice-versa. In examining the PTC ADAPT Self-Test
Program and the AS206-RAM Flight Program, the two seem to
use the opposite choice, so there may not have been a
customary standard for doing so from one program to the
next.<br>
<blockquote>
<p> </p>
</blockquote>
<ul>
</ul>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> TMI<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;">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-A8
of the embedded address represent the new offset within the
currently selected 256-word instruction sector, while bit A9
gives the syllable number within that word. The
"residual sector" cannot be accessed. See also <span
style="font-family: Courier New,Courier,monospace;">TNZ</span>.<br>
<br>
As mentioned, the target address for the machine instruction
itself had to be within the current sector, because its
8-bit address offset is embedded within the
instruction. However, the assembler would
transparently work around this problem, allowing essentially
<i>any</i> target address to be used. The workaround
used by the assembler is that same as that described for the
<tt>TNZ</tt> instruction above. Instructions for which
the workaround have been applied are shown on the assembly
listing as "<tt>TMI*</tt>" rather than "<tt>TMI</tt>".<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> RSU<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>1<br>
0<br>
</td>
<td>1<br>
0<br>
</td>
<td>0<br>
1<br>
</td>
<td>1<br>
1<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;">Same as SUB, except that the
order of the operands in the subtraction is reversed.<br>
<br>
<b>Note</b>: The opcode bits for <tt>RSU</tt> are 1101 (15<sub>8</sub>)
for LVDC, but 0011 (03) for PTC. (0011 in LVDC is for
the <tt>DIV</tt> instruction, which is missing from PTC.)<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> CDS<br>
<i><font face="Helvetica, Arial, sans-serif">or</font></i><br>
CDSD<br>
<i>or</i><br>
CDSS<br>
</td>
<td><br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;"> LVDC only ... <i>not</i>
PTC.<br>
<br>
Change the currently-selected 256-word data sector.
For this instruction, A9 forms a part of the instruction
itself, so only A1-A8 are significant. The partially
overwrite the HOP Register as follows:<br>
<br>
<div style="text-align: center;"> <img style="width: 345px;
height: 283px;" alt="" src="LVDC-CdsInstruction.jpg"
width="345" height="283"><br>
<div style="text-align: left;"> <br>
See also <span style="font-family: Courier
New,Courier,monospace;">HOP</span>.<br>
<br>
In terms of assembly-language syntax, there are the
following variations:<br>
<blockquote><tt>CDS <i></i><i>SYMBOLNAME</i></tt><tt><br>
</tt><tt>CDSD <i>DM,DS</i></tt><tt><br>
</tt><tt>CDSS <i>DM,DS</i></tt><br>
</blockquote>
Thus <tt>CDS</tt> uses the characteristics of a
variable name or a name defined with the <tt>DEQD</tt>
or <tt>DEQS</tt> pseudo-ops (see below), whereas the
module number and sector number are simply supplied with
octal numeric literals in <tt>CDSD</tt> or <tt>CDSS</tt>.
The difference between <tt>CDSD</tt> and <tt>CDSS</tt>
is that the former selects duplex memory while the later
selects simplex memory.<br>
<br>
In the usage I've seen, usage of <tt>CDSS</tt> is
confined almost entirely to the context of <tt>USE DAT</tt>
(see below).<br>
</div>
</div>
</td>
</tr>
<tr>
<td valign="middle"><font face="Courier New, Courier,
monospace">CDS</font><br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle" align="center">TBD<br>
</td>
<td valign="top">PTC only ... <i>not</i> LVDC. This
functionally identical to the identically-named LVDC
instruction above, but is slightly different both
syntactically and in the encoding of the assembled
instruction.<br>
<br>
Changes the currently-selected 256-word data sector by
partially overwriting the HOP Register as follows:<br>
<br>
<div align="center"><img alt="" src="PTC-CDS.png"
width="313" height="157"><br>
</div>
<br>
See also <span style="font-family: Courier
New,Courier,monospace;">HOP</span>.<br>
<br>
In terms of assembly-language syntax:<br>
<blockquote><tt>CDS <i>DM,DS</i></tt><br>
</blockquote>
<i><tt>DM</tt></i> is limited to 0 or 1, while <i><tt>DS</tt></i>
is an octal literal from 0 to 17.<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> SHF<br>
</td>
<td>0<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;"> LVDC only ... not PTC.<br>
<br>
Performs a shift operation on the accumulator. For
this instruction, bits A8 and A9 form a part of the
instruction itself, but of the remaining bits only A1, A2,
A5, and A6 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;">
A1<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
A2<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
A5<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
A6<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
Description of operation<br>
</th>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">Clears the
accumulator<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">Shift one position
right, duplicating the sign bit into the vacated
position<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">Shift two positions
right, duplicating the sign bit into the vacated
position<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">Shift one position
left, filling the vacated position with 0<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">Shift two positions
left, filling the vacated positions with 0<br>
</td>
</tr>
</tbody>
</table>
<br>
By a "left" shift, we mean a shift toward the
more-significant direction (multiplying by powers of 2); by
a "right" shift, we mean a shift toward the less-significant
direction (dividing by powers of 2).<br>
<br>
In terms of assembly-language syntax, I have never seen <tt>SHF</tt>
itself used. Rather, the synonyms <tt>SHL</tt> (left
shift) and <tt>SHR</tt> (right shift) are used, and only in
the following variations:<br>
<blockquote><tt>SHL <i>N</i></tt><tt><br>
</tt><tt>SHR <i>N</i></tt><br>
</blockquote>
where <i><tt>N</tt></i> is a literal decimal numerical
constant. However, <tt>N</tt> is not limited to just
0, 1, or 2, even those are all that <tt>SHF</tt> directly
supports. If an operand <i><tt>N</tt></i>>2 is
encountered, the assembler transparently replaces it with an
appropriate <i>sequence</i> of shift-by-2 and shift-by-1
instructions.<br>
<br>
Note: The <i>original</i> documentation of the <tt>SHF</tt>
instruction itself does not actually describe the
directionality of the shifts, nor the nature of the data
used to fill the bit-positions vacated by the shift.
It instead simply refers to the there-undefined terms "MSD
shift" and "LSD shift". <i> Elsewhere</i> in the
original documentation is a theory-of-operation for the
electronic circuitry, and the additional information about
directionality and fill-values given above is derived from
the theory of operation.<br>
</td>
</tr>
<tr>
<td valign="middle"><font face="Courier New, Courier,
monospace">SHF</font></td>
<td valign="middle">0<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">1<br>
</td>
<td valign="middle">0<br>
</td>
<td valign="middle" align="center">TBD<br>
</td>
<td valign="top">PTC only ... not LVDC.<br>
<br>
Functionally similar to the identically-named LVDC
instruction, but differs in detail. It does not
provide a "clear accumulator" function as the LVDC
instruction does, but allows a shift of up to 6
bit-positions in a single instruction (rather than up to 2
as in the LVDC).<br>
<br>
As far as the encoding is concerned: A7 determines the
direction of the shift: 0 = left shift (filling
vacated bit positions with 0), 1 = right shift (duplicating
the sign bit into the vacated bit positions). As for
A6-A1:<br>
<br>
<table cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<th valign="top">A1<br>
</th>
<th valign="top">A2<br>
</th>
<th valign="top">A3<br>
</th>
<th valign="top">A4<br>
</th>
<th valign="top">A5<br>
</th>
<th valign="top">A6<br>
</th>
<th valign="top">Description of operation<br>
</th>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">Shift by one position (left or right
as determined by A7)<br>
</td>
</tr>
<tr>
<td valign="top">0<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">Shift by two positions (left or right
as determined by A7)</td>
</tr>
<tr>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">Shift by three positions (left or
right as determined by A7)</td>
</tr>
<tr>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">Shift by four positions (left or
right as determined by A7)</td>
</tr>
<tr>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">Shift by five positions (left or
right as determined by A7)</td>
</tr>
<tr>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">Shift by six positions (left or right
as determined by A7)</td>
</tr>
</tbody>
</table>
<br>
In terms of assembly-language syntax, I have never seen <tt>SHF</tt>
itself used. Rather, the synonyms <tt>SHL</tt> (left
shift) and <tt>SHR</tt> (right shift) are used, and only in
the following variations:<br>
<blockquote><tt>SHL <i>N</i></tt><tt><br>
</tt><tt>SHR <i>N</i></tt><br>
</blockquote>
where <i><tt>N</tt></i> is a literal decimal numerical
constant. However, <tt>N</tt> is not limited to just
1 through 6, even those are all that <tt>SHF</tt> directly
supports. If an operand <i><tt>N</tt></i>>6 is
encountered, the assembler transparently replaces it with an
appropriate <i>sequence</i> of shift-by-6 (or less)
instructions.<br>
<br>
Note: The <i>original</i> documentation of the <tt>SHF</tt>
instruction itself does not actually describe the
directionality of the shifts, nor the nature of the data
used to fill the bit-positions vacated by the shift.
It instead simply refers to the there-undefined terms "MSD
shift" and "LSD shift". <i> Elsewhere</i> in the
original documentation is a theory-of-operation for the
electronic circuitry, and the additional information about
directionality and fill-values given above is derived from
the theory of operation.<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> EXM<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>0<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;"> LVDC only ... <i>not</i>
PTC.<br>
<br>
"Execute modified". In baseball terms, this is the
"infield fly rule" of the LVDC: it clearly does something,
but upon first acquaintance it's hard to grasp exactly what
it does.<br>
<br>
The <tt>EXM</tt> instruction takes a target instruction
stored at a different memory location, forms a modified
operand for that instruction, executes the modified
instruction, and then continues with the next instruction
following the <tt>EXM</tt> (unless the program counter has
been changed by the modified instruction). For this
instruction, A8 and A9 form a part of the instruction code,
so only A1-A7 are significant. <br>
<br>
It is important to understand that the target instruction is
not modified within the LVDC memory; rather, it is modified
and executed without the modified form of it being stored in
memory at all.<br>
<br>
Only 4 different choices of memory address are allowed to
contain the target instruction which is to be modified,
namely 0200, 0240, 0300, and 0340 in the "residual sector"
in the memory module selected by the current DM (data
module) bit. (The original documentation does not
actually indicate whether it is the IM or DM bit that
selects the particular memory module in which the target
instruction is stored, and I think that it would be very
reasonable to suppose that the IM bit is used. But
from the actual AS206-RAM Flight Program source code, it is
obvious that DM is the bit which is used.)<br>
<br>
Some of the bits in A1-A7 of the <tt>EXM</tt> instruction
represent various types of modifications to the embedded
address at the target address rather than themselves being
address bits. Here are the interpretations of
bits A1-A7 found in the <tt>EXM</tt> instruction:<br>
<ul>
<li>A1-A4 modify the address embedded in the target
instruction as described below.<br>
</li>
<li>A5 indicates the syllable in which the target
instruction resides in residual memory.</li>
<li>A7,A6 selects the target address, as follows:</li>
<ul>
<li>0,0 for target address 0200</li>
<li>0,1 for target address 0240</li>
<li>1,0 for target address 0300</li>
<li>1,1 for target address 0340</li>
</ul>
</ul>
To modify the target instruction, its A1-A9 bits are formed
as follows:<br>
<ul>
<li>A1-A2 come from A1-A2 of the <span
style="font-family: monospace;">EXM</span>
instruction.</li>
<li>A3 is the logical OR of the A3 of the target
instruction and A3 of the <tt>EXM</tt> instruction.</li>
<li>A4 is the logical OR of the A4 of the target
instruction and A4 of the <tt>EXM</tt> instruction.</li>
<li>A5-A8 come from A5-A8 of the target instruction, and
remain unchanged.</li>
<li>A9 becomes 0, thus the target instruction cannot be
either <tt>EXM</tt> or <tt>SHF/SHR/SHL</tt>.
(The original documentation does not actually say
anything about how the target instruction's A9 is
modified, but if it were allowed to remain 1, the
data-sector discussion which immediately follows would
not make sense.)<br>
</li>
</ul>
The data sector used when the target instruction is executed
is also changed for the duration of that one instruction, as
determined by bits A1, A2, and A9 of the unmodified target
instruction, 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;">
A2<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
A1<br>
</th>
<th style="vertical-align: top; font-weight: bold;">
A9<br>
</th>
<th style="vertical-align: top; font-weight: bold;">Data
Sector<br>
</th>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">004<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">014<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">005<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">015<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">006<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">016<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">0<br>
</td>
<td style="vertical-align: top;">007<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">1<br>
</td>
<td style="vertical-align: top;">017 ("residual"
sector)<br>
</td>
</tr>
</tbody>
</table>
<br>
The assembly-language syntax is<br>
<blockquote><tt>EXM <i>adr,syl,mod</i></tt><br>
</blockquote>
where <i><tt>adr</tt></i> (0, 1, 2, or 3) selects target
address 200, 240, 300, or 340, respectively; <i><tt>syl</tt></i>
(0 or 1) is the syllable of the target address; and <i><tt>mod</tt></i>
(00-17 octal) is the 4-bit modification to be applied to
bits A1-A4 of the target instruction's operand.<br>
</td>
</tr>
<tr>
<td style="font-family: Courier New,Courier,monospace;"> CLA<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td>1<br>
</td>
<td style="text-align: center;">1<br>
</td>
<td style="vertical-align: top;">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".</td>
</tr>
</tbody>
</table>
<br>
<h3><a name="IO_Ports_For_PIO_Instruction"
id="IO_Ports_For_PIO_Instruction"></a>I/O Ports (For LVDC/PTC <span
style="font-family: Courier New,Courier,monospace;">PIO</span>
Instruction)</h3>
My understanding of this is sketchy right now, so take anything I
have to say with a grain of salt. <br>
<p>Note that the LVDC code is self-modifying, and thus ports that
don't explicitly appear in the source code may actually be
accessed at runtime, while ports that do explicitly appear in the
code may be changed to something else before having a chance to be
accessed at runtime. For example, on p. 227 of the AS206-RAM
source code (look at labels <tt>MLDBUX</tt>, <tt>MLDBUY</tt>,
and <tt>MLDBUZ</tt>), there's self-modifying code that changes an
instruction <tt>PIO 203</tt> to a <tt>PIO 303</tt>, then changes
it to a <tt>PIO 273</tt>, and then finally changes it back to <tt>PIO
203</tt>. Unfortunately, with programming and
documentation practices like these, getting a complete list of
ports used — other than by just running the code under all
possible combinations of conditions and recording what happens —
is a tough proposition. (That's not intended as a criticism
of the programming practices IBM FSD had back in 1967 ... but it
goes to show why, <i>today</i>, there are reasons that practices
such as these are frowned upon.)<br>
</p>
<p>At any rate, here is a table of ports from the original
documentation, though massaged a bit by me.<br>
</p>
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="text-align: center;" colspan="9" rowspan="1">
Address Field from PIO Instruction<br>
</th>
<th colspan="1" rowspan="2">Data Source<br>
</th>
<th colspan="1" rowspan="2">Data Destination<br>
</th>
<th colspan="1" rowspan="2" style="vertical-align: middle;">Specific
I/O Ports<br>
</th>
</tr>
<tr>
<th style="text-align: center;">A9<br>
</th>
<th style="text-align: center;">A8<br>
</th>
<th style="text-align: center;">A7<br>
</th>
<th style="text-align: center;">A6<br>
</th>
<th style="text-align: center;">A5<br>
</th>
<th style="text-align: center;">A4<br>
</th>
<th style="text-align: center;">A3<br>
</th>
<th style="text-align: center;">A2<br>
</th>
<th style="text-align: center;">A1<br>
</th>
</tr>
<tr>
<td style="text-align: center;" valign="middle" align="center">X<br>
</td>
<td style="text-align: center;" valign="middle" align="center">0<br>
</td>
<td style="text-align: center;" valign="middle" align="center"><i>
A</i><i><br>
</i> </td>
<td style="text-align: center;" valign="middle" align="center"><i>
A</i><i><br>
</i> </td>
<td style="text-align: center;" valign="middle" align="center"><i>
A</i><i><br>
</i> </td>
<td style="text-align: center;" valign="middle" align="center"><i>
A</i><i><br>
</i> </td>
<td style="text-align: center;" valign="middle" align="center"><i>
A</i><i><br>
</i> </td>
<td style="text-align: center;" valign="middle" align="center">0<br>
</td>
<td style="text-align: center;" valign="middle" align="center"><i>A</i><br>
</td>
<td valign="middle">Accumulator Register<br>
</td>
<td valign="middle">LVDA Telemetry Registers<span
style="font-style: italic;"></span><br>
<br>
or PTC<br>
general<br>
purpose<br>
</td>
<td colspan="1" rowspan="3" valign="middle">For LVDC, used to
output telemetry consisting of the values of variables,
typically via the <tt>TELEM</tt> macro in the LVDC source
code. For definitions of non-standard units of
measurement, see <a href="#AngleUnits">the later discussion
of that topic</a>. Page-number references are to the
AS-206RAM LVDC source code or to its <a
href="https://github.com/virtualagc/virtualagc/blob/master/yaASM.py/sample-1967.lvdc">abridged
form</a>.)<br>
<br>
<table width="100%" cellspacing="2" cellpadding="10">
<tbody>
<tr>
<td width="50%" valign="middle" align="center"><b>LVDC</b><b><br>
</b></td>
<td width="50%" valign="middle" align="center"><b>PTC</b><b><br>
</b></td>
</tr>
<tr>
<td width="50%" valign="top" align="center">
<table width="80%" cellspacing="2" cellpadding="2"
border="1" align="center">
<tbody>
<tr>
<th valign="bottom">A9-A1 (octal)<br>
</th>
<th valign="bottom">Variable<br>
</th>
<th valign="bottom">Scale<br>
</th>
<th valign="bottom">Units<br>
</th>
<th valign="bottom" align="left">Interpretation<br>
</th>
</tr>
<tr>
<td valign="middle" align="center">000<br>
</td>
<td valign="middle" align="center"><tt>TASEC</tt><tt><br>
</tt><tt>ONTAS</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B15</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">Time elapsed from GRR or
time of last orbit navigation<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">001<br>
</td>
<td valign="middle" align="center"><tt>CHIZ</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad<br>
</td>
<td valign="middle">Yaw guidance command in
space-fixed coordinates<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">004<br>
</td>
<td valign="middle" align="center"><tt>ACCZ</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center">0.05 m/sec<br>
</td>
<td valign="middle">Accelerator optisyn
reading<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">005<br>
</td>
<td valign="middle" align="center"><tt>CHIX</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad<br>
</td>
<td valign="middle">Pitch guidance command in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">010<br>
</td>
<td valign="middle" align="center"><tt>ACCX</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center">0.05 m/sec</td>
<td valign="middle">Accelerator optisyn
reading</td>
</tr>
<tr>
<td valign="middle" align="center">011<br>
</td>
<td valign="middle" align="center"><tt>CHIY</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad<br>
</td>
<td valign="middle">Roll guidance command in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">014<br>
</td>
<td valign="middle" align="center"><tt>ACCY</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center">0.05 m/sec</td>
<td valign="middle">Accelerator optisyn
reading</td>
</tr>
<tr>
<td valign="middle" align="center">015<br>
</td>
<td valign="middle" align="center"><tt>THETZ</tt></td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad</td>
<td valign="middle">Whole yaw gimbal angle<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">021<br>
</td>
<td valign="middle" align="center"><tt>THETX</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad</td>
<td valign="middle">Whole roll gimbal angle</td>
</tr>
<tr>
<td valign="middle" align="center">025<br>
</td>
<td valign="middle" align="center"><tt>THETY</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad</td>
<td valign="middle">Whole pitch gimbal angle</td>
</tr>
<tr>
<td valign="middle" align="center">030<br>
</td>
<td valign="middle" align="center"><tt>TLTBB</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B15</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">Biased time elapsed in
time base<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">031<br>
</td>
<td valign="middle" align="center"><tt>TB</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B15</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">Time elapsed in current
time base<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">034<br>
</td>
<td valign="middle" align="center"><tt>ZS</tt><tt><br>
</tt><tt>ONZN</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Component of position in
space-fixed coordinates<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">044<br>
</td>
<td valign="middle" align="center"><tt>XS</tt><tt><br>
</tt><tt>ONXN</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Component of position in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">050<br>
</td>
<td valign="middle" align="center"><tt>Y</tt><tt>S</tt><tt><br>
</tt><tt>ONYN</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Component of position in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">054<br>
</td>
<td valign="middle" align="center"><tt>GR10R</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B-22</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<sup>-1</sup></td>
<td valign="middle">Reciprocal of total radius
in space-fixed coordinates<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">060<br>
</td>
<td valign="middle" align="center"><tt>GZ</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of gravitational
acceleration<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">064<br>
</td>
<td valign="middle" align="center"><tt>GX</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of gravitational
acceleration</td>
</tr>
<tr>
<td valign="middle" align="center">070<br>
</td>
<td valign="middle" align="center"><tt>GY</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of gravitational
acceleration</td>
</tr>
<tr>
<td valign="middle" align="center">074<br>
</td>
<td valign="middle" align="center"><tt>TBA</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B15</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">Set equal to TBB at the
time of a C-band station gain or loss<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">075<br>
</td>
<td valign="middle" align="center"><tt>SS</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Switch selector interrupt<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">110<br>
</td>
<td valign="middle" align="center"><tt>ZDS</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B14</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<br>
</td>
<td valign="middle">Component of velocity in
space-fixed coordinates<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">114<br>
</td>
<td valign="middle" align="center"><tt>XDS</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B14</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec</td>
<td valign="middle">Component of velocity in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">120<br>
</td>
<td valign="middle" align="center"><tt>YDS</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B14</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec</td>
<td valign="middle">Component of velocity in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">124<br>
</td>
<td valign="middle" align="center"><tt>V</tt><tt><br>
</tt> </td>
<td valign="middle" align="center"><tt>B14</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec</td>
<td valign="middle">Total velocity in
space-fixed coordinates<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">134<br>
</td>
<td valign="middle" align="center"><tt>ZS</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Component of position in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">144<br>
</td>
<td valign="middle" align="center"><tt>XS</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Component of position in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">150<br>
</td>
<td valign="middle" align="center"><tt>YS</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Component of position in
space-fixed coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">174<br>
</td>
<td valign="middle" align="center"><tt>ACCT</tt><tt><br>
</tt><tt>TLPAST</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B25</tt><tt><br>
</tt></td>
<td valign="middle" align="center">qms<br>
</td>
<td valign="middle">Real time clock reading<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">400<br>
</td>
<td valign="middle" align="center"><tt>T1I</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B10</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">First IGM phase time-to-go<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">414<br>
</td>
<td valign="middle" align="center"><tt>MC28</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Mode code 28 status
changes. Refer to p. 12.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">415<br>
</td>
<td valign="middle" align="center"><tt>MC24</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Mode code 24 status
changes. Refer to pp. 4-5.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">420<br>
</td>
<td valign="middle" align="center"><tt>MC27</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Mode code 27 status
changes. Refer to pp. 11-12<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">421<br>
</td>
<td valign="middle" align="center"><tt>MC25</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Mode code 25 status
changes. Refer to p. 5.</td>
</tr>
<tr>
<td valign="middle" align="center">425<br>
</td>
<td valign="middle" align="center"><tt>DORSW</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Discrete output register
contents. A change indicates a
guidance failure.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">431<br>
</td>
<td valign="middle" align="center"><tt>ICR</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">LVDA internal control
register contents. Refer to pp. 5-6.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">434<br>
</td>
<td valign="middle" align="center"><tt>Z4</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Position in target plane
coordinates<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">435<br>
</td>
<td valign="middle" align="center"><tt>EMRR</tt><tt><br>
</tt><tt>TLEMR1</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Error monitor register
contents. Change indicates ladder
failure or redundancy disagreement.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">441<br>
</td>
<td valign="middle" align="center"><tt>INT</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">LLS, OBCO, TLC, or S4BCO
interrupt. Refer to p. 6.</td>
</tr>
<tr>
<td valign="middle" align="center">444<br>
</td>
<td valign="middle" align="center"><tt>X4</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Position in target plane
coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">450<br>
</td>
<td valign="middle" align="center"><tt>Y4</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B23</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Position in target plane
coordinates</td>
</tr>
<tr>
<td valign="middle" align="center">460<br>
</td>
<td valign="middle" align="center"><tt>T3I</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B10</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">Time-to-go in S4B second
burn<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">461<br>
</td>
<td valign="middle" align="center"><tt>TLCHPC</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">TLC ("tough luck charlie")
HOP constant<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">465<br>
</td>
<td valign="middle" align="center"><tt>DIS.IN</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Discrete inputs.
Refer to p. 6.</td>
</tr>
<tr>
<td valign="middle" align="center">471<br>
</td>
<td valign="middle" align="center"><tt>SQ3</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B1</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">(1-ZSP<sup>2</sup>)<sup>1/2</sup></td>
</tr>
<tr>
<td valign="middle" align="center">475<br>
</td>
<td valign="middle" align="center"><tt>TBBU</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Time base backup<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">500<br>
</td>
<td valign="middle" align="center"><tt>FDBK</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Switch-selector feedback
register, in the event of an error<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">501<br>
</td>
<td valign="middle" align="center"><tt>MLCHIZ</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad<br>
</td>
<td valign="middle">Minor loop CHIZ<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">504<br>
</td>
<td valign="middle" align="center"><tt>ZDDV</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of vent
acceleration<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">505<br>
</td>
<td valign="middle" align="center"><tt>MLCHIX</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad<br>
</td>
<td valign="middle">Minor loop CHIX</td>
</tr>
<tr>
<td valign="middle" align="center">510<br>
</td>
<td valign="middle" align="center"><tt>XDDV</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of vent
acceleration<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">511<br>
</td>
<td valign="middle" align="center"><tt>MLCHIY</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B0</tt><tt><br>
</tt></td>
<td valign="middle" align="center">pirad<br>
</td>
<td valign="middle">Minor loop CHIY</td>
</tr>
<tr>
<td valign="middle" align="center">514<br>
</td>
<td valign="middle" align="center"><tt>YDDV</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of vent
acceleration<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">520<br>
</td>
<td valign="middle" align="center"><tt>ZDDD</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of drag
acceleration</td>
</tr>
<tr>
<td valign="middle" align="center">524<br>
</td>
<td valign="middle" align="center"><tt>XDDD</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of drag
acceleration</td>
</tr>
<tr>
<td valign="middle" align="center">530<br>
</td>
<td valign="middle" align="center"><tt>YDDD</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m/sec<sup>2</sup></td>
<td valign="middle">Component of drag
acceleration</td>
</tr>
<tr>
<td valign="middle" align="center">534<br>
</td>
<td valign="middle" align="center"><tt>ALT</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B4</tt><tt><br>
</tt></td>
<td valign="middle" align="center">m<br>
</td>
<td valign="middle">Altitude<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">535<br>
</td>
<td valign="middle" align="center"><tt>TLEMR8</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Minor-loop error code<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">544<br>
</td>
<td valign="middle" align="center"><tt>TAUD</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B10</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">Time-to-go<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">561<br>
</td>
<td valign="middle" align="center"><tt>TI</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt>B15</tt><tt><br>
</tt></td>
<td valign="middle" align="center">sec<br>
</td>
<td valign="middle">Time from GRR of time-base
change<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">570<br>
</td>
<td valign="middle" align="center">(various)<br>
</td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Minor-loop error
code. Refer to pp. 6 and 14.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">571<br>
</td>
<td valign="middle" align="center"><tt>ETC</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">End of telemetry cycle,
one per computation cycle<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">575<br>
</td>
<td valign="middle" align="center"><tt>BTC</tt><tt><br>
</tt></td>
<td valign="middle" align="center"><tt><br>
</tt></td>
<td valign="middle" align="center"><br>
</td>
<td valign="middle">Begin telemetry cycle, one
per computation cycle<br>
</td>
</tr>
</tbody>
</table>
</td>
<td width="50%" valign="top" align="center">
<table width="100%" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="bottom" align="center"><b>A9-A1</b><b><br>
</b><b>(octal)</b><b><br>
</b></td>
<td valign="bottom" align="center"><b>Purpose</b><b><br>
</b></td>
</tr>
<tr>
<td valign="middle" align="center">000<br>
</td>
<td valign="top">I suspect this may clear the
entire interrupt latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">001<br>
</td>
<td valign="top">Set interrupt 1 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">004<br>
</td>
<td valign="top">Set interrupt 3 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">010<br>
</td>
<td valign="top">Set interrupt 4 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">020<br>
</td>
<td valign="top">Set interrupt 5 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">021<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">034<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">040<br>
</td>
<td valign="top">Set interrupt 6 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">065<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">075<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">100<br>
</td>
<td valign="top">Set interrupt 7 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">135<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">200<br>
</td>
<td valign="top">Set interrupt 8 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">210<br>
</td>
<td valign="top">Enables one of six output
discretes to be generated. Discretes 1
through 6, respectively, are controlled by
positions 25, 24, 23, 22, 21, and 20 of the
accumulator data word. I'm not sure
how this differs from <tt>CIO 210</tt> (see
next section). In fact, the
source-code comment in the PAST program even
mentions <tt>CIO 210</tt>. From the test
procedures in the PAST program, it appears
to me that these are the same 6 bits which
can be read back with <tt>CIO 214</tt>
(bits 22-17) when appropriately gated by the
PROG REG A toggle switches.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">221<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">340<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">400<br>
</td>
<td valign="top">Set interrupt 9 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">525<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center"><i>A</i><br>
</td>
<td valign="middle">Main Memory<br>
</td>
<td valign="middle">LVDA Telemetry Registers<span
style="font-style: italic;"></span></td>
</tr>
<tr>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center"><i>A</i></td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center"><i>A</i><br>
</td>
<td valign="middle">Residual Memory<br>
</td>
<td valign="middle">LVDA Telemetry Registers<span
style="font-style: italic;"></span></td>
</tr>
<tr>
<td valign="middle" align="center">X<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle">Accumulator Register</td>
<td valign="middle">LVDA Output Registers<br>
<br>
or <br>
<br>
PTC<br>
general <br>
purpose<br>
</td>
<td colspan="1" rowspan="3" valign="middle">
<table width="100%" cellspacing="2" cellpadding="10">
<tbody>
<tr>
<td width="50%" valign="middle" align="center"><b>LVDC</b><b><br>
</b></td>
<td width="50%" valign="middle" align="center"><b>PTC</b><b><br>
</b></td>
</tr>
<tr>
<td width="50%" valign="top" align="center">
<table width="80%" cellspacing="2" cellpadding="2"
border="1" align="center">
<tbody>
<tr>
<th valign="bottom" align="center">A9-A1
(octal) </th>
<th valign="bottom" align="center">Purpose<br>
</th>
</tr>
<tr>
<td valign="top" align="center">006<br>
</td>
<td valign="top">Mode Register<br>
</td>
</tr>
<tr>
<td valign="top" align="center">012 </td>
<td valign="top">Discrete Output Register
(Reset). The <a
href="Documents/satinstunitibm_3.pdf">LVDC
EDD for the Saturn IB Flight Program</a>
document, section 7.3, summarizes the
discrete outputs as: <br>
<div align="center"><img alt=""
src="lvdcDO.png" width="375"
height="215"><br>
</div>
</td>
</tr>
<tr>
<td valign="top" align="center">016 </td>
<td valign="top">Discrete Output Register
(Set). See <tt>PIO 012</tt> above.<br>
</td>
</tr>
<tr>
<td valign="top" align="center">022 </td>
<td valign="top">Internal Control Register
(Set)<br>
</td>
</tr>
<tr>
<td valign="top" align="center">026 </td>
<td valign="top">Internal Control Register
(Reset)<br>
</td>
</tr>
<tr>
<td valign="top" align="center">032 </td>
<td valign="top">Interrupt Register
Reset. Resets the interrupts whose
bits are set in ACC. See 072 below.<br>
</td>
</tr>
<tr>
<td valign="top" align="center">036 </td>
<td valign="top">Switch Selector Register
(Load)<br>
</td>
</tr>
<tr>
<td valign="top" align="center">042 </td>
<td valign="top">Orbital Checkout<br>
</td>
</tr>
<tr>
<td valign="top" align="center">052 </td>
<td valign="top">Switch Selector &
Discrete Output Registers (Read)<br>
</td>
</tr>
<tr>
<td valign="top" align="center">062 </td>
<td valign="top">Switch Selector Interrupt
Counter<br>
</td>
</tr>
<tr>
<td valign="top" align="center">066 </td>
<td valign="top">COD Error (Read)<br>
</td>
</tr>
<tr>
<td valign="top" align="center">072 </td>
<td valign="top">Interrupt-inhibit
latch. (None of the following is
covered by the available documentation, so
everything I say about it is inferred or
guessed from source code.) It's not
clear to me whether this simply writes the
value in ACC to the latch, or whether it
logically-OR's ACC to the latch; I presume
the latter. There are 13 interrupts
covered, and the mask comprises the 12
most-significant bits of ACC other than
SIGN. Here's how I think the
bit-positions of the latch are interpreted:<br>
<ul>
<li>S: n/a (0)</li>
<li>1: ML (Minor Loop)</li>
<li>2: SS (Switch Select)<br>
</li>
<li>3: CIU? In the AS206-RAM Flight
Program, the interrupt-service routine
for this always immediately exits.
So in effect, these interrupts are
always ignored whether inhibited or not.<br>
</li>
<li>4: TLC (Tough Luck Charlie)</li>
<li>5: Command Receiver? The
interrupt-service routine for this is
not part of the AS206-RAM Flight
Program, and is instead in unassigned
memory. Presumably it is serviced
by some other program co-loaded into
memory along with the flight program.<br>
</li>
<li>6: GRR? In the AS206-RAM Flight
Program, the interrupt-service routine
for this always immediately exits.
So in effect, these interrupts are
always ignored whether inhibited or not.</li>
<li>7: S2 PROP. DEPL.? In the
AS206-RAM Flight Program, the
interrupt-service routine for this
always immediately exits. So in
effect, these interrupts are always
ignored whether inhibited or not.</li>
<li>8: OECO/OBCO (Outboard Engine Cut Off,
starts Time Base 3)<br>
</li>
<li>9: S4B/S4BEO/S4BCO (S4B Engine Cut
Off)<br>
</li>
<li>10: RCA? In the AS206-RAM Flight
Program, the interrupt-service routine
for this always immediately exits.
So in effect, these interrupts are
always ignored whether inhibited or not.</li>
<li>11: LLS (Low Level Sense, starts Time
Base 2)<br>
</li>
<li>12: ?<br>
</li>
<li>13-25: n/a (0)</li>
</ul>
</td>
</tr>
<tr>
<td valign="top" align="center">076 </td>
<td valign="top">Minor Loop Timed Interrupt
Counter<br>
</td>
</tr>
<tr>
<td valign="top" align="center">146 </td>
<td valign="top">Ladder No. 1<br>
</td>
</tr>
<tr>
<td valign="top" align="center">152 </td>
<td valign="top">Ladder No. 2<br>
</td>
</tr>
<tr>
<td valign="top" align="center">156 </td>
<td valign="top">Ladder No. 3<br>
</td>
</tr>
<tr>
<td valign="top" align="center">162 </td>
<td valign="top">Ladder No. 4<br>
</td>
</tr>
<tr>
<td valign="top" align="center">166 </td>
<td valign="top">Ladder No. 5<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">172<br>
</td>
<td valign="top">Clamp adders. (This is
not covered by the available documentation,
but seems to be implied by the comments in
the source code.) </td>
</tr>
<tr>
<td valign="middle" align="center">672<br>
</td>
<td valign="top">(None of this is covered by
the available documentation.) Clear
interrupt-inhibit latch, using a mask.
It's not clear to me whether this
logically-inverts the mask and then AND's it
to the latch, or whether it XOR's the mask
to the latch; I presume the former. In
the AS206RAM Flight Program's source code, <tt>PIO
672</tt> is used in memory module 2, and
address 672 translates to 2-17-272, which is
the variable <tt>IHBT</tt>. I infer
that the technique for temporarily
inhibiting LVDA-generated interrupts is:<br>
<ul>
<li>Create a bit-mask determining which
interrupts to inhibit.</li>
<li>Store the mask at <tt>IHBT</tt>.</li>
<li>Write the mask out to the
interrupt-inhibit latch with <tt>PIO
072</tt> (and possibly <tt>PIO 032</tt>).<br>
</li>
<li>... do stuff ...</li>
<li>Use <tt>PIO 672</tt> to undo the
masked interrupt-inhibit bits in the
latch.<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
</td>
<td width="50%" valign="top" align="center">
<table width="100%" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="bottom" align="center"><b>A9-A1</b><b><br>
</b><b>(octal)</b><b><br>
</b></td>
<td valign="bottom" align="center"><b>Purpose</b><b><br>
</b></td>
</tr>
<tr>
<td valign="middle" align="center">002<br>
</td>
<td valign="top">Set interrupt 2 latch.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">006<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">016<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">022<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">026<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">032<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">036<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">056<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">066<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">076<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">136<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">222<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">252<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">402<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">776<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle">Main Memory</td>
<td valign="middle">LVDA Output Registers</td>
</tr>
<tr>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle">Residual Memory</td>
<td valign="middle">LVDA Output Registers</td>
</tr>
<tr>
<td valign="middle" align="center">X<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle">LVDA Peripheral Inputs and Errors<br>
</td>
<td valign="middle">Accumulator<br>
</td>
<td valign="middle">
<table width="100%" cellspacing="2" cellpadding="10">
<tbody>
<tr>
<td width="50%" valign="middle" align="center"><b>LVDC</b><b><br>
</b></td>
<td width="50%" valign="middle" align="center"><b>PTC</b><b><br>
</b></td>
</tr>
<tr>
<td width="50%" valign="top" align="center">
<table width="80%" cellspacing="2" cellpadding="2"
border="1" align="center">
<tbody>
<tr>
<th valign="bottom" align="center">A9-A1
(octal) </th>
<th valign="bottom" align="center">Purpose<br>
</th>
</tr>
<tr>
<td valign="top" align="center">023<br>
</td>
<td valign="top">Error Monitor Register<br>
</td>
</tr>
<tr>
<td valign="top" align="center">043<br>
</td>
<td valign="top">Command Receiver or RCA-110<br>
</td>
</tr>
<tr>
<td valign="top" align="center">053<br>
</td>
<td valign="top">Discrete Input Spares.
Refer to the DIS1-DIS8 inputs in the table
for <tt>PIO 057</tt> below.<br>
</td>
</tr>
<tr>
<td valign="top" align="center">057<br>
</td>
<td valign="top">Discrete Inputs. The <a
href="Documents/satinstunitibm_3.pdf">LVDC
EDD for the Saturn IB Flight Program</a>
document, section 7.4, summarizes the
discrete inputs in the table below.
(The DIS1-DIS8 inputs in the table for <tt>PIO
053</tt> above.)<br>
<div align="center"><img alt=""
src="lvdcDI.png" width="400"
height="440"><br>
<div align="left">The Command Decoder OM/D
bits mentioned in the table originate in
an <a href="LVDC.html#Up-data">up-data
command word</a> transmitted to the
rocket from mission control. There
are two such bits in the transmitted
word, but the LVDA combines them into a
single bit before passing them to the
LVDC — hence, OM/D bits "A" and "B" both
appear at the same position in <tt>PIO
057</tt>. A value of 1 in the
OM/D bit indicates that a "mode" command
word has been received (and is
accessible via <tt>PIO 043</tt>), while
a value of 0 indicates instead that a
"data" command word has been received
(in <tt>PIO 043</tt>).<br>
</div>
</div>
</td>
</tr>
<tr>
<td valign="top" align="center">067<br>
</td>
<td valign="top">Telemetry Scanner<br>
</td>
</tr>
<tr>
<td valign="top" align="center">077<br>
</td>
<td valign="top">Switch Selector<br>
</td>
</tr>
<tr>
<td valign="top" align="center">103<br>
</td>
<td valign="top">Real Time<br>
</td>
</tr>
<tr>
<td valign="top" align="center">107<br>
</td>
<td valign="top">Accelerometer Processor X<br>
</td>
</tr>
<tr>
<td valign="top" align="center">117<br>
</td>
<td valign="top">Accelerometer Processor Z<br>
</td>
</tr>
<tr>
<td valign="top" align="center">127<br>
</td>
<td valign="top">Accelerometer Processor Y </td>
</tr>
<tr>
<td valign="top" align="center">137<br>
</td>
<td valign="top">Interrupt Storage </td>
</tr>
</tbody>
</table>
</td>
<td width="50%" valign="top" align="center">
<table width="100%" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="bottom" align="center"><b>A9-A1</b><b><br>
</b><b>(octal)</b><b><br>
</b></td>
<td valign="bottom" align="center"><b>Purpose</b><b><br>
</b></td>
</tr>
<tr>
<td valign="middle" align="center">003<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">017<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">023<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">027<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">033<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">037<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">043<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">047<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">053<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">057<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">063<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">067<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">073<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">077<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">117<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">123<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">127<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">133<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">137<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">157<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">167<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">177<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">X<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center"><i>A</i><i><br>
</i></td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle">LVDA Resolver Processor Inputs<br>
</td>
<td valign="middle">Accumulator</td>
<td valign="middle">
<table width="100%" cellspacing="2" cellpadding="10">
<tbody>
<tr>
<td width="50%" valign="middle" align="center"><b>LVDC</b><b><br>
</b></td>
<td width="50%" valign="middle" align="center"><b>PTC</b><b><br>
</b></td>
</tr>
<tr>
<td width="50%" valign="top" align="center">
<table width="80%" cellspacing="2" cellpadding="2"
border="1" align="center">
<tbody>
<tr>
<th valign="bottom" align="center">A9-A1
(octal) </th>
<th valign="bottom" align="center">Purpose<br>
</th>
</tr>
<tr>
<td valign="middle" align="center">203<br>
</td>
<td valign="top">Z Gimbal Backup. (This
is not covered by the available
documentation, but seems to be implied by
the comments in the source code.)<br>
</td>
</tr>
<tr>
<td valign="top" align="center">207<br>
</td>
<td valign="top">Spare No. 6<br>
</td>
</tr>
<tr>
<td valign="top" align="center">217<br>
</td>
<td valign="top">Computer COD Counter Start<br>
</td>
</tr>
<tr>
<td valign="top" align="center">223<br>
</td>
<td valign="top">Fine Gimbal No. 1<br>
</td>
</tr>
<tr>
<td valign="top" align="center">233<br>
</td>
<td valign="top">Coarse Gimbal No. 3<br>
</td>
</tr>
<tr>
<td valign="top" align="center">237<br>
</td>
<td valign="top">Computer COD Counter Start<br>
</td>
</tr>
<tr>
<td valign="top" align="center">243<br>
</td>
<td valign="top">Coarse Gimbal No. 1<br>
</td>
</tr>
<tr>
<td valign="top" align="center">247<br>
</td>
<td valign="top">Horizon Seeker No. 1<br>
</td>
</tr>
<tr>
<td valign="top" align="center">257<br>
</td>
<td valign="top">Spare No. 3<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">273<br>
</td>
<td valign="top">Y Gimbal Backup. (This
is not covered by the available
documentation, but seems to be implied by
the comments in the source code.)</td>
</tr>
<tr>
<td valign="middle" align="center">277<br>
</td>
<td valign="top">Spare No. 4<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">303<br>
</td>
<td valign="top">X Gimbal Backup. (This
is not covered by the available
documentation, but seems to be implied by
the comments in the source code.)</td>
</tr>
<tr>
<td valign="top" align="center">313<br>
</td>
<td valign="top">Fine Gimbal No. 4<br>
</td>
</tr>
<tr>
<td valign="top" align="center">317<br>
</td>
<td valign="top">Spare No. 1<br>
</td>
</tr>
<tr>
<td valign="top" align="center">323<br>
</td>
<td valign="top">Horizon Seeker No. 3<br>
</td>
</tr>
<tr>
<td valign="top" align="center">327<br>
</td>
<td valign="top">Horizon Seeker No. 2<br>
</td>
</tr>
<tr>
<td valign="top" align="center">333<br>
</td>
<td valign="top">Coarse Gimbal No. 4<br>
</td>
</tr>
<tr>
<td valign="top" align="center">337<br>
</td>
<td valign="top">Spare No. 5<br>
</td>
</tr>
<tr>
<td valign="top" align="center">343<br>
</td>
<td valign="top">Coarse Gimbal No. 2<br>
</td>
</tr>
<tr>
<td valign="top" align="center">353<br>
</td>
<td valign="top">Fine Gimbal No. 3<br>
</td>
</tr>
<tr>
<td valign="top" align="center">357<br>
</td>
<td valign="top">Spare No. 2<br>
</td>
</tr>
<tr>
<td valign="top" align="center">363<br>
</td>
<td valign="top">Fine Gimbal No. 2<br>
</td>
</tr>
<tr>
<td valign="top" align="center">367<br>
</td>
<td valign="top">Horizon Seeker No. 4<br>
</td>
</tr>
</tbody>
</table>
</td>
<td width="50%" valign="top" align="center">
<table width="100%" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="bottom" align="center"><b>A9-A1</b><b><br>
</b><b>(octal)</b><b><br>
</b></td>
<td valign="bottom" align="center"><b>Purpose</b><b><br>
</b></td>
</tr>
<tr>
<td valign="middle" align="center">203<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">213<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">223<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">227<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">233<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">237<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">243<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">247<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">253<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">257<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">263<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">267<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">273<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">277<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">303<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">313<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">317<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">323<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">333<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">337<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">343<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">347<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">353<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">357<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">363<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">367<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">373<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">403<br>
</td>
<td valign="top">See <tt>CIO 230</tt>.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">773<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="middle" align="center">777<br>
</td>
<td valign="top">Address register<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
<h3><a name="IO_Ports_for_PTC_CIO_Instruction"></a>I/O Ports (for
PTC <font face="Courier New, Courier, monospace">CIO</font>
Instruction)</h3>
<p>Figure 2-11 of <a href="Documents/19730064346_1973064346.pdf">the
original PTC documentation</a> gives a list of i/o ports
employed by the PTC's <tt>CIO</tt> instruction.
Unfortunately, by my count, 137 different <tt>CIO</tt> ports are
used just within the PAST program, while the documentation lists
only 35 of them. The following is a table of <i>all</i>
known <tt>CIO</tt> ports, including not only those listed in the
original documentation, but also those found in the source code of
the PAST program. Sometimes the functionality of a port
referenced <i> only</i> in the PAST program is easily inferred
from comments in the source code, so I've supplied my inferences
in the table below, while in other cases I haven't yet deduced
that functionality. In other words, as usual, this is a work
in progress! Port numbers whose descriptions were pasted
from the original documentation are in <b>bold text</b>, to
distinguish them from those whose functionality has merely been
inferred.<br>
</p>
<table cellspacing="2" cellpadding="2" border="1" align="center">
<tbody>
<tr>
<td valign="middle" align="center"><b>CIO Operand Address</b><b><br>
</b></td>
<td valign="middle" align="left"><b>Operation</b><b><br>
</b></td>
</tr>
<tr>
<td valign="middle" align="center"><b>000</b><b><br>
</b></td>
<td valign="middle" align="left">Enables the interrupt inhibit
register latches to be set under control of accumulator data
bits 11 through 25 (Data bit 11 sets interrupt inhibit latch
15, etc.)<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">001<br>
</td>
<td valign="middle" align="left">Set interrupt 3 latch.
For additional functionality beyond this, see <tt>CIO 234</tt>.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">002<br>
</td>
<td valign="middle" align="left">Set interrupt 1 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">003<br>
</td>
<td valign="middle" align="left">TBD<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>004</b><br>
</td>
<td valign="middle" align="left">Enables the interrupt inhibit
register latches to be reset under control of accumulator
data bits 11 through 25 (Data bit 25 resets interrupt
inhibit latch 1, etc.)<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">005<br>
</td>
<td valign="middle" align="left">Set interrupt 4 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">006<br>
</td>
<td valign="middle" align="left">Set interrupt 2 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">007<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>010</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 1 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">011<br>
</td>
<td valign="middle" align="left">Set interrupt 5 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">012<br>
</td>
<td valign="middle" align="left">Set interrupt 3 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>014</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 2 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">015<br>
</td>
<td valign="middle" align="left">Set interrupt 6 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">016<br>
</td>
<td valign="middle" align="left">Set interrupt 4 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">017<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>020</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 3 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">021<br>
</td>
<td valign="middle" align="left">Set interrupt 7 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">022<br>
</td>
<td valign="middle" align="left">Set interrupt 5 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">023<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>024</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 4 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">025<br>
</td>
<td valign="middle" align="left">Set interrupt 8 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">026<br>
</td>
<td valign="middle" align="left">Set interrupt 6 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>030</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 5 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">031<br>
</td>
<td valign="middle" align="left">Set interrupt 9 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">032<br>
</td>
<td valign="middle" align="left">Set interrupt 7 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>034</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 6 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">035<br>
</td>
<td valign="middle" align="left">Set interrupt 10 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">036<br>
</td>
<td valign="middle" align="left">Set interrupt 8 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">037<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>040</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 7 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">041<br>
</td>
<td valign="middle" align="left">Set interrupt 11 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">042<br>
</td>
<td valign="middle" align="left">Set interrupt 9 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>044</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 8 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">045<br>
</td>
<td valign="middle" align="left">Set interrupt 12 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">046<br>
</td>
<td valign="middle" align="left">Set interrupt 10 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>050</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 9 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">051<br>
</td>
<td valign="middle" align="left">Set interrupt 13 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">052<br>
</td>
<td valign="middle" align="left">Set interrupt 11 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>054</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 10 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">055<br>
</td>
<td valign="middle" align="left">Set interrupt 14 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">056<br>
</td>
<td valign="middle" align="left">Set interrupt 12 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">057<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>060</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 11 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">061<br>
</td>
<td valign="middle" align="left">Set interrupt latch 15<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">062<br>
</td>
<td valign="middle" align="left">Set interrupt latch 13<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>064</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 12 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">065<br>
</td>
<td valign="middle" align="left">Set interrupt latch 9</td>
</tr>
<tr>
<td valign="middle" align="center">066<br>
</td>
<td valign="middle" align="left"><i>May</i> do the
following: set interrupt 14 latch and then "enable
compare" (if SIGN=1) or "disable compare / reset compare
latch" (if SIGN=0). In other words, I suspect that an
interrupt of type 14 occurs when a comparison match
occurs. The other bits in <tt>ACC</tt> may be the bit
pattern against which the comparison is made. I would
suggest further that the the "compare latch" referred to is
the Address Compare (ADR COMP) latch, discussed on p. V-2-69
of the PTC documentation, so that the contents of <tt>ACC</tt>
would be something like a HOP constant. A perhaps
illustrative usage in the PAST program code is found at
label <tt>L9P36</tt>, shortly after which we find <tt>ACC</tt>
indeed being loaded with the HOP constant (for location <tt>L9P36</tt>),
and then output via <tt>CIO 066</tt>. A similar
sequence of code occurs at label <tt>L10P33</tt>. On
the other hand, this interpretation is inconsistent with the
notion that the SIGN bit must be non-zero to enable
comparisons, since <tt>L9P36</tt>'s HOP constant has a SIGN
bit of 0, so perhaps more thought is required to unravel
what this operation is doing.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>070</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 13 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">071<br>
</td>
<td valign="middle" align="left"><i>S</i>et interrupt latch 10</td>
</tr>
<tr>
<td valign="middle" align="center">072<br>
</td>
<td valign="middle" align="left"><i>May</i> do the
following: set interrupt latch 15, and load a register
determining the behavior of TSYNC signal. The PAST
program comments that relate to the values loaded in <tt>ACC</tt>
are:<br>
<ul>
<li>137777777, solid TSYNC reset, diode check<br>
</li>
<li>337777777, single TSYNC pulse (if not followed by <tt>CIO
102</tt>) or 240 TSYNC pulses per second (if followed
by <tt>CIO 102</tt>).</li>
</ul>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>074</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 14 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">075<br>
</td>
<td valign="middle" align="left">Set interrupt latch 1<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">076<br>
</td>
<td valign="middle" align="left"><i>May</i> be the same kind
of thing as <tt>CIO 072</tt>, except for interrupt latch 11
and the GCSYNC signal:<br>
<ul>
<li>000000002, solid GSYNC reset, diode check.</li>
<li>257777777, reset solid GSYNC</li>
<li>357777777, single GSYNC pulse (if not followed by <tt>CIO
102</tt>) or 240 GSYNC pulses per second (if followed
by <tt>CIO 102</tt>).</li>
<li>377777777, solid GSYNC<br>
</li>
</ul>
(The PAST program source code actually indicates that the
first item on the list above is a <tt>CIO 072</tt> ... but
I think this may be a bug in the PAST program, and it may
have intended to say <tt>CIO 076</tt> rather than <tt>CIO
072</tt>.) </td>
</tr>
<tr>
<td valign="middle" align="center">077<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>100</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 15 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">101<br>
</td>
<td valign="middle" align="left">Set interrupt latch 2<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">102<br>
</td>
<td valign="middle" align="left">Set interrupt latch 13<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>104</b><br>
</td>
<td valign="middle" align="left">Reset interrupt 16 latch<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">105<br>
</td>
<td valign="middle" align="left">Set interrupt latch 3<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">106<br>
</td>
<td valign="middle" align="left">Set interrupt latch 1<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>110</b><br>
</td>
<td valign="middle" align="left">Resets the main interrupt
latch, also known as the INT B latch. The value
provided in <tt>ACC</tt> is ignored.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">111<br>
</td>
<td valign="middle" align="left">Set interrupt latch 4<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">112<br>
</td>
<td valign="middle" align="left">Set interrupt latch 2<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>114</b><br>
</td>
<td valign="middle" align="left">Generates a PTC single step
command.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">115<br>
</td>
<td valign="middle" align="left">Set interrupt latch 5<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">116<br>
</td>
<td valign="middle" align="left">Set interrupt latch 3<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">117<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>120</b><br>
</td>
<td valign="middle" align="left">Sends a single character to
be printed on the typewriter. This character is
encoded in 6 bits (SIGN and bits 1-5) in BA8421
format. See <a href="#BCI">the <tt>BCI</tt>
pseudo-op</a> for an explanation of BA8421.<br>
<br>
The typewriter BUSY signal (see <tt>CIO 214</tt> below)
becomes active while this operation occurs physically, and
then becomes inactive when the operation is complete.<br>
<br>
For reasons which are unclear to me, <tt>CIO 120</tt>
appears to enable various interrupts in the interrupt latch,
with different interrupts being enabled for different
characters. The same holds true for <tt>CIO 124</tt>
and <tt>CIO 130</tt>, with the same interrupts being
enabled for the same printable characters. Moreover,
the conditions enabled by <tt>CIO 130</tt> affect still
other interrupt bits. In the PAST program source code,
the characters printed vs the interrupt bits expected to be
set are given by a 1-to-1 relationship between the arrays <tt>CHAR</tt>
and <tt>PATN</tt>, with the exception that <tt>PATN</tt>
does not distinguish between "upper case" and "lower case"
characters as described below. Though not mentioning
interrupts at all, the interrupt-bit patterns <i>seem</i>
to be derivable from Figure 2-56 of the PTC document,
"Selection and Tilt-Rotate Schedule", in which the following
relationship between individual BCD keyboard solenoids (or
other conditions) and interrupt bits seems to hold
empirically:<br>
<ul>
<li>Interrupt 3 latch: R1 (<tt>CIO 120/124/130</tt>)</li>
<li>Interrupt 4 latch: R2 (<tt>CIO 120/124/130</tt>)</li>
<li>Interrupt 5 latch: R2A (<tt>CIO 120/124/130</tt>)</li>
<li>Interrupt 6 latch: R5 (<tt>CIO 120/124/130</tt>)</li>
<li>Interrupt 7 latch: T1 (<tt>CIO 120/124/130</tt>)</li>
<li>Interrupt 8 latch: T2 (<tt>CIO 120/124/130</tt>)</li>
<li>Interrupt 9 latch: Check Bit (<tt>CIO 120/124/130</tt>)</li>
<li>Interrupt 10 latch: TAB (<tt>CIO 134</tt>)</li>
<li>Interrupt 11 latch: INDEX (<tt>CIO 134</tt>)<br>
</li>
<li>Interrupt 12 latch: RED (<tt>CIO 134</tt>)<br>
</li>
<li>Interrupt 13 latch: BLACK (<tt>CIO 134</tt>)<br>
</li>
<li>Interrupt 14 latch: CARR RTN (<tt>CIO 134</tt>)<br>
</li>
<li>Interrupt 15 latch: SPACE (<tt>CIO 120/124/134</tt>)</li>
</ul>
<p><i>Additionally,</i> some characters are categorized as
"upper case" and others are categorized as "lower
case". These distinctions aren't what you would
expect, since the alphabetics ("A" through "Z") are all <i>lower</i>
case. When ever a change from an upper-case
character to a lower-case character occurs, the typewriter
requires additional time to make this adjustment, so the
BUSY signal remains active longer. Moreover, instead
of simply changing the interrupt-latch bits in the way
described above, a two-step process is observed:<br>
</p>
<ol>
<li>For a change to upper case, Interrupt 1 latch is set,
while for a change to lower case, Interrupt 2 latch is
set. This condition persists for a while.</li>
<li>After a brief delay, the remaining interrupt-latch
bits (as described earlier) are set as well.<br>
</li>
</ol>
</td>
</tr>
<tr>
<td valign="middle" align="center">121<br>
</td>
<td valign="middle" align="left">Set interrupt latch 6<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">122<br>
</td>
<td valign="middle" align="left">Set interrupt latch 4<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>124</b><br>
</td>
<td valign="middle" align="left">Sends a single decimal
character to be printed on the typewriter. This
character is encoded in 4 bits (SIGN and bits 1-3).
The 6-bit BA8421 format (see <a href="#BCI">the <tt>BCI</tt>
pseudo-op</a>) but with the two most-significant bits
implicitly 0. I.e., the lowest 16 characters of
BA8421, which happens to include all decimal digits, plus 6
other characters (space and so on). <br>
<br>
See the notes for <tt>CIO 120</tt>, regarding the BUSY
signal and the interrupt-latch bits.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">125<br>
</td>
<td valign="middle" align="left">Set interrupt latch 7<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">126<br>
</td>
<td valign="middle" align="left">Set interrupt latch 5<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>130</b><br>
</td>
<td valign="middle" align="left">Sends a single octal digit to
be printed on the typewriter. This character is
encoded in 3 bits (SIGN and bits 1-2).<br>
<br>
See the notes for <tt>CIO 120</tt>, regarding the BUSY
signal and the interrupt-latch bits.</td>
</tr>
<tr>
<td valign="middle" align="center">131<br>
</td>
<td valign="middle" align="left">Set interrupt latch 8<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">132<br>
</td>
<td valign="middle" align="left">Set interrupt latch 6<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>134</b><br>
</td>
<td valign="middle" align="left">Generates a typewriter
control command. Positions SIGN and 1 through 5 of the
accumulator data word are decoded to perform one of six
operations.<br>
<br>
<table cellspacing="2" cellpadding="2" align="center">
<tbody>
<tr>
<td valign="middle" align="center"><u>Data Bit</u><u><br>
</u></td>
<td valign="middle" align="left"><u>Operation</u><u><br>
</u></td>
</tr>
<tr>
<td valign="middle" align="center">SIGN<br>
</td>
<td valign="middle" align="left">Space<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="left">Select Black Ribbon<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">2<br>
</td>
<td valign="middle" align="left">Select Red Ribbon<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">3<br>
</td>
<td valign="middle" align="left">Index (i.e., advance
to next line without moving the the left-margin)<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">4<br>
</td>
<td valign="middle" align="left">Carriage Return<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">5<br>
</td>
<td valign="middle" align="left">Tab<br>
</td>
</tr>
</tbody>
</table>
<br>
A carriage return also occurs automatically, without the
need for <tt>CIO 134</tt>, if the right-hand margin is
reached and the typewriter is not otherwise busy.<br>
<br>
Regarding tabs and carriage returns, realize that for an IBM
Selectric typewriter, the tab stops and the left/right
margins were set manually, using controls on the face of the
typewriter. Fortunately, Selectric typefaces used (I
believe!) typefaces with fixed-width characters, so the
number of characters per tab stop or line of print did not
vary on a line-by-line basis. On the other hand, there
were two different sizes for the typefaces, 12 characters
per inch or 10 characters per inch, so the number of
characters per line still varied depending on the chosen
size of the typeface. Given that the PAST program's
test procedures actually do test conditions such as reaching
the right-hand margin, one would suppose that the PTC
documentation of the self-test procedures would give
specific instructions regarding these various choices.
One would be mistaken in this assumption.<br>
<br>
So in terms of emulation of the PTC's typewriter peripheral,
there's no cut-and-dried way of knowing where the tab stops
are, when an automatic carriage returns is supposed to occur
due to having hit a right-hand margin, or where the print
head is supposed to position itself after a carriage return
does occur. The PAST program itself gives some hints
as to what's expected, in that some cursory notes on p. 90
of the source code — a routine which exercises the
typewriter — say:<br>
<blockquote><tt>* SET
RIGHT MARGIN BETWEEN 120 AND 124</tt><tt><br>
</tt><tt>* SET LEFT
MARGIN AT 0</tt><tt><br>
</tt><tt>* SET TAB AT
10</tt><br>
</blockquote>
Unfortunately these settings (or at least the margin
settings) are not consistent with the tests actually
implemented in the PAST program source code. The
emulated PTC panel accepts the tab-stop width and carriage
width as command-line parameters.<br>
<br>
See also the notes for <tt>CIO 120</tt>, regarding the BUSY
signal and the interrupt-latch bits.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">135<br>
</td>
<td valign="middle" align="left">Set interrupt latch 9<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">136<br>
</td>
<td valign="middle" align="left">Set interrupt latch 7<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">137<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center"><b>140</b><br>
</td>
<td valign="middle" align="left">Generates an X plot command.
See <tt>CIO 144</tt> below.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">141<br>
</td>
<td valign="middle" align="left">Set interrupt latch 10<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">142<br>
</td>
<td valign="middle" align="left">Set interrupt latch 8<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>144</b><br>
</td>
<td valign="middle" align="left">Generates a Y plot
command. The CalComp 565 plotter is a drum plotter, in
which the paper is pinched against a cylindrical drum, and
the pen is on a carriage that moves parallel to the axis of
the drum. The Y axis is along the carriage, with the
positive direction being to the left, and the negative
direction to the right, while the X coordinate is around the
circumference of the drum and is changed by the rolling of
the drum to advance or regress the paper.<br>
<br>
The X value for <tt>CIO 140</tt> and Y value for <tt>CIO
144</tt>, supplied by <tt>ACC</tt>, are not absolute
coordinates, but are rather relative to the current position
of the pen. According to the PTC documentation, the
values for <tt>CIO 140</tt> and <tt>144</tt> can range
from -1024 to +1024, with each step representing an offset
of 0.01 inch. (Of course, in the emulated PTC, the
distances may not be represented accurately.) The drum
itself was physically 11 inches wide, thus providing a hard
limit on the absolute Y coordinates, which I presume was 0
to 1023. There is presumably no practical limit on the
absolute X coordinates, since the paper is provided on a
continuous roll (which can be torn off as desired) rather
than on sheets cut to a specific length.<br>
<br>
The X and Y values are not in native 2's-complement format
of the processor. Instead, they are encoded as <i>positive</i>
10-bit values (in the least-significant bits of <tt>ACC</tt>,
bits 16 through 25), while the sign is indicated the SIGN
bit. All other bits (1 through 15) are 0.<br>
<br>
The driving circuitry for the plotter was provided by the
PTC, and allowed only for drawing along the X or Y axes, or
at 45° angles, thus greatly limiting the flexibility of what
could be easily plotted. To draw at 45°, <tt>CIO 140</tt>
and <tt>CIO 144</tt> instructions would be performed in
succession, outputting values that are either identical or
else differ only by being opposite in sign. The
plotter would then be stepped by the PTC circuitry at a rate
of 300 steps/second. Using other combinations of
values (such as an X value of 100 and and a Y value of 200)
would <i>not</i> draw a line at a different angle; rather,
the pen would proceed at a 45° angle until either X or Y had
been exhausted, and then would move an extra amount along
the Y or X axis until the other had been exhausted.
Thus, to draw a line at (say) 30°, rather than attempting to
do so in one iteration, it would be necessary to do it using
many short segments at multiples of 45°, producing a
slightly jagged effect. <b>Note:</b> The
emulated PTC panel (yaPTC.py) ignores this restriction, and
simply drives the pen in a straight line to the new
commanded position, at whatever angle is implied.<br>
<br>
The original PTC documentation is not as explicit as I'd
hope for, but it seems to imply that the initiation of the
plotting action is controlled by <tt>CIO 144</tt>. In
other words, merely loading the X value using <tt>CIO 140</tt>
is not enough to start the physical plot; it is necessary to
load the Y value (perhaps with 0) using <tt>CIO 144</tt>
for the plotting to actually commence. This
interpretation is consistent with the usage and the program
comments in the PAST program source code.<br>
<br>
Regarding the PTC panel emulation (yaPTC.py), a separate
window is opened to hold an image of the plot. The
plot is in the same orientation as the original physical
printer: the X-axis is vertical and the Y-axis is
horizontal. By default the plot window is 1024×1024,
plus a small margin. That's big enough in the Y
direction, but not necessarily in the X direction.
However, you can expand the size of the plot window by
dragging its border. Or, if you have a mouse with a
scroll wheel, you can pan the image vertically using the
scroll wheel. For horizontal panning, depress
the keyboard's SHIFT key while adjusting the scroll wheel.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">145<br>
</td>
<td valign="middle" align="left">Set interrupt latch 11<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">146<br>
</td>
<td valign="middle" align="left">Set interrupt latch 9<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>150</b><br>
</td>
<td valign="middle" align="left">Generates a Z plot
command. Specifically, if bit 25 (the
least-significant bit) is set, then the pen is raised off of
the paper; if bit 24 is set, the pen is lowered onto the
paper.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">151<br>
</td>
<td valign="middle" align="left">Set interrupt latch 12<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">152<br>
</td>
<td valign="middle" align="left">Set interrupt latch 10<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>154</b><br>
</td>
<td valign="middle" align="left">Stores the configuration of
the interrupt latches in positions SIGN and 1 through 15 of
the accumulator data word. (The SIGN bit stores interrupt
latch 1 configuration, bit 1 stores interrupt latch 2
configuration, ..., bit 15 stores the interrupt latch 16
configuration.)<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">155<br>
</td>
<td valign="middle" align="left">Spare<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">156<br>
</td>
<td valign="middle" align="left">Set interrupt latch 11</td>
</tr>
<tr>
<td valign="middle" align="center"><b>160</b><br>
</td>
<td valign="middle" align="left">Outputs a single
carriage-control command to the printer, encoded in the 6
most-significant bits (sourced by ACC). The encoding
was defined by Figure 2-51 in the original PTC
documentation. <br>
<br>
For the original physical printer, there was a paper tape
which encoded information about the paper loaded into the
printer. This allowed things like automatic pagination
without any software changes. The encoding of the
carriage-control commands involved 12 "channels", each of
which had a hole punched in the tape or did not have a hole
punched. This paper-format-defining paper tape and its
12 channels is obviously irrelevant in modern terms, and
specifically to any emulation of the PTC, where there's no
paper tape and probably no paper! Similarly, the
physical printer had a buffer in which all incoming data was
stored until either the buffer was full or else a "group
mark" command had been received, at which point the buffered
data was physically printed and the buffer was
cleared. The carriage-control commands fall into two
groups, those which are executed "immediately" — i.e.,
presumably before the buffer is physically printed — or
"after print". This buffer is not emulated, so there
is no distinction made in the PTC emulation between the
"immediate" and the "after print" commands.<br>
<br>
Here's my emulation-friendly summary of Figure 2-51, with
all reference to the "channels" and "immediate"/"after
print" removed. "X" (unlike in Figure 2-51) means
"don't care":<br>
<br>
<table cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<th valign="bottom" align="center">SIGN + Bit 1 <br>
</th>
<th valign="bottom" align="center">Bit 2<br>
</th>
<th valign="bottom" align="center">Bit 3<br>
</th>
<th valign="bottom" align="center">Bit 4<br>
</th>
<th valign="bottom" align="center">Bit 5<br>
</th>
<th valign="bottom" align="left">Description<br>
</th>
</tr>
<tr>
<td valign="middle" align="center">00 or 11<br>
</td>
<td valign="middle" align="center">X<br>
</td>
<td valign="middle" align="center">X<br>
</td>
<td valign="middle" align="center">X<br>
</td>
<td valign="middle" align="center">X<br>
</td>
<td valign="middle" align="left">Vertical space
(carriage return + line feed). <br>
</td>
</tr>
<tr>
<td valign="middle" align="center">01 or 10<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="left">1 horizontal space<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">01 or 10<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="left">2 horizontal spaces<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">01 or 10<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="left">3 horizontal spaces<br>
</td>
</tr>
</tbody>
</table>
<br>
As mentioned in the discussion of the <tt>PRS</tt>
instruction earlier, using <tt>PRS</tt> to send character
data to the printer has the side effect of altering the
interrupt latch, thus potentially causing interrupts, or of
allowing readback (using <tt>CIO 154</tt>) of those changes
to the interrupt latch. This is entirely undocumented
(unless it can be figured out from the 2nd-level
schematics), as far as I can tell, but fortunately the PAST
source code has a complete list of the bit patterns produced
vs the data for <tt>CIO 160</tt> that produce them.
Refer to the arrays <tt>PATN2</tt> and <tt>PATN3</tt> in
that source code. Rather than reproduce that list
here, I'll instead give you a rule that I infer from them,
which is helpful in understanding the <tt>PRS</tt>
interrupt-latch bit-patterns:<br>
<ul>
<li>Bits SIGN, 1-5: These are identical to the upper
6 bits of <tt>CIO 160</tt>'s data word.</li>
<li>Bit 6: Odd-parity bit. (I.e., a bit chosen
to insure that the contents of the entire interrupt
latch has odd parity.)<br>
</li>
<li>Bits 7-11: 21<sub>8</sub>.</li>
<li>Bits 12-25: 0.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="middle" align="center">161<br>
</td>
<td valign="middle" align="left">Spare<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">162<br>
</td>
<td valign="middle" align="left">Set interrupt latch 12</td>
</tr>
<tr>
<td valign="middle" align="center"><b>164</b><br>
</td>
<td valign="middle" align="left">Sets the printer to "octal"
mode. In octal mode, 8 octal digits are encoded in <tt>PRS</tt>-instruction
data.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">165<br>
</td>
<td valign="middle" align="left">Spare<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">166<br>
</td>
<td valign="middle" align="left">Set interrupt latch 13<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>170</b><br>
</td>
<td valign="middle" align="left">Sets the printer in "BCD"
mode. I think this is a misnomer, in that rather than
being a Binary Coded Decimal mode, it is actually a mode in
which 4 full characters (encoded in BA8421) are contained in
each <tt>PRS</tt>-instruction.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">171<br>
</td>
<td valign="middle" align="left">Spare<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">172<br>
</td>
<td valign="middle" align="left">Set interrupt latch 14<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">174<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">175<br>
</td>
<td valign="middle" align="left">Spare<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">176<br>
</td>
<td valign="middle" align="left">Set interrupt latch 15<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">177<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">200<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">202<br>
</td>
<td valign="middle" align="left">Set interrupt latch 12<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>204</b><br>
</td>
<td valign="middle" align="left"><a
href="ptcProcessorDisplayPanel.png"><img
src="ptcProcessorDisplayPanel-tiny.jpg" title="Click to
enlarge." alt="" width="108" height="200" border="2"
align="right"></a>Enables the program control display
register to be loaded. Positions 20 through 25 of the
accumulator data word are loaded into positions P40, P20,
P10, P4, P2 and P1, respectively, of the program control
display register, which in turn light the corresponding
lamps on the PTC's Processor Display Panel depicted to the
right (click to enlarge). </td>
</tr>
<tr>
<td valign="middle" align="center">206<br>
</td>
<td valign="middle" align="left">Set interrupt latch 14<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>210</b><br>
</td>
<td valign="middle" align="left"><a
href="ptcProcessorDisplayPanel.png"><img
src="ptcProcessorDisplayPanel-tiny.jpg" title="Click to
enlarge." alt="" width="108" height="200" border="2"
align="right"></a>Enables one of six output discretes to
be generated. Discretes 1 through 6, respectively, are
controlled by positions 25, 24, 23, 22, 21, and 20 of the
accumulator data word. I believe these are the same
bits which can be read back with <tt>CIO 214</tt> (bits
22-17). <br>
<br>
They may also light the lamps labeled D6 through D1 on the
PTC's Processor Display Panel depicted to the right (click
to enlarge). <br>
<br>
Finally, I believe that the outputs have specific functions
in terms of the PTC hardware external to the CPU.
While these functions are completely undocumented, the PAST
program's source code uses them in various ways. I
haven't yet determined how to reconcile the various uses,
which aren't necessarily self-consistent — it's hard to
tell! — but here's a summary of what the code seems to say::<br>
<ul>
<li>Discrete output 1: <br>
</li>
<ul>
<li>Cause the printer to vertically space to the next of
its 12 predefined "channels". This will also cause the
printer's BUSY signal (bit 25 of <tt>CIO 214</tt>) to
become active. Presumably, spacing will continue
to occur as long as this discrete is set, although the
emulated PTC printer peripheral treats it as a
one-time event; however, in emulation, the printer
BUSY signal does continue to remain active as long as
this condition is present. As a side effect,
this causes the interrupt latch (ready by <tt>CIO 154</tt>)
to be loaded with one of 12 predefined patterns of
bits.</li>
<li>Also seems to case a typewriter BUSY signal. I
don't know why or whether there's an associated
physical affect on the typewriter. I assume
there must be. Perhaps, in analogy to the effect
on the printer mentioned above, it could be a
form-feed command.<br>
</li>
<li>Force the printer's PROCESSOR RELEASE signal.<br>
</li>
</ul>
<li>Discrete output 2: Forces a printer PARITY
ERROR. <br>
</li>
<li>Discrete output 3: <br>
</li>
<ul>
<li>Force the typewriter's right-margin detection
signal, thus causing a carriage return, and causing
the typewriter's BUSY signal (bit 23 of <tt>CIO 214</tt>)
to become active. Presumably, carriage returns
continue to occur as long as this discrete is set,
although the emulated PTC treats it as a one-time
event; however, in emulation, the BUSY signal does
continue to remain active as long as this condition is
present or until an actual output typewriter operation
changes the condition of the signal. More on
this TBD.</li>
<li>Same ... but for the printer.<br>
</li>
</ul>
<li>Discrete output 4: Force the printer's BUSY
signal (bit 25 of <tt>CIO 214</tt>) into an active
state; i.e., force the printer to report that it is
BUSY. More on this TBD.</li>
<li>Discrete output 5: Force the printer's BUSY
signal (bit 25 of <tt>CIO 214</tt>) into an active
state; i.e., force the printer to report that it is
BUSY. More on this TBD. <b>Note:</b>
Source-code comments in the PAST program (p.73) imply
the exact opposite of this, namely that it is forcing
the printer to report that it is ready. However,
the actual test supplied by the code belies the
comments. </li>
<li>Discrete output 6: Forces the printer's
detection of "channel 12" to be active. Normally,
a detection of channel 12 implies that the end of the
physical page has been reached and that the printer
should therefore advance to "channel 1" of the next
page. This will also cause the printer's BUSY
signal (bit 25 of <tt>CIO 214</tt>) to become
active. Presumably, the page feeds will continue
to occur as long as this discrete is set, although the
emulated PTC typewriter peripheral treats it as a
one-time event; however, in emulation, the typewriter
BUSY signal does continue to remain active as long as
this condition is present. As a side effect, this
causes the interrupt latch (read by <tt>CIO 154</tt>)
to be loaded with a specific pattern of bits, similar to
that of <tt>CIO 160</tt> (skip after printing to
channel 1), namely 305010000<sub>8</sub> (as opposed to
30504000).<br>
</li>
</ul>
See also <tt>PIO 210</tt> in the preceding section.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">212<br>
</td>
<td valign="middle" align="left">Set interrupt latch 1<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>214</b><br>
</td>
<td valign="middle" align="left"><a
href="ptcProcessorDisplayPanel.png"><img
src="ptcProcessorDisplayPanel-tiny.jpg" title="Click to
enlarge." alt="" width="108" height="200" border="2"
align="right"></a>Transfers the PROG REG A data word
into the accumulator. PROG REG A is a set of 26 toggle
switches which are part of the PTC's Processor Display
Panel, depicted to the right (click to enlarge). The
original documentation is by no means clear, but here is my
interpretation of its explanations.<br>
<br>
Except for the toggles I mark below as GATED, the states of
the toggle switches are simply read directly by <tt>CIO 214</tt>,
with OFF (down) giving 0 and ON (up) giving 1. The
interpretations are therefore software-dependent and
essentially arbitrary. There are a few cases in which
the PAST program uses certain toggles in a systematic way,
and those are indicated below.<br>
<br>
In contrast, the GATED toggles are read as 1 when ON, but
when OFF allow the CPU to instead read the indicated signals
generated elsewhere in the PTC, which could each be either 0
or 1 at any given time. <br>
<ul>
<li>Bits S: TBD<br>
</li>
<li>Bits 1-13: TBD<br>
</li>
<li>Bit 14: Action after an error is
encountered: If OFF, proceed to next test; if ON,
repeat the failed test.</li>
<li>Bit 15: TBD<br>
</li>
<li>Bit 16: Action after an error is
encountered: If ON, then single step; if OFF,
continuous run.</li>
<li>(GATED) Bit 17: Externally-generated discrete input,
TBD. See <tt>CIO 210</tt> above and <tt>PIO 210</tt>
in the preceding section.<br>
</li>
<li>(GATED) Bit 18: Externally-generated discrete input,
TBD. See <tt>CIO 210</tt> above and <tt>PIO 210</tt>
in the preceding section.</li>
<li>(GATED) Bit 19: Externally-generated discrete input,
TBD. See <tt>CIO 210</tt> above and <tt>PIO 210</tt>
in the preceding section.</li>
<li>(GATED) Bit 20: Externally-generated discrete input,
TBD. See <tt>CIO 210</tt> above and <tt>PIO 210</tt>
in the preceding section.</li>
<li>(GATED) Bit 21: Externally-generated discrete input,
TBD. See <tt>CIO 210</tt> above and <tt>PIO 210</tt>
in the preceding section.</li>
<li>(GATED) Bit 22: Externally-generated discrete input,
TBD. See <tt>CIO 210</tt> above and <tt>PIO 210</tt>
in the preceding section.</li>
<li>(GATED) Bit 23: The PTC's typewriter's BUSY signal.</li>
<li>(GATED) Bit 24: The PTC's plotter's BUSY signal.</li>
<li>(GATED) Bit 25: The PTC's printer's BUSY signal.</li>
</ul>
</td>
</tr>
<tr>
<td valign="middle" align="center">216<br>
</td>
<td valign="middle" align="left">Set interrupt latch 2<br>
</td>
</tr>
<tr>
<td valign="middle" align="center"><b>220</b><br>
</td>
<td valign="middle" align="left"><a
href="ptcProcessorDisplayPanel.png"><img
src="ptcProcessorDisplayPanel-tiny.jpg" title="Click to
enlarge." alt="" width="108" height="200" border="2"
align="right"></a>Transfers the PROG REG B data word
into the accumulator. PROG REG B is a set of 26 toggle
switches which are part of the PTC's Processor Display
Panel, depicted to the right (click to enlarge). <br>
<br>
It appears to me that the states of the switches are simply
read directly by <tt>CIO 220</tt>, with OFF (down) giving 0
and ON (up) giving 1. The interpretations are
therefore software-dependent and essentially arbitrary.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">223<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">224<br>
</td>
<td valign="middle" align="left">Undocumented, but from the
PAST program test procedures (see address 0-03-1-101), it
appears to me that the SIGN bit and bits 1-14 set interrupt
latches for all bit positions in which <tt>ACC</tt> has a
1; i.e., they logically OR the PTC's interrupt-latches
1-15. Notice that INT 16 is not affected.<br>
<br>
But also (see address 0-03-1-332 in the PAST program), bits
15-25 are used as well. Those 11 bits <i>also</i>
seem to logically OR the PTC's interrupt-latches 1-11.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">230<br>
</td>
<td valign="middle" align="left">TBD<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">233<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">234<br>
</td>
<td valign="middle" align="left">As far as I can tell, this is
completely undocumented, so anything I have to say about it
is based on pure guesswork (and the desire for the self
tests in the PAST program to succeed rather than
fail). I think this may output a value to a 26-bit
shift register that subsequently shifts the data left at a
rate of one bit per machine cycle. In the original PTC
hardware, the shift register may be used to serialize data
for display on the PTC front panel, when the DISPLAY SELECT
rotary switch was in the TRS detent.<br>
<br>
Further, the current value of the shift register may
possibly be read back with a <tt>CIO 001</tt> instruction
for test purposes. Thus if successive instructions of
<tt>CIO 234</tt> and <tt>CIO 001</tt> are used, the latter
should read back the data the former wrote out, shifted left
by one bit position. If true, this would be an extra
capability of <tt>CIO 001</tt>, in addition to the
interrupt-control function described earlier.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">240<br>
</td>
<td valign="middle" align="left"><a
href="ptcProcessorDisplayPanel.png"><img
src="ptcProcessorDisplayPanel-tiny.jpg" title="Click to
enlarge." alt="" width="108" height="200" border="2"
align="right"></a>Lights the PROG ERR (PROGRAM ERROR)
lamp on the PTC's Processor Display Panel, depicted to the
right (click to enlarge). There is no way to
programmatically reset the PROG ERR lamp. The lamp is
part of the PROG ERROR/SYNC ERROR pushbutton indicator, and
the lamp is turned off by pressing the pushbutton on the
panel. (The SYNC ERROR lamp, though physically part of
the pushbutton, is not reset by this action; it is an
independent indicator and has a separate reset mechanism.)<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">243<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">250<br>
</td>
<td valign="middle" align="left">The only documentation of <tt>CIO
250</tt> comprises the following cryptic comments from the
PAST program source code:<br>
<ul>
<li>SIGN bit is set to 1: <tt>INHIBIT CHECK BIT AT
10,11,12 TIME</tt></li>
<li>Bit 1 is set to 1: <tt>RESET CHECK BIT INHIBIT</tt>.
(This comment appears in a block of code which is
commented as <tt>TEST CHECK BIT FOR 10,11,12 TIME OCTAL
MODE</tt>.)<br>
</li>
</ul>
<p>This appears to relate to the use <tt>PRS</tt>
instructions when the printer is in octal mode. In
that case, each <tt>PRS</tt> instruction causes 9 octal
digits and 3 spaces to print. The octal digits print
at times 1 through 9, while the spaces print at times 10
through 12. When <tt>CIO 250</tt> has been used to
inhibit the check bit "at 10,11,12" time", it means that
parity bits will not be generated for the 3 blank spaces.<br>
</p>
</td>
</tr>
<tr>
<td valign="middle" align="center">253<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">263<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">264<br>
</td>
<td valign="middle" align="left">There is no documentation
I've found. I've looked at the instances of <tt>CIO
264</tt> in the PAST program's source code, and the only
ones I find occur immediately after use of <tt>CIO 210</tt>
to activate discrete outputs 1, 2, and 3 in the course of
printer-peripheral operations, at which point those discrete
outputs apparently have the following interpretations:<br>
<ul>
<li>D1: PROCESSOR RELEASE</li>
<li>D2: PARITY ERROR</li>
<li>D3: CARR BUSY</li>
</ul>
<p>Because <tt>CIO 264</tt> is used only in blocks of the
PAST program whose comments indicate that it is testing
what happens in the case of printer parity errors, my best
guess is that <tt>CIO 264</tt> latches these values into
a separate set of flip-flops, which are then used by the
PTC hardware to simulate that printer parity errors have
occurred. Such errors would otherwise be impossible
to simulate in software and would require physical
modifications to the printer electronics. The effect
I see (in the PAST program) is that certain bits in the
interrupt latch are set after a subsequent <tt>PRS</tt>
instruction. In other words, one latches the desired
bits using <tt>CIO 264</tt>, performs a <tt>PRS</tt> to
print, then reads back the interrupt latch with <tt>CIO
154</tt>, and tests bits read back from the interrupt
latch to verify that they indicate the proper printer
error. I have no rationale for the specific bits
that are set, other than that I have observed them
empirically. Indeed, they seem rather arbitrary, and
I don't intend to specifically document them here.
Moreover, once a particular self test has been initiated —
test routine 5 is the specific test in which <tt>CIO 264</tt>
occurs — the PAST program then runs the test repeatedly
until manually canceled, and yet does nothing to reset the
contents of <tt>CIO 264</tt> for test runs subsequent to
the first run, as far as I can see. And yet they <i>must</i>
be reset, or else all subsequent tests would fail due to
the contents of the <tt>CIO 264</tt> latch being
unexpected. The emulation handles this by resetting
those latched bits every time the printer's mode is
changed from BCD to octal or vice-versa.<br>
</p>
<p>It's easy to see that this behavior I've described is a
particularly weak aspect of the PTC emulation, likely to
exist only in my imagination rather than correspondending
to what the original hardware did. I hope the
question may eventually be resolved by analysis of the PTC
electrical schematics.<br>
</p>
</td>
</tr>
<tr>
<td valign="middle" align="center">303<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">313<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">323<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">333<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">343<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">353<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">453<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">603<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">613<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">623<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
<tr>
<td valign="middle" align="center">633<br>
</td>
<td valign="middle" align="left">TBD </td>
</tr>
</tbody>
</table>
<h3><a name="Subroutine_Linkage" id="Subroutine_Linkage"></a>Subroutine
Linkage</h3>
While the LVDC is executing an instruction, it is also forming the
HOP constant of the next instruction in sequence—i.e., on the
assumption that no branch occurs—and this HOP constant is available
to the next instruction that executes. In most cases, this
means that an instruction can find out its own address (which isn't
very interesting), but if the previous instruction was a branch then
it means that the current instruction can determine the address of
the instruction in sequence that followed the branch instruction,
and thus can use this information for setting up returns from
subroutines. The instruction for fetching that HOP constant
and saving it is either <span style="font-family: courier
new,courier,monospace;">STO 0776</span> or <span
style="font-family: courier new,courier,monospace;">STO 0777</span>.
Only
those special addresses work. So a typical subroutine linkage
would look like this:<br>
<br>
<div style="margin-left: 80px;"> <span style="font-family: courier
new,courier,monospace;">
TRA MYSUB<br>
</span> </div>
<div style="margin-left: 40px;"> <span style="font-family: courier
new,courier,monospace;"> ... <i>return
to here</i> ...<br>
<br>
...<br>
<br>
MYSUB STO
0776 # or, STO 0777<br>
... <i>do stuff</i>
...<br>
HOP 0776 # or, HOP
0777<br>
</span> </div>
<br>
<h3><a name="Interrupts" id="Interrupts"></a>Interrupts</h3>
<h4><a name="Interrupts_of_LVDC"></a>Interrupts of LVDC</h4>
There are up to 12 external interrupt sources, buffered by the
LVDA. Upon any of these becoming active, the LVDA generates a
master interrupt signal to the LVDC. When the LVDC receives
the master interrupt signal, assuming that interrupts have not been
programmatically inhibited, the following actions occur:<br>
<ol>
<li>The LVDC automatically masks that particular interrupt from
occurring again until explicitly reenabled (at step 9 below).<br>
</li>
<li>The LVDC allows any instruction, multiplication, or division
in progress to complete.</li>
<li>The LVDC performs a <span style="font-family: Courier
New,Courier,monospace;">HOP 0400</span>, thus transferring
control to an interrupt-service routine—or, as the original
documents refer to it, an "input-output subprogram".
Recall that this does not jump to address 0400, rather it loads
the HOP Register from the value stored at address 0400, and this
can be used to jump to a location, set the current memory module
and sector, etc. (Early non-flight hardware seemingly used
a <span style="font-family: Courier New,Courier,monospace;">HOP
0776</span> instead of <span style="font-family: Courier
New,Courier,monospace;">HOP 0400</span>.)<br>
</li>
<li>The <span style="font-style: italic;">first</span>
instruction executed by the interrupt service routine must be
either <span style="font-family: Courier
New,Courier,monospace;">STO 0776</span> or <span
style="font-family: Courier New,Courier,monospace;">STO 0777</span>
to store the pre-interrupt value of the HOP Register at either
address 0776 or 0777.</li>
<li>The interrupt service routine should then save any registers
or common memory locations that were going to be altered into
local storage. In almost all cases, one would suppose that
the accumulator needed to be stored. If multiplications or
divisions would be used, the P-Q Register would also need to be
saved, presumably with a pair of instructions like <span
style="font-family: Courier New,Courier,monospace;">CLA 0775</span>
followed by <span style="font-family: Courier
New,Courier,monospace;">STO <span style="font-style: italic;">somewhere</span></span>.</li>
<li>The interrupt service routine should do a <span
style="font-family: Courier New,Courier,monospace;">PIO</span>
from the Interrupt Storage input port to determine which of the
12 interrupt sources are active, so that it can vector to an
appropriate service routine for it.<br>
</li>
<li>The interrupt service routine should then do whatever
computations it needed to do.</li>
<li>The interrupt service routine should restore the registers it
had saved (<span style="font-family: Courier
New,Courier,monospace;">CLA <span style="font-style: italic;">somewhere</span></span>
followed by <span style="font-family: Courier
New,Courier,monospace;">STO 0775</span> to restore the P-Q
Register, if necessary, followed by a restoration of the
accumulator).</li>
<li>The interrupt service routine should do a <span
style="font-family: Courier New,Courier,monospace;">PIO</span>
to the Interrupt Register Reset output port, with just the
specific bit set corresponding to the interrupt type being
processed, to reenable that specific interrupt. The
particular flavor of <span style="font-family: Courier
New,Courier,monospace;">PIO</span> performed should, of
course, take the Data Source from memory rather than from the
accumulator, since at this point the accumulator has already
been restored to its pre-interrupt condition.<br>
</li>
<li>The return from interrupt is either <span style="font-family:
Courier New,Courier,monospace;">HOP 0776</span> or <span
style="font-family: Courier New,Courier,monospace;">HOP 0777</span>,
depending on which location the HOP constant had been stored on
entry to the interrupt service routine.</li>
</ol>
Interrupts can be programmatically masked or unmasked with <span
style="font-family: Courier New,Courier,monospace;">PIO</span> to
Interrupt Inhibit. By setting a bit in Interrupt Inhibit
corresponding to the interrupt whose masking is desired, that
interrupt is thereby masked. Any combination of bits can be
set, so any combination of interrupts can be masked. To
reenable the interrupt, a 0 is written to the corresponding bit in
Interrupt Inhibit.<br>
<br>
The available interrupts, and their bitwise positioning in the i/o
registers mentioned above, differed for the Saturn IB rocket (Apollo
7, ASTP, Skylab) vs. the Saturn V rocket (Apollo 8-17). The
Saturn IB and Saturn V descriptions below were taken from different
documents (namely, <a
href="Documents/MSFC-MAN-206-SkylabSaturnIBFlightManual.pdf"> <span
style="font-style: italic;">Skylab Saturn IB Flight Manual</span></a>
p. 6-21 and <a style="font-style: italic;"
href="Documents/MSFC-MAN-503-SaturnFlightManual-SA503.pdf"> Saturn
Flight Manual, SA-503</a> p. 7-21, respectively), and if one
accounts for the differences in language between the two documents,
the interrupts are almost entirely the same. I've marked the ones in
<span style="color: rgb(255, 0, 0);">red</span> that seem different
to me, as well as any other points of particular difficulty for me.<br>
<br>
<table summary="" style="text-align: left; margin-left: auto;
margin-right: auto;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th style="font-weight: bold; text-align: center;">LVDC Data
Word Bit Position<br>
</th>
<th style="font-weight: bold;">Description of function in
Saturn IB<br>
</th>
<th style="font-weight: bold;">Description of function in
Saturn V<br>
</th>
<th style="vertical-align: middle;">Are these actually the
same thing?<br>
</th>
<th>Comments<br>
</th>
</tr>
<tr>
<td style="text-align: center;">11<br>
</td>
<td>RCA-110A interrupt<br>
</td>
<td>Command LVDA/RCA-110A interrupt<br>
</td>
<td>Probably.<br>
</td>
<td>The RCA-110A is the ground-control computer. This
interrupt implies that a command word has been received via
digital uplink and is ready to be processed. See
section 6.2.3 of <a style="font-style: italic;"
href="Documents/MSFC-IV-4-401-1-AstrionicsSystemHandbookSaturnLaunchVehicles.pdf">Astrionic
System Handbook, Saturn Launch Vehicles</a>.</td>
</tr>
<tr>
<td style="text-align: center;">10<br>
</td>
<td>S-IB low-level sensors dry "A"<br>
</td>
<td>S-IC inboard engine out "A"<br>
</td>
<td>If interpreted as "first stage engine out", yes.</td>
<td><br>
</td>
</tr>
<tr>
<td style="text-align: center;">9<br>
</td>
<td>RCA-110A interrupt<br>
</td>
<td>Program re-cycle (RCA-110A) interrupt<br>
</td>
<td>Probably.<br>
</td>
<td>The RCA-110A is the ground-control computer. The
following is partly speculation, so take it with a grain of
salt: I believe that this interrupt may occur when a special
uplink command ("Terminate") is received. The purpose
of the "Terminate" command is to halt an operation from a
previously uplinked command (see above) and to return the
LVDC flight program to normal operation. Since the
"command LVDA/RCA-110A" interrupt would be disabled until
that processing is completed, a separate interrupt for the
"Terminate" command is needed, and that is the "Program
re-cycle" interrupt.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">8<br>
</td>
<td>S-IVB engine out "B"<br>
</td>
<td>S-IVB engine out "B"<br>
</td>
<td>Yes.<br>
</td>
<td><br>
</td>
</tr>
<tr>
<td style="text-align: center;">7<br>
</td>
<td>S-IB outboard engines cutoff "A"<br>
</td>
<td>S-IC propellant depletion/engine cutoff "A"<br>
</td>
<td>If interpreted as "first stage engine cutoff", yes.</td>
<td><br>
</td>
</tr>
<tr>
<td style="text-align: center;">6<br>
</td>
<td>Manual initiation of S-IVB engine cutoff "A"<br>
</td>
<td>S-II propellant depletion/engine cutoff<br>
</td>
<td style="color: rgb(255, 0, 0);">Both refer to the second
stage, but ... don't know!<br>
</td>
<td><br>
</td>
</tr>
<tr>
<td style="text-align: center;">5<br>
</td>
<td>Guidance reference release<br>
</td>
<td>Guidance reference release<br>
</td>
<td>Yes.<br>
</td>
<td><br>
</td>
</tr>
<tr>
<td style="text-align: center;">4<br>
</td>
<td>Command decoder interrupt "A" or "B"<br>
</td>
<td>Command receiver interrupt<br>
</td>
<td>Probably.<br>
</td>
<td><span style="color: rgb(255, 0, 0);">I think this
interrupt comes from the decoder that interprets uplinked
data (see the two RCA-110A interrupts above), but it's
unclear to me what the purpose is, or how "A" and "B"
differ.</span><br>
</td>
</tr>
<tr>
<td style="text-align: center;">3<br>
</td>
<td>Simultaneous memory error<br>
</td>
<td>Temporary loss of control<br>
</td>
<td>Yes.<br>
</td>
<td>"Simultaneous memory error" refers to simultaneous parity
errors in a single address mirrored in duplexed memory
modules. This is also known by the acronym TLC, which
is related in an obvious way to the description "Temporary
Loss of Control" supplied by the documentation.
However, "temporary loss of control" is quite an optimistic
way of looking at it, because there is no method of recovery
from it. Far from being "temporary", the error is
basically immediately catastrophic in the real world of the
rocket, and therefore very permanent. I have been told
that the LVDC programmers called this the "Tough Luck
Charlie" interrupt, and indeed there is a reference to this
in the LVDC source code.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">2<br>
</td>
<td>Spare<br>
</td>
<td>Computer interface unit interrupt<br>
</td>
<td style="color: rgb(255, 0, 0);">No.<br>
</td>
<td><br>
</td>
</tr>
<tr>
<td style="text-align: center;">1<br>
</td>
<td>Internal to the LVDC<br>
</td>
<td>Switch selector interrupt<br>
</td>
<td rowspan="2">Probably.<br>
</td>
<td rowspan="2">The switch-selector interrupt and the
minor-loop interrupt are generated internally by the
LVDC/LVDA.<br>
</td>
</tr>
<tr>
<td style="text-align: center;">S<br>
</td>
<td>Internal to the LVDC<br>
</td>
<td>Minor loop interrupt<br>
</td>
</tr>
</tbody>
</table>
<h4><a name="Interrupts_of_PTC"></a>Interrupts of PTC</h4>
<p>There are up to 16 external interrupt sources for the PTC.
Interrupts of the first 15 types are generated by the circuitry of
the PTC that corresponds to an LVDA, and is latched in the LVDA,
whereas the 16th type is generated by a pushbutton ("I16") on the
PTC control panel.<br>
</p>
<p>When one of these interrupts occurs, assuming that interrupts
have not been inhibited, the following actions occur:<br>
</p>
<ol>
<li>The PTC allows any instruction in progress to complete.</li>
<li>The PTC masks further interrupts, until explicitly reenabled
(either programmatically at step 8 below, or else by switches on
the PTC control panel).</li>
<li>The PTC performs a <span style="font-family: Courier
New,Courier,monospace;">HOP</span> using one of the
HOP-constants stored at addresses 0400 through 0417 (locations 0
through 017 of module 0 sector 017), depending on the source of
the interrupt, thus transferring control to an interrupt-service
routine appropriate to the interrupt source. Recall that
this does not jump <i>to</i> one of these addresses, rather it
loads the HOP Register from the value stored at the address,
which has the effect of jumping to the location described by the
HOP constant, setting the current memory module and sector,
etc. Thus an interrupt of type 1 basically executes a <font
face="Courier New, Courier, monospace">HOP 401</font>, an
interrupt of type 2 executes a <font face="Courier New,
Courier, monospace">HOP 402</font>, etc.<br>
</li>
<li>The <span style="font-style: italic;">first</span>
instruction executed by the interrupt service routine must be
either <span style="font-family: Courier
New,Courier,monospace;">STO 0776</span> or <span
style="font-family: Courier New,Courier,monospace;">STO 0777</span>
to store the pre-interrupt value of the HOP Register at either
address 0776 or 0777.</li>
<li>The interrupt service routine must then immediately save any
registers or common memory locations that were going to be
altered into local storage. In almost all cases, one would
suppose that the accumulator needed to be stored.</li>
<li>The interrupt service routine should then do whatever
computations it needed to do.</li>
<li>The interrupt service routine should restore the registers.</li>
<li>The interrupt service routine should perform the appropriate <tt>CIO</tt>
instruction(s) for reenabling the masked interrupts.<br>
</li>
<li>The return from interrupt is either <span style="font-family:
Courier New,Courier,monospace;">HOP 0776</span> or <span
style="font-family: Courier New,Courier,monospace;">HOP 0777</span>,
depending on which location the HOP constant had been stored on
entry to the interrupt service routine.</li>
</ol>
In the PAST program specifically, space for the HOP constants of the
first 15 interrupt vectors is allocated but no constant values are
assigned at assembly time. The HOP constants are instead
assigned dynamically later under program control as part of the
self-testing process. On the other hand, the 16th vector
(manual interrupt 16) is always processed at label <tt>L17P2</tt>
in the source code.<br>
<br>
The available interrupts are:<br>
<br>
TBD<br>
<h3><a name="Telemetry" id="Telemetry"></a>Telemetry</h3>
Output telemetry from the Instrumentation Unit transmitted to
mission control can be sourced from either the LVDC or the
LVDA. The LVDA spontaneously outputs telemetry on its own
accord only when an error indication appears in its error-monitor
register. The normal telemetry case, however, is that the LVDC
initiates output telemetry by sending data to the LVDA via a <tt>PIO</tt>
CPU instruction, and then the LVDA handles subsequent details of
actually transmitting the data. In both cases, the output is
in the form of 10-bit arrays, though the output packet logically
consists of 4 such successive 10-bit arrays: i.e., of 40 bits.
<br>
<br>
However, the specifics differ depend somewhat on the source.
We'll confine our description to data sourced by the LVDC. As
mentioned above, telemetering an output 40-bit packet from the
LVDC's perspective is done by means of the CPU's <tt>PIO</tt>
instruction, for which <a
href="LVDC.html#IO_Ports_For_PIO_Instruction">a variety of i/o
addresses are reserved for telemetry operations</a>. Of the
40 bits:<br>
<ul>
<li>26 bits are the data payload. These bits come directly
from the operand of the <tt>PIO</tt> instruction.</li>
<li>9 bits are a tag indicating the specify type of data in the
packet.</li>
<ul>
<li>Bit A9: TBD</li>
<li>Bit A8: 1. (1 for telemetry requested by the LVDC, and
0 for the LVDA.)</li>
<li>Bits A7-A1. These apparently come from the i/o address
in the <tt>PIO</tt> instruction. For example, the
instructions <tt>CLA =67 / PIO 040</tt> would end up setting
A7-A1 of the tag to 040 (octal), while the data payload would
be set to 67 (decimal).<br>
</li>
</ul>
<li>3 bits determine the "mode". I'm not sure where these
bits come from, but perhaps they come from the mode register,
which the LVDC software sets via <tt>PIO 006</tt>.<br>
</li>
<li>1 bit indicates validity of the packet. The value of the
bit is 0 if valid and 1 if invalid, and is present because the
LVDC <tt>PIO</tt> operation can clobber an output already in
progress, due to lack of synchronization between the LVDC and
LVDA. At any rate, this bit is manipulated by the LVDA,
and is transparent to the LVDC.<br>
</li>
<li>1 bit is parity. The overall parity of the 40-bit packet
is odd. The parity bit is generated by the LVDA, and is
transparent to the LVDC.</li>
</ul>
Different documentation differs in describing the arrangement of
these various bits within the 40-bit packet, and does not fully
explain the transmission order of the bits, so I'll refrain from
discussing that topic here.<br>
<br>
A 40-bit packet requires 4.17 milliseconds to transmit, and thus the
LVDC needs to space out its telemetry requests by at least this
amount of time, or else subsequent telemetry request it outputs to
the LVDA will overwrite and destroy prior requests.<br>
<br>
As far as the numerical specifics of the tag values used in the
40-bit packets, this is TBD.<br>
<h3><a name="Up-data"></a>Up-data</h3>
<p>(A lot of information in this section is abstracted from the <a
href="Documents/AstrionicsSystemsHandbook_Nov69.pdf">Astrionics
System Handbook</a>, chapter 6, "Radio Command Systems".)<br>
</p>
<p>The term <i>up-data</i> refers to commands transmitted from
mission control to the LVDC/LVDA.<br>
</p>
<p>As transmitted, the standard command-word format consists of 35
bits:<br>
</p>
<ul>
<li>3 bits are referred to as the "X" bits. They form an
address, indicating which vehicle the message is intended for. <br>
</li>
<li>14 bits are also an address, but they identify a specific
"command decoder" for processing the message. A vehicle
may have multiple command decoders with different hard-coded
addresses.<br>
</li>
<li>18 bits comprise the control and data portions of the message.<br>
</li>
</ul>
<p>The latter two sets of bits are interspersed within the message,
and thus are not transmitted in the specific order shown above.<br>
</p>
<div align="center"><img alt="" src="upDataLVDC.png" width="923"
height="501"></div>
<p>However, the as-transmitted format of the data isn't really very
relevant to how the LVDC and its software relate to the up-data,
since only a portion of the transmitted bits reach the LVDC
software — specifically only some of the bits from the final group
of 18 — and even then they don't always reach the LVDC in the
exact form they are transmitted. Thus, let's narrow our
discussion of the up-data to just the LVDC's perspective.
The 18 control&data bits of the message are further
categorized as:<br>
</p>
2 "OM/D" or <i>orbital mode/data</i> (OM/D) bits. (These
are depicted in the image above, presumably mistakenly, as <b>D</b>M/D
bits.) The LVDA combines this pair of bits (in some manner
unknown to me), and thus the LVDC receives a single OM/D bit.
The LVDC recognizes two types of commands, <i>mode commands words</i>
and <i>data command words</i>, and the type of the command word is
determined by the OM/D bits. <br>
<p>Similarly, there are two transmitted "interrupt bits" (see the
image above). These cause an interrupt to occur in the LVDC,
which I believe is designated in <a href="#Interrupts">the
interrupt table given earlier as bit-position 4</a>, Command
Receiver Interrupt.<br>
</p>
<p>Finally, the 14 remaining bits actually represent just 7 bits of
actual information, since each bit appears both in its normal form
and in its logically-complemented form for the purpose of
error-detection. <br>
</p>
<p><img alt="" src="commandWordFormat.png" width="363" height="411"
align="right">Refer to section 6.2 of <a
href="Documents/AstrionicsSystemsHandbook_Nov69.pdf">the
Astrionics System Handbook</a> for more detail, but the LVDC
software accesses the received command using the following general
steps:<br>
</p>
<ul>
<li>Do unrelated processing until the Command Receiver interrupt
occurs. </li>
<li>Interrogate the OM/D bit of <tt>PIO 057</tt> to verify that
its value is 1. This means that the received word is a
"mode command word". (The first word of any sequence of
commands will be a mode command word, followed by some number of
"data command words".)<br>
</li>
<li>Interrogate <tt>PIO 043</tt> to get the value of the mode
word, and parses it to determine the specific command that has
been requested. Each command type will imply the number of
data command words that will be subsequently transmitted and
processed. For the sake of discussion, let's call that
number <i>N</i>.<br>
</li>
<li>Outputs telemetry (TBD) indicating successful reception of a
command word.</li>
<li>For each of the <i>N</i> data command words that are supposed
to be received for this sequence, do the following:</li>
<ul>
<li>Do unrelated processing until the Command Receiver interrupt
occurs.</li>
<li>Interrogate the OM/D bit of <tt>PIO 057</tt> to verify that
its value is 0. I.e., that the received word is a data
command word.</li>
<li>Get the received word using <tt>PIO 043</tt>.</li>
<li>Buffer the received word in memory.</li>
</ul>
<li>After all of the <i>N</i> data words are received, perform
whatever action is appropriate for the now-completely-received
command.</li>
</ul>
<p>The command word read using <tt>PIO 043</tt> has the format
shown in the illustration to the right. As mentioned above,
there are 7 actual data bits, but they appear twice each:
Once "normally", and once inverted. Besides that, there is a
"sequence bit" which also appears normally (bit 8) and inverted
(bit 1). This bet helps to make sure the command words have
been received in an appropriate order. The sequence bit is 0
for the mode command word, then 1 for the first data command word
(if any), and then it just toggles between 0 and 1 for each
subsequent data command word received. When the next mode
command word is received, the sequence bit goes back to 0 and the
pattern repeats.<br>
</p>
<p><br>
</p>
<h3> </h3>
<h2><a name="LVDC_Assembly_Language" id="LVDC_Assembly_Language"></a>LVDC
Assembly
Language</h2>
Unfortunately, there is no surviving manual or other reference
describing the syntax of LVDC assembly language, nor the pseudo-ops
available in it, nor any source code for the original LVDC
assembler. <br>
<br>
This section is a compilation of my own inferences about those
things from evaluating the available LVDC source code and from
writing my own LVDC assembler, and then subsequently updating for
PTC source code that was acquired later. The description is
intended to be authoritative only in the sense that it describes how
my own assembler (<a href="#yaLVDCASM_the_LVDC_Cross-Assembler">yaASM.py</a>),
which does produce an assembled core-rope image identical to that of
the original assembler, handles the code. However, my
description shouldn't be taken as authoritative in any larger
sense. For example, when I say below that the assembler has an
initial "preprocessor pass" that performs certain processing, I mean
that yaASM.py has such a pass; I <i>imagine</i> that the original
assembler did as well, but cannot guarantee it.<br>
<br>
You'll probably need to refer to the previous <a
href="#CPU_Instructions">discussion of the CPU instructions</a>
from time to time, in order to follow the discussion.<br>
<h3><a name="Basic_Factoids"></a> Basic Factoids</h3>
<i>Empty lines</i>: Are ignored by the assembler.<br>
<br>
<i>Code comments (original Project Apollo)</i>: Full-line
comments seem to be prefixed by the character '*' in column 1.
Anything left over at the end of a line after the beginning of a
line has been correctly parsed seems to be treated as a comment, and
doesn't require any '*' prefix.<br>
<br>
<i>Code comments (modern Virtual AGC Project)</i>: Comments <i>I've</i>
added that were not present in the original listing are all
full-line comments but with a '#' character in column 1.<br>
<br>
<i>Character set</i>: Upper-case alphabetic, numeric, and some
punctuation. This isn't really any great surprise, of course,
if you reflect that all of the source code was supplied on computer
punch cards to the IBM/360 mainframe computer which ran the
assembler program, and that the character sets supported by keypunch
machines did not include lower-case characters anyway. Douglas
Jones has written a fun <a
href="http://homepage.divms.uiowa.edu/%7Ejones/cards/index.html">exploration
of punch cards</a>, if you're interested in that kind of
thing. (By the way, I've heard anecdotally that the executable
program which was output by the assembly of the LVDC software was
punched into a long mylar tape, perhaps 1.5" wide, which was then
transported by the coders themselves to Marshall Space Flight
Center, where the mylar tape was put into a tape reader which
transferred the program into the ferrite-core memory of the LVDC
itself. This was possible because, as you may recall from
above, all of the ferrite cores in the LVDC were both readable <i>and</i>
writable. This contrasts to the AGC, in which the program was
stored in read-only memory which had to be <i>manufactured</i>
rather than simply written to. So installing the software in
the LVDC was a far less painful, less expensive, much quicker
process than installing software in the AGC. In the case of
the AS-206RAM program listing, the assembler helpfully reports that
the punch tape is 432 feet long.)<br>
<br>
<i>Symbols</i> (names of variables, constants, subroutines,
...): 6 characters or less, alphanumeric, with the leading
character alphabetic. They may also contain the character ".",
though not in the leading position.<br>
<i><br>
Literal numerical constants</i>: Decimal literals are as you
might expect from working with AGC code. They are just regular
decimal numbers, possibly with a suffixed exponent "<tt>E</tt><tt><i>n</i></tt>"
for powers of 10, or a suffixed "<tt>B<i>n</i></tt>" for binary
scaling, or both. Suffixed exponents and scales, if both are
present, can be in either order.<br>
<br>
As far as octal literals are concerned, some contexts (such as the <tt>OCT</tt>
pseudo-op or the <tt>PIO</tt> instruction) specifically require
them, in which case there's no special syntax to distinguish them
from decimal numbers, other than the fact that they're not
associated with the digits '8' or '9', with decimal points, nor with
exponents. In some usages there is ambiguity, which case the
octal literal is prefixed by 'O' (upper-case alphabetical character,
<i>not</i> a zero).<br>
<br>
Regarding conversion of literal numerical constants to bit patterns
actually stored within 26-bit memory words, there seem to be three
basic patterns:<br>
<ul>
<li>Pure octal constants are <i>left</i>-aligned in their memory
word. In other words, a constant of <i>N</i> octal digits
would be right-padded by 26-<i>3N</i> bits of 0.<br>
</li>
<li>Pure decimal (integer) constants are fully <i>right</i>-aligned.
In other words, a decimal integer encoded as <i>N</i> bits
would be sign-extended on the left by 26-<i>N</i> bits.</li>
<li>Decimal non-integer constants are treated as being in the
range -1.0 < <i>constant</i> < 1.0. </li>
</ul>
<p><i><a name="AngleUnits"></a>Units of angular measurement</i>:
For most internal purposes, the source code typically measures
angles in a unit called a <i>pirad</i>. I can find no
reference to any unit by this name outside of the LVDC source
code, nor does the LVDC source code choose to define it in the
program comments. However, from the usage, it seems pretty
clear that<br>
</p>
<blockquote>1 pirad = 180° = <font face="Times New Roman, Times,
serif">π</font> radians<br>
</blockquote>
And then there are <i>ladder units</i>. They are undefined,
of course, but I suspect this is the form required for outputting
angular commands to external hardware:<br>
<blockquote>1° = 1/0.06 ladder units<br>
</blockquote>
There are also references to angles measured in <i>2016 fine units</i>,
again undefined. Apparently, the "fine" refers to "fine
resolvers", and thus is likely the form in which the angular data is
delivered to the LVDC from the resolvers. At any rate, it
appears that<br>
<blockquote>1° = 2016/5.625 fine units<br>
</blockquote>
Finally, there are references to <i>backup units</i>, which are
(you guessed it!) undefined. It appears that<br>
<blockquote>1° = 2016/180 backup units<br>
</blockquote>
<i>Units of time</i>: The source code sometimes refers to a
unit of time measurement it calls <i>qms</i>, but does not
define. I suspect this is the unit of measurement in which the
real-time clock delivers data to the LVDC. Apparently,<br>
<blockquote>1 ms = 1/0.24609375 qms<br>
1 ms ≈ 4.063492 qms<br>
</blockquote>
In other words, "qms" probably stands for "quarter millisecond".<br>
<blockquote>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</blockquote>
<blockquote></blockquote>
<ul>
</ul>
<i>Format of a non-comment line</i>: <br>
<ul>
<li>Columns 1-6: Optional symbol, supplying a name for the
memory location of the current line of code. The original
coders called these "left-hand symbols".</li>
<li>Columns 8-15: The name of the CPU instruction,
pseudo-op, or macro. Notice that this is <i>not</i>
aligned with what is sometimes thought of as the default
position of a "tab stop", which would have been at column 9.</li>
<li>Columns 16-28: The operand. I'll talk more about these
operands below.<br>
</li>
<li>29-75: Comment, possibly blank. </li>
<li><a name="SequenceNumber"></a>75-80: Sequence number,
consisting of 6 decimal digits. These sequence numbers
came directly from the original punch cards. As a
convention, the sequence numbers are unique, and are in
increasing order from one line to the next ... almost always,
the sequence numbers increment by 10 from one line to the
next. Nevertheless, there are chunks of code having no
sequence numbers at all. When that happens, the assembler
simply adds 10 to the last sequence number it saw, and then
assigns that same number to all subsequent lines until
encountering a card with an actual sequence number on it.
(I'm <i>not</i> saying it increments the sequence number by 10
on every unnumbered line; it increments it just once, and then
keeps giving line after line the <i>same</i> number.)
Given that fact, it's pretty obvious that the cards were
processed in the order they were encountered, rather than being
rearranged internally to the assembler in sequence-number
order. I don't believe the original assembler needed to
use these sequence numbers other than for reference purposes in
the symbol table (see below).</li>
</ul>
<p>By the way, these observations about columnar alignment don't
relate to the new assembler (yaASM.py), which does not generally
enforce or use the columnar alignment in any way, other than to
recognize that column 1 is special. (Exception: The <tt>BCI</tt>
pseudo-op used in PTC source code is special and <i>does</i>
require column alignment.) I don't know if the original
assembler actually cared about the columnar alignment, or whether
the alignment I've observed is simply a convention.<br>
</p>
<ul>
</ul>
<h3><a name="Preprocessor_Pass"></a>Preprocessor Pass</h3>
<p>The LVDC assembler is a macro assembler, meaning that the
language it processes has a variety of constructs intended to make
coding easier and more manageable but which aren't directly
related to the internal characteristics of the LVDC CPU.
These constructs are all resolved and removed from the code by a
dedicated preprocessor pass prior to any assembly of actual LVDC
instructions or allocation of LVDC memory. The various
preprocessor constructs that appear in LVDC code are described in
this section.<br>
</p>
<p>The preprocessor itself operates in a single pass, and therefore
any symbols or macros it uses must have been defined prior in the
source code to such use. I don't think that any of the
features mentioned in this section are used the PTC source code
available to us, so it's possible that the early versions of the
assembler used for PTC didn't have a preprocessor at all.<br>
</p>
<i>The </i><i><tt>CALL</tt></i><i> macro</i>: <tt>CALL</tt>
is a macro hard-coded into the assembler itself. By a "macro",
I mean that superficially it is used in source code as if it were a
CPU instruction, but it is not a CPU instruction. Rather, it
is a shorthand for a sequence of several CPU instructions. A
single <tt>CALL</tt> is expanded by the preprocessor into the
appropriate stream of true CPU instructions. When I say it is
"hard-coded" into the assembler, I mean that the language also
includes ways for the programmer to define his own custom macros
within the LVDC program if he wants, but that there are no such
definitions for the <tt>CALL</tt> macro in the LVDC source code.<br>
<br>
It is probably hard-coded in the assembler rather than having a soft
definition within the source code because there are two distinct
variations of it.: There are both 2-argument and 2-argument
variants of the macro. The 2-argument version is used for
calling a subroutine having a single input argument. The macro
is invoked by a source-code line of the form<br>
<blockquote><tt>CALL <i>ARG1</i>,<i>ARG2</i></tt> <br>
</blockquote>
which the preprocessor replaces by a pair of actual instructions, <br>
<blockquote><tt>CLA <i>ARG2</i></tt><br>
<tt>HOP <i>ARG1<br>
</i></tt></blockquote>
All three lines appear in assembly listings, but the <tt>CALL</tt>
is treated as a comment and the other two have a '+' character
printed next to them to show that they're there due to the expansion
of the macro. <br>
<br>
The 3-argument version,<br>
<blockquote><tt>CALL <i>ARG1,ARG2,ARG3</i></tt> <br>
</blockquote>
instead expands as<br>
<blockquote><tt>CLA ARG3<br>
STO 775<br>
CLA ARG2<br>
HOP ARG1<br>
</tt></blockquote>
and thus calls a subroutine with two input arguments.<br>
<br>
<i>General macro-definition facility</i>: As I said above, the
macro facility is general-purpose, and custom macros can also be
defined within the source code. The syntax used for defining a
macro is as follows:<br>
<blockquote><tt><i>NAME</i>
MACRO ARG1,ARG2,...<br>
... code using the symbols
ARG1, ARG2, and so on ...<br>
ENDMAC<br>
</tt></blockquote>
Once defined, <i><tt>NAME</tt></i> can be used to invoke the
associated macro.<br>
<br>
Note that in the <i>definition</i> of the macro, the strings <tt>ARG1</tt>,
<tt>ARG2</tt>, and so on are literal. You can't <i>define</i>
a macro with arbitrary arguments names like (say) <tt>x</tt>, <tt>y</tt>,
and <tt>z</tt>. <br>
<br>
As an example, consider the 2-argument the <tt> CALL</tt> macro
described earlier. It is hard-coded into the assembler, and
therefore doesn't require a definition in the code, but if it
weren't hard-coded it could have been giving the following soft
definition:<br>
<blockquote><tt>CALL MACRO
ARG1,ARG2<br>
CLA
ARG2<br>
HOP ARG1<br>
ENDMAC<br>
</tt></blockquote>
<i>Pseudo variables</i>: "Pseudo variables" are named numeric
constants known only by the preprocessor. Any usages of such
pseudo variables are replaced by numeric literals by the
preprocessor, and thus none of them remain in the code by the time
the actual assembly process begins. This implies that the
namespace for pseudo variables is distinct from that for left-hand
symbols in general, so a pseudo variable can have the same name as a
block of code or a data variable in memory without overlap.<br>
<br>
Pseudo variables are <i>defined</i> by the EQU pseudo-op, with a
syntax like the following:<br>
<blockquote><tt><i>NAME</i></tt><tt>
EQU (</tt><tt><i>EXPRESSION</i></tt><tt>)</tt><br>
</blockquote>
In the operand here, the parentheses are literal and must always be
present. <tt><i>EXPRESSION</i></tt> is an arithmetical
expression involving numeric literals, the operations + - * /,
parentheses, and other (previously-defined) pseudo variables.
For example,<br>
<blockquote><tt>OMEGA EQU
(.72921141E-4)</tt><tt><br>
</tt><tt>RWCP EQU
(OMEGA*6373377*.87993)</tt><br>
</blockquote>
In general, parenthesized expressions involving pseudo-variables
like this can appear anywhere in LVDC source code, and is replaced
by the preprocessor with the numeric literals. Except for
appearing as left-hand symbols in <tt>EQU</tt> statements, pseudo
variables appear <i>only</i> with such parenthesized expressions,
or in tests for conditional assembly (see below).<br>
<br>
In most usages, an <tt>(<i>EXPRESSION</i>)</tt> appearing in an
assembly language operand can be suffixed with an optional binary
scaling factor<br>
<blockquote><tt>(<i>EXPRESSION</i>)B<i>n</i></tt></blockquote>
The optional scaling factor doesn't really make sense if it were
used in the <tt>EQU</tt> statements defining the pseudo-variables,
since the purpose of the scaling factor is really a relationship
between the logical value of the number and the physically-pragmatic
pattern of bits stored in memory. Nevertheless, the assembler
allows any expression to be thusly suffixed by a scaling factor,
even in the <tt>EQU</tt> statement itself. <br>
<i></i><i><br>
Conditional assembly</i>: Code can be conditionally retained
or discarded by the preprocessor the basis of a test, with the
syntax<br>
<blockquote>
<p><tt>IF <i>PSEUDOVARIABLE</i><i></i>=(<i>EXPRESSION</i>)<br>
... code ...<br>
ENDIF<br>
</tt></p>
</blockquote>
If the value of the specified pseudo variable is equal the evaluated
expression, then enclosed code is retained by the preprocessor, and
is thus eventually assembled. If not, then the enclosed code
is discarded.<br>
<h3><a name="Assembly_Pass"></a>Assembly Pass</h3>
<p>(Technically, what I'm calling the "assembly pass" here is really
implemented in the new assembler, yaASM.py, in two successive
passes, known the "discovery pass" and the "assembly pass".
The former associates all program labels and variable names with
physical addresses, while the latter performs the actual assembly
using the now-resolved addresses. That detail is totally
irrelevant and transparent to the user, but would be necessary
information to anybody modifying yaASM.py itself.)<br>
</p>
<i></i>
<p><i>Instruction operands</i>: Operand formats differ for
some CPU instruction types, but most of them require a variable (a
word in data memory), and conform to a pattern in which there are
several allowed variants for specifying the operand:<br>
</p>
<ol>
<li>A literal 3-digit octal number (such as 777 or 776), which is
an offset into the DM/DS (Data Module / Data Sector) defined by
the current contents of the HOP register.<br>
</li>
<li>The symbolic name of a variable or constant defined elsewhere
in the program. The variable/constant has to be in the
current DM/DS, so if the referenced symbol doesn't happen to be
located in that particular module or sector, it could be a
problem.</li>
<li>An arithmetical expression involving symbolic names, such as <tt>CBTAB+1</tt>
or <tt>CBTAB+(4*CBSTNO+1)</tt>. For a sufficiently
complex expression, since as the latter one in the preceding
sentence, the raw form of the instruction will appear in the
assembly listing as if it were a comment (like a <tt>CALL</tt>
line), and the fully resolved expression will appear marked with
a "+" character as if it were a macro expansion ... which it
probably is. For example, if <tt>(4*CBSTNO+1)</tt>
resolves to 57, then the expanded instruction would be <tt>CBTAB+57</tt>.
Note that such expressions, depending on what they contain, may
resolve <i>either</i> to an address in memory, or else to a
constant value. In the latter case, the numerical constant
is treated like the constants described in the following item.<br>
</li>
<li>The character <tt>=</tt>, prefixed to a literal numerical
constant. Here the assembler allocates an <i>unnamed</i>
variable in the current DM/DS, stores the value of the constant
at that variable, and then uses the location of the new-created
variable as the operand. In other words, not all program
variables are explicitly defined by pseudo-ops ... some of them
are transparently allocated in as needed by the assembler itself
in memory locations not previously used for anything..
Each numerically-unique constant is stored only once as a
variable and is reused everywhere that requires it. For
example, in the AS-206RAM LVDC assembly listing, <tt>=1B18</tt>
is an operand in the lines with sequence numbers 051570 and
051910, while <tt>=00000004</tt> is used at 051950 and 053380,
but they both evaluate to the same numerical value and thus
reference the same memory location (2-06-076). Note that
if the literal numerical constant begins with the character 'O'
(alphabetic, not digit) then the number is octal, while if the
leading 'O' is not present then the number is decimal.</li>
<li>For PTC <i>only</i>: The PTC version of the assembler
had an extraordinarily dangerous "feature", which thankfully had
been removed by the time of the LVDC version of the
assembler. If an operand was encountered which would
ordinarily be the name of a variable, but for which no actual
variable with that name was explicitly allocated in the source
code, then the assembler would <i>automatically</i> <i>silently</i>
allocate one in unused memory, in the same manner as for
operands like <tt>=O<i>octal</i></tt> <i>constants</i>
described in the item above. What makes this dangerous is
the possibility of a typo in a variable name at one place in a
program but not in other places. For example, if you had
the following code, you'd think the <tt>CLA</tt> was accessing
<tt>ARGX12</tt> (with the value 12345 octal), when in reality a
new variable <tt>ARCX12</tt> (with the value 0) had been
created, and the <tt>CLA</tt> would be accessing that instead.
<br>
</li>
</ol>
<blockquote>
<blockquote>
<p><tt>ARGX12 OCT 12345<br>
...<br>
CLA ARCX12
MISTYPED "ARGX12" AS "ARCX12"<br>
</tt></p>
</blockquote>
</blockquote>
<ol>
</ol>
<p>Except for the <tt>HOP</tt><tt></tt> instructions, the other CPU
instructions that transfer program control target a location in
the current IM/IS rather than a variable in the DM/DS, and thus
require a different type of operand. Those instructions (<tt>TRA</tt>,
<tt>TNZ</tt>, <tt>TMI</tt>) thus have operands in one of the
following two formats:<br>
</p>
<ul>
<li>The symbolic name of a code location in the current IM/IS.</li>
<li>"<tt>*+<i>n</i></tt>" or "<tt>*-<i>n</i></tt>", where <tt><i>n</i></tt>
is a literal decimal constant. This references the memory
location <tt><i>n</i></tt> words later or earlier than the
current instruction, respectively. (I say that the literal
constant is <i>decimal</i> because yaASM.py implements it in
that way. However, there are no instances of <tt><i>n</i></tt>>7
in the existing LVDC source code, so I really have no way of
knowing whether the original assembler accepted decimal
constants or octal ones.)<br>
</li>
</ul>
<ul>
</ul>
<p>Other exceptions:<br>
</p>
<ul>
<li>The shift instruction, <tt>SHF</tt>, and the shorthand
replacements for it, <tt>SHR</tt> and <tt>SHL</tt>. The
latter two shorthand instructions take an operand of 0 or a
positive decimal integer, and thus represent logical right or
left shifts by a selectable number of positions. With "<tt>0</tt>"
as the operand, as a special case, the accumulator is
cleared. There are no uses of <tt>SHF</tt> in the
existing source code, so while it must take an integer operand,
I'm not sure whether it would be octal or decimal or something
else. <b>Note:</b> <tt>SHR</tt> and <tt>SHL</tt>
are implemented as <tt>SHF</tt> operations, but <tt>SHF</tt>
can only shift by 1 or 2 positions for LVDC, or 1 through 6
positions for PTC. Therefore, if the operand for <tt>SHR</tt>
or <tt>SHL</tt> is greater than 2 (6), the assembler
transparently converts the operation to a minimum-length
sequence of shorter shift operations. For example, for
LVDC a <tt>SHL 5</tt> assembles to <tt>SHL 2</tt> / <tt>SHL 2</tt>
/ <tt>SHL 1</tt>. Consequently, depending on the operand,
any given <tt>SHR</tt> or <tt>SHL</tt> may assemble to
multiple executable words in memory rather than to a single
word. </li>
<li>The <tt>CDS</tt> instruction requires an operand of the form
<tt><i>DM</i>,<i>DS</i>,<i>DUPDN</i></tt> where the three octal
fields are interpreted, respectively, as specifying a
HOP-constant-like data module (0-7), data sector (0-17), and
duplex vs simplex mode (0-1). The <tt>DEQD</tt> pseudo-op
(see below) can be used to create symbolic macro names for such
specifications, and so the operand for <tt>CDS</tt> can be such
a symbolic macro name as well.</li>
<li>The <tt>EXM</tt> instruction has operands of the form "<tt><i>target</i>,<i>syllable</i>,<i>modifier</i></tt>",
where <tt><i>target</i></tt>, <tt><i>syllable</i></tt>, and <tt><i>modifier</i></tt>
are all small literal octal integer constants. These
fields may be interpreted as follows:</li>
<ul>
<li><tt><i>target</i></tt> (0-3): Specifies offset in
residual memory of target instruction: 0 for 600, 1 for
640, 2 for 700, 3 for 740. (I.e., 200, 240, 300, or 340 in the
residual memory sector.)<br>
</li>
<li><tt><i>syllable</i></tt> (0-1): Specifies syllable of
the target instruction within the target word.<br>
</li>
<li><tt><i>modifier</i></tt> (0-17 octal): Specifies a
4-bit modifier for the instruction: the two
least-significant bits <i>replace</i> the corresponding bits
in the target instruction, while the two most-significant bits
<i>bitwise-OR</i> with the corresponding bits.<br>
</li>
</ul>
<li>The <tt>PIO</tt> and <tt>CIO</tt> instructions accept only
literal octal constants (000-377 for <tt>PIO</tt>, 000-777 for
<tt>CIO</tt>). All of the examples I saw in the original
LVDC/PTC assembly listings were 0-padded, though yaASM.py does
not enforce that restriction.<br>
</li>
</ul>
<h3> <i><a name="Pseudo-ops"></a></i>Pseudo-ops</h3>
The following table shows every type of pseudo-op I've encountered
in the AS-206RAM and PTC ADAPT Self-Test program listings, and what
I've been able to infer about them:<br>
<br>
<table width="100%" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<th valign="middle" nowrap="nowrap" align="left">Pseudo-op<br>
</th>
<th valign="middle" align="left">Description<br>
</th>
</tr>
<tr>
<td valign="middle"><tt>BCI ^<i>text</i>$</tt><br>
</td>
<td valign="top"><a name="BCI"></a>This pseudo-op appears only
in PTC code.<br>
<br>
This pseudo-op encodes the <i><tt>text</tt></i> argument
into consecutive memory locations. It could be used
for preparing messages for printing on either the printer
peripheral (see the <a href="#PRS">PRS</a> instruction) or
the typewriter peripheral. <br>
<br>
The <i><tt>text</tt></i> operand is delimited by a leading
'^' and trailing '$', which are not themselves encoded into
memory. The assembler right-pads the <i><tt>text</tt></i>,
if necessary, until it is a multiple of 4 characters ending
in at least 2 spaces. <br>
<br>
<b>Note</b>: The leading carat character (<tt>^</tt>)
in <tt><i>text</i></tt> was not used in the original
Apollo-era source code. It has been added to the
assembly-language syntax for the convenience of the <i>modern</i>
assembler (yaASM.py). That's because the <tt><i>text</i></tt>
argument sometimes begins with a space character, and since
the modern assembler does not enforce strict columnar
alignment of the operand, it would otherwise have no way to
ascertain where <tt><i>text</i></tt> begins. The
original assembler, on the other hand, did enforce strict
columnar alignment, and therefore required no delimiter at
the beginning.<br>
<br>
Encoding of the <i><tt>text</tt></i> strings involves both
BA8421 encoding, used for <a
href="https://en.wikipedia.org/wiki/IBM_1400_series#Field_and_character_coding">IBM
1400 series printers</a>, and EBCDIC encoding, used for
later IBM printers like the ones that printed the original
LVDC and PTC assembly listings. The BA8421 encoding
scheme can be found at <a
href="https://en.wikipedia.org/wiki/BCD_%28character_encoding%29#IBM_1401_BCD_code">this
wikipedia link</a>, but it has the codes in a hexadecimal
form that are a bit confusing to relate to the octal codes
used in LVDC assembly language, so below I've reformulated
the table in terms of two-digit octal codes instead. <br>
<br>
<table cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<th valign="middle" align="center"><br>
</th>
<th valign="middle" align="center">_0<br>
</th>
<th valign="middle" align="center">_1<br>
</th>
<th valign="middle" align="center">_2<br>
</th>
<th valign="middle" align="center">_3<br>
</th>
<th valign="middle" align="center">_4<br>
</th>
<th valign="middle" align="center">_5<br>
</th>
<th valign="middle" align="center">_6<br>
</th>
<th valign="middle" align="center">_7<br>
</th>
</tr>
<tr>
<th valign="middle" align="center">0_<br>
</th>
<td valign="middle" align="center"> <br>
</td>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">2<br>
</td>
<td valign="middle" align="center">3<br>
</td>
<td valign="middle" align="center">4<br>
</td>
<td valign="middle" align="center">5<br>
</td>
<td valign="middle" align="center">6<br>
</td>
<td valign="middle" align="center">7<br>
</td>
</tr>
<tr>
<th valign="middle" align="center">1_</th>
<td valign="middle" align="center">8<br>
</td>
<td valign="middle" align="center">9<br>
</td>
<td valign="middle" align="center">0<br>
</td>
<td valign="middle" align="center">#<br>
</td>
<td valign="middle" align="center">@<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
</tr>
<tr>
<th valign="middle" align="center">2_</th>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" align="center">/<br>
</td>
<td valign="middle" align="center">S<br>
</td>
<td valign="middle" align="center">T<br>
</td>
<td valign="middle" align="center">U<br>
</td>
<td valign="middle" align="center">V<br>
</td>
<td valign="middle" align="center">W<br>
</td>
<td valign="middle" align="center">X<br>
</td>
</tr>
<tr>
<th valign="middle" align="center">3_</th>
<td valign="middle" align="center">Y<br>
</td>
<td valign="middle" align="center">Z<br>
</td>
<td valign="middle" align="center">‡<br>
</td>
<td valign="middle" align="center">,<br>
</td>
<td valign="middle" bgcolor="#ffff99" align="center">(<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
</tr>
<tr>
<th valign="middle" align="center">4_</th>
<td valign="middle" align="center">-<br>
</td>
<td valign="middle" align="center">J<br>
</td>
<td valign="middle" align="center">K<br>
</td>
<td valign="middle" align="center">L<br>
</td>
<td valign="middle" align="center">M<br>
</td>
<td valign="middle" align="center">N<br>
</td>
<td valign="middle" align="center">O<br>
</td>
<td valign="middle" align="center">P<br>
</td>
</tr>
<tr>
<th valign="middle" align="center">5_</th>
<td valign="middle" align="center">Q<br>
</td>
<td valign="middle" align="center">R<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" align="center">$<br>
</td>
<td valign="middle" align="center">*<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
</tr>
<tr>
<th valign="middle" align="center">6_</th>
<td valign="middle" bgcolor="#ffff99" align="center">+<br>
</td>
<td valign="middle" align="center">A<br>
</td>
<td valign="middle" align="center">B<br>
</td>
<td valign="middle" align="center">C<br>
</td>
<td valign="middle" align="center">D<br>
</td>
<td valign="middle" align="center">E<br>
</td>
<td valign="middle" align="center">F<br>
</td>
<td valign="middle" align="center">G<br>
</td>
</tr>
<tr>
<th valign="middle" align="center">7_</th>
<td valign="middle" align="center">H<br>
</td>
<td valign="middle" align="center">I<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" align="center">.<br>
</td>
<td valign="middle" bgcolor="#ffff99" align="center">)<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
<td valign="middle" bgcolor="#cccccc" align="center">?<br>
</td>
</tr>
</tbody>
</table>
<br>
<p>In case it isn't obvious from the table above, code 00 is
a blank space. The yellow-shaded characters have
encodings in the PAST program octal listing that don't
match the BA8421 encoding from wikipedia for some reason,
so the table above has been doctored to match the
assembler. The gray-background codes are
non-printable, and the emulation displays them as '
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<span style="color: rgb(51, 51, 51); font-family:
"Open Sans", "Helvetica Neue",
Helvetica, Arial, sans-serif; font-size: 14px;
font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400;
letter-spacing: normal; orphans: 2; text-align: left;
text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color:
rgb(255, 255, 255); text-decoration-style: initial;
text-decoration-color: initial; display: inline
!important; float: none;">▯</span>' when printed (for
example, using a <tt>PRS</tt> instruction). <br>
</p>
<p>Actually, while the assembler, the PTC printer, and the
PTC typewriter all use characters encoded in BA8421 to a
certain extent, and they all conform in terms of
alphanumerics and the blank space, they differ among
themselves to a certain extent as far as the special
(non-alphanumeric) characters are concerned. Rather
than reproduce all of those tables here, I'd simply refer
you to our PTC front-panel emulation program, yaPTC.py, in
which the table above is appears as the array called
BA8421, the table for the printer peripheral appears as
"BA8421a", and the table for the typwriter peripheral
appears as "BA8421b".<br>
</p>
<p>I have googled some of weirder characters, since it
wasn't obvious why they would be included in such a
limited repertoire of symbols, and unexpectedly got some
historical information about them that may actually be
applicable to their usage in the PTC: </p>
<ul>
<li>Code 77, the "group mark" character (a vertical line
with three horizontal hashes) was "formerly used as a
separator character for i/o operations". In the
case of the original printer, it seems to have been used
to flush the printer's internal memory buffer, by
physically printing the contents of the buffer and then
clearing the buffer. The buffer would normally
have been flushed anyway after filling up, so explicitly
sending the group mark would only have been necessary at
the end of a sequence of characters which may not have
completely filled the print buffer.<br>
</li>
<li>Code 74, the "square lozenge" character (a square with
concave sides) was "used as a command delimiter in some
very old computers".</li>
<li>Code 32, the "double dagger" character (a vertical
line with two horizontal hashes) is possibly used as an
error indicator.</li>
</ul>
I think that the set of allowed characters for <tt><i>text</i></tt>
is the intersection of the printable characters from the
BA8421 set listed above and the EBCDIC character set.
Unless I'm mistaken, that's just:<br>
<ul>
<li>Digits: 0 1 2 3 4 5 6 7 8 9<br>
</li>
<li>Upper case alphabetic: A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z</li>
<li>A blank space<br>
</li>
<li>Other: / . , - + * ( ).<br>
</li>
</ul>
The reason for this restriction is that the input
assembly-language source files and the printed assembly
listing are encoded in EBCDIC while the encoding of the
output assembled octals for the <tt>BCI</tt> pseudo-op uses
the BA8421 coding scheme. Therefore, only characters
available simultaneously in both characters are meaningful
from input through output of the assembler.<br>
<br>
As far as the octals assembled for <tt>BCI</tt> are
concerned, each of the memory locations allocated by the
pseudo-op encodes exactly 4 characters of the message.
The first character of the string occupies the two
most-significant octal digits of the first memory location,
the next character occupies the next lower two octal digits
of that memory location, and so on. Thus, encoding 4
characters requires 24 bits per 26-bit memory word.
The least-significant bits of each memory word are always
unused and are 0. <br>
<br>
For example, when the following is assembled,<br>
<blockquote> <tt>BCI ^TYPE OCTAL
CHARACTERS$</tt><br>
</blockquote>
the assembler notes that "<tt>TYPE...</tt>" has the BA8421
character octal character codes 23, 30, 47, 65, ..., and
thus the assembled octal encoding of the string is
233047650, .... That's pretty straightforward.<br>
<br>
In the <i>printed</i> assembly listing output, though,
things are much less straightforward. While the
original assembler did print out a representation of how the
<tt><i>text</i></tt> string assembled, presumably intended
to be helpful to the programmer, what it ended up printing
was a pretty goofy representation of the original
text. For example, consider the example <tt>BCI</tt>
usage mentioned above, which comes from page 3 of the PAST
program. The assembly listing displays the assembled
memory locations as<br>
<blockquote><tt>CHPV</tt><tt><br>
</tt><tt>0OTC</tt><tt><br>
</tt><tt>/L0T</tt><tt><br>
</tt><tt>Y/R/</tt><tt><br>
</tt><tt>TCVR</tt><tt><br>
</tt><tt>B000</tt><br>
</blockquote>
As nearly as I can guess, the assembler derived this
nonsensical representation roughly by the following
procedure:<br>
<ol>
<li>Get the BA8421 encoding of a character from the <tt><i>text</i></tt>
operand. For example, octal 23 for 'T'. </li>
<li>Add this to octal 260 (hex B0). For the 'T' this
would give 23+260=303.<br>
</li>
<li>Interpret this latter value as the <a
href="https://en.wikipedia.org/wiki/EBCDIC#Code_page_layout">EBCDIC</a>
code for a character and print it. For example, in
EBCDIC, octal 303 (hex C3) is 'C', and that's why 'C'
ends up being printed out in place of 'T'.<br>
</li>
<li>For <i>some</i> characters in <tt><i>text</i></tt>,
this procedure can produce an encoded value that doesn't
represent any character in EBCDIC, and which therefore
can't be printed as-is. In that case, the
procedure seems to be to hunt around by
adding/subtracting multiples of octal 100 (0x40) to the
EBCDIC code until a printable character is
obtained. Here's how that works out in detail in a
few examples:</li>
<ul>
<li>Space character: ' ' → 0<sub>8</sub> (BA8421)
→ 0xB0 (EBCDIC) → undefined. The only printable
EBCDIC character that can be reached from 0xB0 by
adding or subtracting multiples of 0x40 is 0xB0+0x40 =
0xF0 (EBCDIC) → '0'.</li>
<li>'A' → 61<sub>8</sub> (BA8421) → 0xE1 (EBCDIC) →
undefined. The only reachable printable EBCDIC
character is 0xE1-0x80=0x61 → '/'.</li>
<li>',' → 33<sub>8</sub> (BA8421) → 0xCB (EBCDIC) →
undefined. The only reachable printable EBCDIC
character is 0xCB-0x80=04B → '.'.</li>
</ul>
</ol>
<p>Yes, it seems silly to <i>me</i> too. Don't blame
me. Perhaps there's some amazing rationale for this
seemingly-loopy procedure that I simply don't
understand. If you know of one, let me know. I
suspect it's just a bug, but it seems ridiculous that a
bug as ridiculous as printing out "CHPV..." in place of
"TYPE..." went unnoticed back in the day! The modern
assembler (yaAGC.py) by default <i>does not</i> reproduce
this behavior, but does so if the --past-bugs command-line
switch is used.<br>
</p>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>BSS</tt><tt> <i>n</i><br>
</tt></td>
<td valign="middle">This pseudo-op simply allocates <tt><i>n</i></tt>
words of memory. They are loaded with the value 0.<br>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>DEC</tt><tt> <i>number</i><br>
</tt></td>
<td valign="middle">This pseudo-op allocates one word of
memory, and loads the decimal <tt><i>number</i></tt> in
it. <br>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>DEQD</tt><tt> </tt><tt><i>M</i></tt><tt>,</tt><tt><i>S</i></tt><tt>,</tt><tt><i>LOC<br>
</i></tt><i> or</i><tt><i><br>
</i></tt><tt>DEQS</tt><tt> </tt><tt><i>M</i></tt><tt>,</tt><tt><i>S</i></tt><tt>,</tt><tt><i>LOC</i></tt></td>
<td valign="middle">This preprocessor pseudo-op is a variant
of <tt>EQU</tt> (see below). It defines a
pseudo-variable, named according to its left-hand symbol,
referencing a specific fixed location in memory, specified
by its module, sector, and offset, which are literal octal
constants. Since the pseudo-variable exists only in
the preprocessor, it does not store anything at that
location, but merely defines a symbol representing that
particular memory configuration. The symbol for the
pseudo-variable created in this manner did not appear in the
symbol tables produced by the original LVDC assembler, but
do so in symbol tables produced by yaASM.py. As far as
I know, those pseudo-variables are used only as operands of
<tt>CDS</tt> instructions (see above).<br>
<br>
<tt>DEQD</tt> differs from <tt>DEQS</tt> in that the former
specifies a duplex memory configuration whereas the latter
specifies a simplex configuration.<br>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>DFW</tt><tt> <i>inst</i><i>ruction1</i>,<i>operand1</i>,<i>instruction2</i>,<i>operand2</i><br>
</tt></td>
<td valign="middle">Assembles a constant which can
subsequently be used as the operand of an <tt>EXM</tt>
instruction (see earlier). Note that <tt>EXM</tt>
cannot access such a constant in-place — i.e., not at the
location where the <tt>DFW</tt> pseudo-op stores it —
rather, requiring that the constant be moved at runtime to
one of the addresses 200, 240, 300, or 340 in residual
memory.<br>
<br>
Naively, what this pseudo-op does is to assembles two
instructions (remember, each instruction assembles into one
"syllable" and that two syllables comprise a single word of
memory), allocate a word of memory, and store the assembled
pair of instructions in it. However, because of the
way <tt>EXM</tt> uses such assembled instructions, there
are a few details which differ from this simple model.
Specifically, the residual bit (A9) and least-significant
bits (A2, A1) in <tt><i>operand1</i></tt> and <i><tt>operand2</tt></i>
are modified from what you expect to include certain bits
from the DS (data sector) applicable to <tt><i>operand1</i></tt>
and <i><tt>operand2</tt></i>. The documentation for <tt>EXM</tt>
should make it clear what those changes are. </td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>DOG <i>DM,DS,DLOC</i><br>
</tt><i> or</i><tt><br>
DOGD </tt><tt><i>DM</i></tt><tt>,</tt><tt><i>DS</i></tt><tt>,</tt><tt><i>DLOC</i></tt><tt><br>
</tt><i> or</i><br>
<tt>DOGD </tt><tt><i>DM</i></tt><tt>,</tt><tt><i>DS</i></tt><tt>,</tt></td>
<td valign="middle">Of the LVDC source code available to us,
the <tt>DOG</tt> form appears only in the PTC ADAPT
Self-Test Program, while the <tt>DOGD</tt> form appears
only in the AS206-RAM Flight Program. <br>
<br>
Abbreviated form of <tt>ORGDD</tt> (see below) that only
modifies the assembler's current data-memory pointer,
leaving the instruction-memory pointer untouched. It
does not allocate any memory. The location parameter <tt><i>DLOC</i></tt>
is treated as a suggestion rather than as a hard
specification of the offset into the data-memory sector,
since if the assembler finds that the requested <tt><i>DLOC</i></tt>
has already been used, it will search upward through the
data sector until it finds a location that hasn't already
been used. If any field is left empty, it defaults to
000.<br>
<br>
Presumably there is a <tt>DOGS</tt> pseudo-op as well
(differing in that it pertains to a simplex memory
configuration rather than a duplex one), but I have not
encountered it in actual code.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>EQU (<i>expression</i>)</tt><br>
</td>
<td valign="middle">Defines a "pseudo variable" used only by
the assembler's preprocessor pass. The parentheses are
literally present. The expression is arithmetical in
nature, and can involve decimal numbers, other pseudo
variables, and the operations +, -, *, or /. The lines
are evaluated in a single pass, so pseudo variables used in
expressions need to have been defined earlier in the source
code. For example,<br>
<blockquote><tt>PI
EQU (3.1415927)</tt><br>
</blockquote>
Note that when pseudo variables are <i>used</i> they are
always within arithmetical expressions that are enclosed in
parentheses, <tt>(<i>expression</i>)</tt>, such as:<br>
<blockquote><tt>PI
DEC (PI)B0<br>
PI3 DEC
(3*PI)B0<br>
</tt></blockquote>
These examples also illustrate the important point that the
namespace used for these pseudo variables is distinct from
the namespace used for left-hand symbols naming variables or
blocks of code. There are indeed symbols that have
this double usage. For example, in the AS-206RAM
program, "<tt>GEPLON EQU (15)</tt>" is at line 006600, while
"<tt>GEPLON DEC (GEPLON)B10</tt>" is at line 016820.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>FORM <i>a,b,</i>...</tt><br>
</td>
<td valign="middle">This preprocessor pseudo-op defines to the
assembler (without generating any actual code) the name of a
macro that, when used, will pack a pattern of bit-fields
into a single word-size constant. In the <tt>FORM</tt>
statement itself, the field-widths are decimal, whereas when
the macro is used, the values of the fields are octal.
An example may make all this clearer:<br>
<blockquote><tt>MYPAT
FORM 2,3,4,5,6</tt><tt><br>
</tt><tt>
.</tt><tt><br>
</tt><tt>
.</tt><tt><br>
</tt><tt>
.</tt><tt><br>
</tt><tt>MYCON MYPAT
1,2,3,4,5<br>
</tt></blockquote>
The first of these lines defines a macro, <tt>MYPAT</tt>,
which can pack 2-bit, 3-bit, 4-bit, 5-bit, and 6-bit fields
into a single 20-bit field. Since the LVDC word-size
is actually 26 bits, the unused 6 bits of the compiled
constant will all be 0. Confusingly, the way the
assembler <i>displays</i> word-size constants, the
least-significant bit is always 0 (because it's the physical
position in which parity is stored), so the constant is
actually aligned at bit 27 and appears as exactly 9 octal
digits. Because of this, in other words, it will
really appear that there are 7 unused bits assigned the
value 0.<br>
<br>
The second of the lines shown above uses the macro. It
compiles such a constant and stores it at a the memory
location <tt>MYCON</tt>. The 2-bit field will have
the (binary) value 01, the 3-bit field will have the value
010, and so on, so the actual value of <tt>MYCON</tt>, in
binary, as displayed by the assembler, will be<br>
<blockquote><tt>01 010 0011 00100 000101 000000
0</tt><br>
</blockquote>
or octal 243101200.<br>
<br>
The LVDC flight program AS-206RAM defines three such macros,
<tt>SS</tt>, <tt>SSFORM</tt>, and <tt>SSLAD</tt>, on page
45.<br>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>HPC</tt><tt> <i>SYMBOLNAME</i><br>
</tt>
<div align="left"><i> or</i><br>
</div>
<tt>HPC <i>SYMBOLNAME1</i>,<i>SYMBOLNAME</i><i>2</i><br>
</tt></td>
<td valign="middle">This allocates a word of memory at the
current location, and stores a HOP constant in it that's
constructed from the operand. <br>
<br>
In the one-operand variation, the HOP constant is simply the
same as that of the symbol whose name is given by the
operand.<br>
<br>
In the two-operand variation, IM, IS, S, and LOC fields of
the HOP constant are taken from <tt><i>SYMBOLNAME1</i></tt>,
while the DM and DS fields are taken from <tt><i>SYMBOLNAME</i><i>2</i></tt>.<br>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>HPCDD</tt><tt> <i>arg1,arg2</i><br>
</tt>
<div align="left"><i> or</i><br>
</div>
<tt>HPCDD <i>IM,IS,S,LOC,DM,DS</i><i></i><br>
</tt></td>
<td valign="middle">Like <tt>HPC</tt> (see above), constructs
a HOP constant and stores it at the current location.<br>
<br>
For all I know, there may be an <tt>HPCDS</tt> variation as
well, differing from <tt>HPCDD</tt> in applying to a
simplex memory configuration rather than a duplex one, but I
have not encountered it in practice.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>MAT</tt><br>
</td>
<td valign="top">Forces alignment for the next memory
allocated to a 020-word (octal, or 16 decimal) boundary, and
may have something to do with the succeeding words logically
forming a matrix. It does not allocate any
memory. I.e., any memory it skips past to reach the
proper alignment remains unallocated. </td>
</tr>
<tr>
<td valign="middle"><tt>OCT <i>number</i></tt><br>
</td>
<td valign="middle">Allocates a word of memory and stores the
given octal <tt><i>number</i></tt> there.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>ORGDD <i>IM</i>,<i>IS</i>,<i>S</i>,<i>LOC</i>,<i>DM</i>,<i>DS,DLOC</i></tt><br>
</td>
<td valign="middle">LVDC only ... not PTC.<br>
<br>
Sets the instruction-memory and the data-memory assumptions
for the next code or data lines to be assembled. The
fields within the operand relate to those within the HOP
constants, except that while the HOP constant has a single
LOC field, the assembler internally maintains separate LOC
fields for instruction memory (<i><tt>LOC</tt></i>) and data
memory (<tt><i>DLOC</i></tt>).<br>
<br>
The trailing <tt><i>DLOC</i></tt> is sometimes not
specified, so that we are left simply with "<tt>ORGDD <i>IM</i>,<i>IS</i>,<i>S</i>,<i>LOC</i>,<i>DM</i>,<i>DS,</i></tt>".
In that case, the first previously-unused location in the
select data module/sector is used. Actually, even
specifying <tt><i>DLOC</i></tt> explicitly does not
necessarily imply that the data location is set to <i><tt>DLOC</tt></i>,
since if that location has already been used, the next
unused location after that will be selected instead, and the
assembler generates a warning message. <br>
<br>
In general, the assembler will reject a <tt><i>LOC</i></tt>
field to an address that has already been allocated:
the assembler will always advance the counters until
reaching the first unused location.<br>
<br>
There may be an <tt>ORGDS</tt> variant as well, specifying
a simplex memory configuration rather than a duplex
configuration, but I have not encountered it in practice.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt><tt>ORG <i>IM</i>,<i>IS</i>,<i>S</i>,<i>LOC</i>,<i>DM</i>,<i>DS,DLOC<br>
</i></tt></tt></td>
<td valign="top">PTC only ... not LVDC.<br>
<br>
This is functionally almost identical to the LVDC <tt>ORGDD</tt>
pseudo-op, though differing slightly syntactically.<br>
<br>
Sets the instruction-memory and the data-memory assumptions
for the next code or data lines to be assembled. The
fields within the operand relate to those within the HOP
constants, except that while the HOP constant has a single
LOC field, the assembler internally maintains separate LOC
fields for instruction memory (<i><tt>LOC</tt></i>) and data
memory (<tt><i>DLOC</i></tt>).<br>
<br>
Any of the fields may be left empty. As far as I can
tell, any field left empty defaults to 0, except for <tt><tt><i>DLOC</i></tt></tt>.
In the case of <tt><tt><i>DLOC</i></tt></tt>, it appears to
me that it defaults to the <i>next</i> location after the
previous one allocated in the sector. For example,
consider the following example code:<br>
<blockquote><tt>ORG 1,2,0,3,0,16,20</tt><tt><br>
</tt><tt>OCT 1234</tt><tt><br>
</tt><tt>OCT 2345</tt><tt><br>
</tt><tt>OCT 3456</tt><tt><br>
ORG ... to some other memory sector
...<br>
...<br>
</tt><tt>ORG 1,2,0,3,0,16,</tt><tt><br>
</tt><tt>OCT 4567</tt><tt> </tt><br>
</blockquote>
The first 3 <tt>OCT</tt>s would be at addresses 0-16-20,
0-16-21, and 0-16-22. The final <tt>OCT</tt> would be
address 0-16-23. It should not be inferred that the
addresses 0-16-0 through 0-16-17 are completely filled up
(as they would be for a similar LVDC pseudo-op <tt>ORGDD</tt>),
because <tt>ORG</tt> merely increments the preceding
address (rather than searching for the first unallocated
address as in the LVDC's <tt>ORGDD</tt>). In fact, it
appears to me that <tt>ORG</tt> with <tt>DLOC</tt> left
empty never goes to <tt>DLOC</tt>=0, and instead starts
with <tt>DLOC</tt>=1. <br>
<br>
Moreover, it appears to me that the original assembler had a
bug, which we intentionally reproduce in the modern
assembler (yaASM.py). The bug is that even if no data
words had been allocated between one ORG and the next, the
assembler still assumed that a <i>minimum</i> of 1 word had
been allocated anyway. Suppose, for example, we were
to append the following code to the sample above:<br>
<blockquote><tt>ORG 1,2,0,3,0,16,</tt><br>
<tt> </tt><tt><tt>ORG 1,2,0,3,0,16,</tt><br>
<tt> </tt></tt><tt><tt>ORG
1,2,0,3,0,16,</tt><br>
<tt> </tt>OCT 5670</tt><tt> </tt><br>
</blockquote>
The <tt>OCT</tt> would be at address 0-16-26, because each
of the final 2 <tt>ORG</tt>s would incorrectly have assumed
that at least one word had been allocated prior to it. <br>
<br>
Here's a selection of actual uses found in PTC software:<br>
<blockquote><tt>ORG ,,,,,13,0</tt><tt><br>
</tt><tt>ORG ,1,,2,,1,</tt><tt><br>
</tt><tt>ORG ,2,1,0,,2,1<br>
ORG 1,2,,2,1,2,3<br>
</tt></blockquote>
</td>
</tr>
<tr>
<td valign="middle"><tt>SYN <i>symbol</i></tt><br>
</td>
<td valign="middle">This pseudo-op requires a left-hand symbol
to precede the <tt>SYN</tt> on the line. It tells the
assembler to treat the left-hand symbol as a synonym for <tt><i>symbol</i></tt>.
This is similar in concept to <tt>EQU</tt>, which
essentially creates synonyms for numerical constants.
But it differs from <tt>EQU</tt> in that it is not a part
of the preprocessor, and thus can reference symbols defined
later in the source code. Further, the symbols it
references can be program labels or variable names <br>
</td>
</tr>
<tr>
<td valign="middle"><tt>TABLE <i>number</i></tt><br>
</td>
<td valign="middle">This informs the assembler that the
succeeding <tt><i>number</i></tt> words of memory form a
table. The operand is a decimal number. The only
use I can see for this is to make sure the assembler doesn't
split the table across a memory-sector boundary. All
of the uses of <tt>TABLE</tt> I find in the AS-206RAM
listing are tagged as assembler warnings.<br>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>USE</tt><tt> INST<i><br>
</i></tt><i> or</i><tt><i><br>
</i>USE DAT<i><br>
</i> </tt></td>
<td valign="middle">These pseudo-ops alter the way the
assembler places and orders succeeding items in
memory. The usual positioning and ordering is
represented by <tt>USE INST</tt>, whereas I'm unsure of
what <tt>USE DAT</tt> is for. I think it may be a
convenient way to pack CPU instructions when one wants to
place them in the midst of an area of memory used primarily
for storing variables, or may represent an alternative to
the <tt>DFW</tt> pseudo-op (see above).<br>
<br>
<tt>USE INST</tt>:<br>
<blockquote>The <tt>ORGDD</tt> pseudo-op (see above)
defines an origin for both "instructions" (fields <tt><i>IM</i>,<i>IS</i>,<i>S</i>,<i>LOC</i></tt>)
and "data" (fields <tt><i>DM</i>,<i>DS,LOC2</i></tt>).
Normally, instructions are assembled at successive offset
locations while the "syllable" (0 or 1) is kept
fixed. I.e., normally, all of the locations with
syllable 0 are used up, then all of the locations with
syllable 1. The assembler uses the <tt><i>IM</i>,<i>IS</i>,<i>S</i>,<i>LOC</i></tt>
fields from <tt>ORGDD</tt> to determine the memory area
in which this happens. When the end of the memory
sector is reached, a different syllable or sector or
module must be selected either by the assembler or the
coder. <br>
<br>
Data is similarly assembled at successive locations (with
pseudo-ops like <tt>DEC</tt>, <tt>OCT</tt>, or <tt>BSS</tt>),
but in the memory area selected by the <tt><i>DM</i>,<i>DS,LOC2</i></tt>
fields from <tt>ORGDD</tt> instead. Moreover, data
is typically a full word of memory rather than a single
syllable, so both syllables of each memory word are
typically used for each data item.<br>
</blockquote>
<tt>USE DAT</tt>:<br>
<blockquote>On other other hand, when <tt>USE DAT</tt> is
in effect, I think only instructions are assembled, and
data-allocated pseudo-ops like <tt>DEC</tt>, <tt>OCT</tt>,
or <tt>BSS</tt> aren't used. There are two changes
from <tt>USE INST</tt> in the way instructions are
assembled. <br>
<br>
Firstly, instructions are assembled in the memory area
selected by the <tt><i>DM</i>,<i>DS,LOC2</i></tt> fields
from <tt>ORGDD</tt>. I.e., they appear in "data"
memory rather than in "instruction" memory. But
beyond that, successive instructions are not assembled
into the same syllable of memory, but are instead
assembled at alternating syllables: 1, 0, 1, 0, 1, 0,
..... (Notice that syllable 1 comes first in
the sequence.)<br>
<br>
I'm not sure how the CPU responds to this ordering.
The <tt>USE DAT</tt> context is often (though not always)
associated with simplex memory configuration as selected
by a <tt>CDSS</tt> instruction so perhaps this is really
the order in which the CPU executes instructions in a
simplex configuration.<br>
</blockquote>
</td>
</tr>
<tr>
<td valign="middle" nowrap="nowrap"><tt>VEC</tt><tt><br>
</tt></td>
<td valign="middle">Forces alignment on a 4-word boundary, and
may have something to do with the succeeding words logically
forming a vector. It does not allocate any
memory. I.e., any memory it skips past to reach the
proper alignment remains unallocated.<br>
</td>
</tr>
</tbody>
</table>
<h3><a name="ANATOMY"></a>Program Structure </h3>
<p>Here are some of my own observations and inferences, based on
inspection of the AS-206RAM assembly listing.<br>
</p>
<p>Overall structure of the program: <br>
</p>
<ul>
<li>Code:</li>
<ul>
<li>Table of contents<br>
</li>
<li>Explanatory comments about telemetry data.</li>
<li>Pseudo variables definitions<br>
</li>
<li>Code-entry points which are obliged to be at specific memory
locations. (interrupt, initialization, timing "minor
loop", abort)</li>
<li>Orbital program linkages.</li>
<li>Macro definitions.</li>
<li>Utility programs required to be at specific memory
locations. I notice that some of this code is
self-modifying. Perhaps that may be part of the
motivation for putting it at a specific location.
Perhaps not.</li>
<li>Data storage area. I.e., variables and constants ...
but there is also a smidgeon of code stored here (go figure!),
for managing the switch-selector table. Of particular
bulk are:</li>
<ul>
<li>Switch selector table</li>
<li>C-band and telemetry station table.</li>
</ul>
<li>Section 1: Initialization</li>
<li>Section 2: Accelerometer processing.</li>
<li>Section 3: Boost navigation.</li>
<li>Section 4: Guidance select and pre-IGM guidance.</li>
<li>Section 5: IGM guidance.</li>
<li>Section 6: Backup routines</li>
<li>Section 7: Interrupt routines</li>
<li>Section 8: Orbital initialization</li>
<li>Section 9: Orbital processor</li>
<li>Section 10: Orbital navigation</li>
<li>Section 11: C-band and telemetry navigation routine</li>
<li>Section 12: Acceleration routines</li>
<li>Section 13: Orbital guidance</li>
<li>Section 14: Interrupt processing</li>
<li>Section 15: Simultaneous memory error (Tough Luck Charlie)</li>
<li>Section 16: Minor loop support</li>
<li>Section 17: Minor loop</li>
<li>Section 18: Disagreement bit processing</li>
<li>Minor loop error telemetry routine</li>
<li>Section 19: Switch selector check</li>
<li>Section 20: Switch selector processing</li>
<li>Section 21: Flight simulation</li>
<li>Section 22: Utility Routines<br>
</li>
</ul>
<li>Tables generated by the assembler:</li>
<ul>
<li>Segment cross reference table</li>
<li>Octal memory listing<br>
</li>
</ul>
</ul>
<p>Assembly warnings: Warnings are marked with a <tt>W</tt>
in the leftmost column of the offending line. No explanation
appears in the assembly listing of why any particular warning is
issued. In the AS-206RAM assembly listing, the sequence
numbers at which errors and warnings are found is as follows:<br>
</p>
<blockquote><tt>012420 015020 015050 015070 015090 015110 015140
015260 015290 015310 <br>
026500 026800 026820 026840 026880 026920 026990 027020 027820
027890 <br>
027910 027980 028040 028090 029370 030230 031780 031930 032230
036880 <br>
036910 036920 036930 036950 036990 037020 037200 037490 038040
038680 <br>
038820<br>
</tt></blockquote>
<p>Sector shifts in the program flow: Recall that each 26-bit
word of memory (not including the parity bit) consists of two
13-bit syllables, referred to as syllable 0 and syllable 1.
Each CPU instruction assembles to a single 13-bit value, and thus
fits precisely within a single syllable, and any word in memory
can simultaneously hold two separate instructions. When the
CPU executes code in a given memory sector, it just sequences
through all of the instructions in the currently-selected
syllable. When the last-available word in the current
syllable is reached, execution cannot continue. Rather than
forcing the programmer to deal with this situation explicitly, the
assembler steps in and transparently substitutes an extra
instruction into the program flow to select a different syllable,
sector, or module. So from the programmer's standpoint, he
can just write an uninterrupted block of code without even
worrying about the fact that it spans several different memory
sectors. The code transparently modified by the assembler
uses slightly more memory and execution time that it superficially
appears to from the source code, but that <i>usually</i> doesn't
matter. <br>
</p>
<p>From the assembler's point of view, though, it's a bit more
complicated. The simplest case is in reaching the end of
syllable 0 for a given memory sector. The first (unused)
location of syllable 1 of that same memory sector is accessible by
a <tt>TRA</tt> instruction, so the assembler transparently
inserts a <tt>TRA</tt> just before reaching the end of syllable
0.<br>
</p>
<p>What happens when reaching the end of syllable 1 of a memory
sector is much trickier. For one thing, various factors
influence the usage of words at the ends of sectors in syllable 1,
so it's a chore for the assembler just to figure out when the end
of sector 1 has even been reached. The next problem is that
once the end of syllable 1 has been reached, it can't simply
switch to a new syllable: it instead has to switch to a
different <i>sector</i> within the memory module, or perhaps even
to a different memory module altogether. That can't be done
with a simple <tt>TRA</tt> instruction, and requires a
more-complex <tt>HOP</tt> instruction instead. Unlike a <tt>TRA</tt>
instruction which encodes its target address within the
instruction itself, a <tt>HOP</tt> instruction requires a
variable containing the "HOP constant" of the target
address. Naturally, no such variable containing the desired
HOP constant normally exists. So in order to insert a <tt>HOP</tt>
instruction, the assembler must first create such a
variable: it must find an unused location in the current
data sector or residual sector, and stick a HOP constant into it.</p>
Those points at which a sector change is performed due to reaching
the end of the sector, regardless of whether or not the assembler
inserts any <tt>HOP</tt> or <tt>TRA</tt> instructions, is marked
with a <tt>*</tt> in column 1 of the assembly listing. These
transparently-inserted jumps are found at the following
card-sequence numbers in the AS-206RAM listing:<br>
<blockquote>
<p><tt>044700 047910 050170 052790 054910 057850 062640 065020
067470 070680 <br>
073610 076720 079190 083030 085700 089420 093330 096170 098760
101450<br>
104090 109850 112570 116390 120760 123850 <br>
</tt></p>
</blockquote>
<p>Assembly errors: Errors are marked in the leftmost column
of the offending line by a character that presumably indicates the
type of error. In the AS-206RAM assembly listing, the 7 such
errors are found, and here are my interpretations of what they
mean:<br>
</p>
<ul>
<li><tt>U</tt> at sequence number 027140. The operand, <tt>CBNAV</tt>,
is not a defined symbol. It appears as though it was
probably correct in earlier software versions, but perhaps
should have been changed to <tt>CBNAV1</tt> in this version.<br>
</li>
<li><tt>U</tt> at sequence number 029650. One of the macro
parameters, <tt>CBRANW</tt>, is not a defined symbol.
There is a handwritten note implying that it probably should
have been <tt>TEMP6</tt>.</li>
<li><tt>O</tt> (no sequence number, p. 67). This is a
full-line comment, but the necessary "<tt>*</tt>" character in
column 1 has apparently been accidentally omitted.
Therefore, the first word in the line (which happens to be "+")
has been interpreted as an instruction, and naturally the
assembler knows of no such instruction. <br>
</li>
<li><tt>V</tt> at sequence number 047930. The assembler
mistakenly believes the target location, <tt>*-2</tt>, is
out of range, because it has been fooled by an automatic switch
from memory syllable 0 to syllable 1 slightly before. In
fact, the target location actually <i>is</i> accessible by a <tt>TRA</tt>
instruction (or a <tt>HOP</tt> instruction), but presumably the
original assembler was not smart enough to figure that out.<br>
</li>
<li><tt>U</tt> (no sequence number, p. 187). The target location,
<tt>TB5GO</tt>, is an undefined symbol.<br>
</li>
<li><tt>A</tt> (no sequence number, p. 188). The target variable,
<tt>TBB</tt>, is defined, but is not located in either the
current data sector or in the residual sector, and is therefore
not accessible.<br>
</li>
<li><tt>O</tt> (no sequence number, p. 190). The target location
of a jump, <tt>ORBGID</tt>, is not located in the current data
sector. The instruction is <tt>TRA</tt>, and ordinarily
that means that the assembler would automatically have used a <tt>HOP</tt>
instruction in place of the <tt>TRA</tt>. For reasons that are
unclear to me, the original assembler did not do so in this
case, and instead simply discarded the instruction.<br>
</li>
</ul>
<p>Notice that about half of the errors above occur on the (rare!)
lines having no card-sequence number. I think that for
pragmatic reasons, sequence numbers would usually have been left
off of the punch-cards while the code was under development.
Otherwise, they would have needed to be changed frequently, which
would be a great inconvenience. In other words, the sequence
numbers were likely only added once the code had reached a
releasable form. Thus most of the errors appeared in areas
of the code that were under active development, which is not
terribly surprising.<br>
</p>
<p>Alas! There are 7 <i>more</i> errors exactly like the <tt>A</tt>
type error listed above which the original assembler did not even
detect. These are the pairs of lines of code at
card-sequence numbers 026840, 026860, 026880, 026900, 026920,
026940, and 026960. They're all of the form<br>
</p>
<blockquote><tt><i>LABEL</i> CLA <i>CONSTANT</i><br>
CLA
<i>CONSTANT</i>+1<br>
</tt></blockquote>
<p> </p>
<p>Fortunately, it's easy to see how these latter 7 errors should be
fixed. As it happens, there are quite a few examples on the
same page of the assembly listing that make it clear the pattern
should have instead been <br>
</p>
<blockquote><tt><i>LABEL</i> CDS <i>CONSTANT</i><br>
CLA
<i>CONSTANT</i>+1<br>
</tt></blockquote>
Format of the source-code portion of the assembly listing:
Consider a "normal" section of the listing, containing code,
comments, etc., as opposed to report tables generated by the
assembler, to which I've added some markup (in green) for
explanatory purposes:<br>
<div align="center"><img alt="" src="anatomyCode.jpg" width="1005"
height="310"> </div>
<ul>
<li>Columns IM, IS, S, LOC, DM, and DS: These columns are
generated by the assembler and represent <a
href="#Layout_of_Memory_Words">the fields of the HOP constant</a>
associated with the line of code, from the viewpoint of the
assembler. (The only HOP fields missing are DUPIN and
DUPDN, which I suppose would be global settings affecting all
memory, as opposed to varying on a line by line basis.) In
particular, the IM and IS fields give the memory module and
sector in which the line of code appears, and LOC gives the
offset into the memory sector of the word in which the code for
the instruction is stored.</li>
<li>Columns A8-A1, A9, and OP: These columns are also
generated by the assembler, and represent <a
href="#Layout_of_Memory_Words">fields of the assembled
instruction</a> associated with the line of code. In
particular, OP is the octal value of the particular CPU
instruction, <a href="#CPU_Instructions">as tabulated earlier</a>.<br>
</li>
<li>Column CONSTANT: Yet another field generated by the
assembler. Most lines don't have it, but it appears
whenever the operand of the instruction is the address of a
numerical constant stored at some other place in memory, but for
which the assembler knows the value. For example, both of
the lines in the sample above are the same, 342452244, because
both of them relate to a <tt>HOP SCPOLY</tt> instruction.
As I've already explained above, what the assembler does with a
line of code like this is to find the <tt>SCPOLY</tt> routine
(which conveniently for us, actually appears in sample above as
well), figures out its HOP constant, allocates a word of memory,
stores the HOP constant at that location, and then embeds the
address of that location into the instruction. You can
actually see all that happening in the sample. The HOP
constant itself corresponds to the values IM=4, IS=04, S=1,
LOC=124, DM=2, DS=14 at the line of code <tt>SCPOLY STO 777</tt>.
I know it's probably tough to do those conversions in your head,
so a handy python script (<a
href="https://github.com/virtualagc/virtualagc/blob/master/yaASM.py/unHOP.py">unHOP.py</a>)
is available that can do it for you; and in fact, if you feed
342452244 into unHOP.py, the expected values of IM, IS, S, etc.,
pop out. (You also get the extra info that DUPIN=1 and
DUPDN=1 ... more on which below.) Moreover, if you look at
the lines where the constant appears, namely the lines reading
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<tt>HOP SCPOLY</tt>, and you look at the assembled code, you'll
see that the address at which the HOP constant is stored must be
DM=2, DS=14, LOC=342.</li>
<li>Column EXPANSION: The final field generated by the
assembler. It contains the character '+' for instructions
which have been expanded from the <tt>CALL</tt> macro, but is
blank otherwise. Whether there are other things that can
appear there, I can't say.</li>
<li>Columns LEFT-HAND SYMBOL, INSTRUCTION, OPERAND, COMMENT,
SEQUENCE: I've covered these above, and suspect that they
may come directly from the punch cards, unchanged.</li>
</ul>
The Segment Cross Reference table: This appears near the end
of the assembly listing, and is generated by the assembler.
Here's a small sample:<br>
<br>
<div align="center"><img alt="" src="anatomyXref.jpg" width="1328"
height="74"><br>
</div>
<p>What the cross reference does is list each symbol in the program,
tell you where it appears in memory, and then tells you how to
find all <i>uses</i> of that symbol in the code. It should
be pretty obvious to you that in this example, the symbol <tt>UTEMP1</tt>
is in memory module 2, sector 17, at address 174. It may or
may not be obvious that where the symbol is <i>used</i> is at the
line SEQUENCE numbers 085370, 116640, etc. Alas, the few
pages of the assembly listing which I've elected to freely expose
do not include the one which <tt>UTEMP1</tt> is allocated, but
does include several examples of where it is used. For
example, if you look at the sample code I've marked up in green
just a bit above, you can see it used at SEQUENCE number 117600,
just as expected. Not all lines of code have SEQUENCE
numbers, and in those cases the SEQUENCE number appearing in the
table are generated by simply adding 10 to last card having an
explicit SEQUENCE number.<br>
</p>
<p>Although I haven't shown any examples in the image above, memory
locations which the assembler itself automatically allocates also
appear in the segment cross reference table. Recall that
there are cases where the assembler transparently allocates memory
locations to store values of constants (like the values of
numerical expressions or HOP constants) which are referenced
on-the-fly without being explicitly defined in the source
code. These variables are distinguished by having no
symbolic name. Instead they are referenced by their unique
values rather than by symbolic name. I.e., their unique
values are used as if they were their symbolic names. Hence
what appears in the table in place of a name is the 9-octal-digit
value stored at the location. They appear in the table after
all of the symbolic names.<br>
</p>
<p>The octal listing of the program: This is generated by the
assembler and appears at the very end of the listing. It
simply shows what appears at each memory location in the modules,
as either a single 26-bit octal word or as two 13-bit
syllables. So you can see in the octal table what each
instruction and each pseudo-op assembles to in octal form.
In each of the numbered columns of the table, syllable 1 of the
memory word is on the left and syllable 0 is on the right.
For example, referring to the image below, in module 2, sector 00,
location 0201 (or 2-00-0201 for short), syllable 1 has the value
10170 and syllable 0 has the value 00174. <br>
</p>
<p>It's important to understand the alignment of the data shown in
the octal listing:<br>
</p>
<ul>
<li>26-bit data words (none of which are shown below) are shifted
1 bit to the left, and thus displayed as 9 octal digits.
The least-significant bit is always 0.</li>
<li>13-bit instructions, syllable 1, are shifted 2 bits to the
left, and thus displayed as 5 octal digits. The
least-significant 2 bits are always 0.</li>
<li>13-bit instructions, syllable 0, are shifted 1 bit to the
left, and thus displayed as 5 octal digits. The
most-significant and least-significant bit are always 0.</li>
</ul>
<p>This seems weird — the instruction alignment in particular! — but
I suppose the rationale is that the open bit positions correspond
to the positions of parity bits. The assembler itself does
not bother to compute the parity bits for you, and thus represents
them all as 0. If you take an instruction from syllable 1
and one from syllable 0 as shown in the table, overlap the
least-significant <i>octal digit</i> from the left-hand
instruction with the most-significant octal digit from the
right-hand instruction, then bitwise OR them (or add them), you
get the full contents of the memory word. For example,
taking the first two instructions shown below (63224 12436), the
full 26-bit content of address 2-00-000, left-aligned, is:<br>
</p>
<blockquote><tt> 63224<br>
+ <u> 12436</u><br>
632252436<br>
</tt></blockquote>
<p>However, there's no doubt that the visual representation of this
data is undoubtedly weird. And, it's unclear just how useful
it is ... certainly not at all, if you're trying to disassemble
the instructions by eye! I've provided a handy python script
(<a
href="https://github.com/virtualagc/virtualagc/blob/master/yaASM.py/unOP.py">unOP.py</a>)
that you can use to provide a simple-minded disassembly of the
instructions found in the octal listing. The script assumes
that if an octal number you give it has a leading space character
then it is in syllable 0, and that if it has no leading space it
is in syllable l. For example, feeding "63224" into it gives
back "MPH 315", while feeding " 12436" into it gives back "CLA
124".<br>
</p>
<div align="center"><img alt="" src="anatomyOctal.jpg" width="1114"
height="134"><br>
</div>
<br>
<p> </p>
<h2><a name="MIT_Instrumentation_Laboratory_vs_IBM"></a>MIT
Instrumentation Laboratory vs IBM Federal Systems Division</h2>
The MIT Instrumentation Laboratory (which designed the Apollo
Guidance Computer) had nothing to do with the LVDC, and conversely
IBM Federal Systems Division (which designed the LVDC) had nothing
to do with the AGC. However, since IBM was an important
manufacturer of computers (indeed, it designed the Gemini on-board
computer system), whereas MIT/IL was emphatically <i>not</i>, there
was an understandable feeling by some that the Apollo program might
better be served by an IBM on-board guidance computer in the Command
Module and Lunar Module than by newly-designed computer from novice
MIT/IL.<br>
<br>
Accordingly, IBM proposed that the LVDC be used in place of the AGC
in the CM and LM, and in 1963, it produced a big, two volume report
(<a href="Documents/IBMStudyReport-63-928-129-Volume1.pdf">here</a>
and <a href="Documents/IBMStudyReport-63-928-130-Volume2.pdf"> here</a>)
to support their proposal. The Instrumentation Labs fired back
their own critiques, shredding IBM's report to the extent
possible. And in <a
href="Documents/CritiqueOfIBMApolloStudyReport.pdf"> one of those
critiques</a>, we have a few precious gems of LVDC assembly
language, as written by the Instrumentation Labs personnel rather
than by IBM. Perhaps I'm making too much of this sample code, but
for years and years it was the only purported LVDC code we had any
access to, and as the only LVDC code then thought still to exist,
perhaps over the span of a decade or so it used up more of my mind
share than it ought.<br>
<br>
Whether it's good LVDC code or bad LVDC code, who knows? I can
tell you that it would certainly bomb out when run through our
modern assembler, and presumably would do so when run through IBM's
original one ... so it's very unlikely that the good folks at MIT/IL
had any access either to the original IBM assembler, or even to any
samples of IBM-written source code. They were either using
their imaginations, or perhaps wrote their own assembler for it,
using their own home-grown syntax. Who knows? Perhaps
some day I'll go through it and fix up the syntax enough to run it
through the assembler and emulator.<br>
<br>
Whether or not it's good code, here's what it looked like. The
'#' characters indicate the beginnings of comments, and as usual,
were added by me rather then originally being present in the sample
code.<br>
<br>
<table summary="" style="text-align: left; margin-left: auto;
margin-right: auto;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; background-color: rgb(204,
255, 255);"> <small><span style="font-family: Courier
New,Courier,monospace;"># Sum of two double-precision
vectors A and B to produce vector C.</span><br
style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">
CLA
A<br>
ADD B<br>
STO C<br>
CLA A + 1<br>
ADD B + 1<br>
STO C + 1<br>
CLA A + 2<br>
ADD B + 2<br>
STO C + 2<br>
...<br>
<br>
# Purportedly, subroutine linkages to call functions to
perform vector addition.<br>
CLA ADRESA<br>
STO VCAADR<br>
CLA * + 2<br>
HOP VCALINK<br>
HOPCON * + 1<br>
CLA ADRESB<br>
STO VADADR<br>
CLA * + 2<br>
HOP VADLINK<br>
HOPCON * + 1<br>
CLA CADRES<br>
STO VTSADR<br>
CLA * + 2<br>
HOP VTSLINK<br>
HOPCON * + 1<br>
...<br>
<br>
# Integration during accelerated flight. If you want to
see the equations being<br>
# implemented, look at page 7 of <a
href="Documents/CritiqueOfIBMApolloStudyReport.pdf">
the critique</a>.<br>
AVERAGEG STO EXITHOP<br>
HOP HOPSET1<br>
AVG1 CLA
WK<br>
SHF R1<br>
ADD HGK/2<br>
ADD VK<br>
MPH H<br>
ADD R<br>
STO R<br>
MPY R<br>
HOP THISEC1<br>
AVG4 CLA
HOPWD1<br>
ADD ONE<br>
STO HOPWD1<br>
CLA PQ<br>
ADD DOTSUM<br>
STO DOTSUM<br>
HOPWD1 HOP HOPSET1<br>
AVG2 CLA
DOTSUM<br>
STO SQRTARG<br>
CLA * + 2<br>
HOP SQRTLINK<br>
HOPCON * + 1<br>
CLA SQRTANS<br>
MPY DOTSUM<br>
CLA -MUH/2<br>
NOOP<br>
NOOP<br>
DIV PQ<br>
HOP THISSEC2<br>
AVG5 CLA
HOPSET1<br>
STO HOPWD1<br>
CLA HOPSET2<br>
STO HOPWD2<br>
NOOP<br>
NOOP<br>
NOOP<br>
CLA PQ<br>
STO DOTSUM<br>
HOP HOPSET2<br>
AVG3 CLA
R<br>
MPY DOTSUM<br>
CLA HGK/2<br>
ADD W<br>
ADD V<br>
STO V<br>
CLA PQ<br>
STO HGK/2<br>
ADD V<br>
STO V<br>
HOP THISSEC3<br>
AVG6 CLA
HOPWD2<br>
ADD ONE<br>
STO HOPWD2<br>
HOP HOPSET2<br>
HOPSET1 HOPCON AVG1, XCOMP<br>
HOPCON AVG1, YCOMP<br>
HOPCON AVG1, ZCOMP<br>
HOPCON AVG2, XCOMP<br>
HOPSET2 HOPCON AVG3, YCOMP<br>
HOPCON AVG3, ZCOMP<br>
EXITHOP ( exit hop con )<br>
STRTLINK HOPCON SQRT, XCOMP<br>
THISSEC1 HOPCON AVG4, AVG4<br>
THISSEC2 HOPCON AVG5, AVG5<br>
THISSEC3 HOPCON AVG6, AVG6<br>
<br>
# Compute a double-precision square root.<br>
SQRT STO
RETURN<br>
CLA ZERO<br>
STO NORMCNT<br>
CLA ARG<br>
NORMTEST AND HIGH3<br>
TNZ NORMDUN<br>
CLA NORMCNT<br>
ADD ONE<br>
STO NORMCNT<br>
CLA ARG<br>
SHF L2<br>
STO ARG<br>
TRA NORMTEST<br>
HIGH3 DEC -.75<br>
1/2
DEC .5<br>
SLOPELO DEC .4162<br>
BIASLO DEC .1487<br>
SLOPEHI DEC .2942<br>
BIASHI DEC .2046<br>
NORMDUN AND 1/2<br>
TNZ ARGHI<br>
CLA ARG<br>
MPY SLOPELO<br>
SHF R1<br>
STO ARG<br>
CLA BIASLO<br>
ADD PQ<br>
TRA NEWTON<br>
ARGHI CLA ARG<br>
MPY SLOPEHI<br>
SHF R1<br>
STO ARG<br>
CLA BIASHI<br>
ADD PQ<br>
NEWTON STO BUF<br>
CLA ARG<br>
DIV BUF<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
CLA PQ<br>
SHF R1<br>
ADD BUF<br>
STO BUF<br>
CLA ARG<br>
DIV BUF<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
ADD ZERO<br>
CLA BUF<br>
SHF R1<br>
ADD PQ<br>
STO ARG<br>
CLANORC CLA NORMCNT<br>
TNZ POSTSQRT<br>
CLA ARG<br>
SHF R1<br>
STO ARG<br>
TRA CLANORC<br>
<br>
# Calling sequence for SQRT (or similar for any other
unary subroutine).<br>
CLA X<br>
STO ARG<br>
CLA REHOP<br>
HOP SQRTLINK<br>
RETURN CLA ARG<br>
...<br>
REHOP HOPCON RETURN<br>
SQRTLINK HOPCON SQRT<br>
</span></small></td>
</tr>
</tbody>
</table>
<br>
<h2><a name="yaLVDC_the_LVDC_CPU_Emulation"
id="yaLVDC_the_LVDC_CPU_Emulation"></a><small><big>yaLVDC, the
LVDC/PTC CPU Emulation</big></small></h2>
<div style="text-align: center;">
<div style="text-align: left;"><i>The LVDC/PTC CPU emulator is a
work in progress, so the information in this section may not
yet be totally reliable.</i><br>
<br>
An important proviso regarding CPU emulation is that the
original physical LVDCs installed in the Saturn rockets were not
by themselves fast enough to keep up with the real-time
calculations needed to directly control the rocket. The
LVDC could only update the control signals it was outputting
about 25 times a second ... and while that may <i>seem</i>
fast, it's not fast enough when you're controlling a powerful
beast like the Saturn V rocket. The control signals output
by the LVDC if used directly, as is, would have been too
stair-steppy, too choppy. 25 outputs per second isn't
enough! So the LVDC's output signals didn't directly
control the rocket. What happened instead is that a
separate unit — the LVD<i>A</i> — was needed to accept the
digital outputs from the LVDC and turn them into
smoothly-changing controls for the rocket. And when I say
smoothly-changing, I mean both smoothly in <i>time</i> as well
as in terms of electrical properties. Thus any emulation of the
LVDC that could acceptably control the rocket would additionally
require emulation of the LVDA. But the yaLVDC program does
<i>not</i> do that; it emulates the LVDC and nothing more!
If you want to emulate the LVDA or anything else connected to
the LVDC, additional emulation software is needed beyond just
yaLVDC.<br>
<br>
Another interesting aspect of the LVDC is that since it was
essentially a "black box" that outputted real-time control
signals in response to real-time inputs, it is possible to
create a reasonably satisfactory behavioral simulation for it in
the absence of the original software, since we know the <a
href="Documents/SaturnVLaunchVehicleGuidanceEquations.pdf">
guidance equations</a> relating the outputs to the
inputs. The yaLVDC software does <i>not</i> do that; it
emulates the LVDC or PTC CPU, whether you have loaded into it
any LVDC software that implements the guidance equations or
not. Perhaps all you load into the emulation is something
as trivial as LVDC software that just counts from 1 to
1000. No matter, yaLVDC doesn't care what the LVDC/PTC
software <i>does</i>, it will run it just the same! With
that said, while creating behavior simulations is not an
objective of the Virtual AGC project as far as the Apollo CPUs
are concerned, there are people engaged in creating such
simulations for the <span style="font-weight: bold;">Orbiter</span>
NASSP project and elsewhere.<br>
<div align="center"><img style="width: 770px; height: 236px;"
alt="" src="Saturn-GuidanceEquations.jpg" width="770"
height="236"><br>
</div>
</div>
</div>
<br>
The yaLVDC program currently has to be build from its <a
href="https://github.com/virtualagc/virtualagc/tree/master/yaLVDC">source
code</a>. Building it requires the GNU C compiler ("gcc")
and the GNU "make" program. Simply download the source code,
"cd" into the folder containing it (which is the "yaLVDC" folder in
the Virtual AGC software repository), and run the command
"make". You should then add yaLVDC to your PATH, so that it
can be easily found later by the operating system.<br>
<br>
In order to run an LVDC or PTC emulation, you first have have some
LVDC or PTC software to load into it, and that LVDC/PTC software
must have been assembled by <a
href="#yaLVDCASM_the_LVDC_Cross-Assembler">the yaASM.py assembler
which is covered in the next section</a>. In any given
assembly, the assembler produces 3 output files which are required
as input to yaLVDC. These are called yaASM.tsv (the octal
listing of the initial memory contents), yaASM.sym (the symbol
table), and yaASM.src (the source code, as related to specific
memory locations and source-code line numbers). These files
can be moved to any folder you like, and renamed anything you like,
as long as they retain the extensions .tsv, .sym, and .src.<br>
<br>
You invoke the LVDC/PTC emulator with the command<br>
<blockquote><tt>yaLVDC [<i>OPTIONS</i>] --assembly=<i>path/to/the/LVDC/or/PTC/executable</i></tt><br>
</blockquote>
For example, you might already be in the folder containing PTC
executables (which perhaps you've renamed PAST.tsv, PAST.sym, and
PAST.src), and yaLVDC might be in your PATH, and the command might
be<br>
<blockquote><tt>yaLVDC --ptc --cold-start --assembly=PAST</tt><br>
</blockquote>
Here's a list of the <tt><i>OPTIONS</i></tt> available right now,
though using the command "yaLVDC --help" might give a more
up-to-date list.<br>
<br>
<table width="80%" cellspacing="2" cellpadding="2" align="center">
<tbody>
<tr>
<th valign="top">OPTION<br>
</th>
<th valign="top">Description<br>
</th>
</tr>
<tr>
<td valign="middle"><tt>--help</tt><tt><br>
</tt></td>
<td valign="middle">Displays a list of all available <tt><i>OPTIONS</i></tt>
for yaLVDC, and possibly other useful information.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>--assembly=<i>PATH</i><br>
</tt></td>
<td valign="middle">Specifies a full path to the executable
LVDC/PTC files, <i>minus</i> the filename extensions (.tsv,
.sym, .src). For example, if you hadn't renamed the
executable files output by the assembler, and if those were
in the current folder, it would just be <tt>--assembly=yaASM</tt>.
Or if you had renamed them (say) MyProgram.tsv,
MyProgram.sym, and MyProgram.src, and were in the folder
.../test/, then it would be <tt>--assembly=../test/MyProgram</tt>.
(Note that on Linux or MacOs, the forward-slash character
'/' is used to separate components of a path on the
filesystem. On Windows, I think that either '/' or the
usual Windows backslash separator '\' would be accepted.)<br>
<br>
Eventually, multiple <tt>--assembly</tt> switches would be
allowed on a single yaLVDC command line, allowing
simultaneous loading of separately assembled program
components at nonoverlapping locations in memory. This
is necessary because (as described above) the LVDC Flight
Program did not completely fill memory, and required the
presence of other programs (such as the Preflight Program)
to function properly. The PTC ADAPT Self Test Program,
on the other hand is complete and relies on no other
software. At present, though, the ability to have
multiple programs simultaneously loaded is not yet
implemented.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>--cold-start<br>
</tt></td>
<td valign="middle">Eventually, as the emulation runs, it will
automatically periodically save files (yaLVDC.core) which
act as snapshots of the internal state of the
emulation. Similarly upon startup, it will by default
automatically load the most-recent snapshot. This
action overrides the memory contents provided by the <tt>--assembly</tt>
switch(es) (while leaving intact their symbol tables and
source-code tables), essentially allowing execution to
proceed from the point where it had previously left
off. (This automatic saving of snapshot files, by the
way, is not yet implemented.)<br>
<br>
The <tt>--cold-start</tt> switch overrides the automatic
load of the snapshot which occurs at power-up, thus insuring
that the memory contents specified by the <tt>--assembly</tt>
switch(es) are in place.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>--core=<i>FILENAME</i><br>
</tt></td>
<td valign="middle">This switch overrides the filename for the
memory snapshot loaded at power-up, which would by default
otherwise be yaLVDC.core. It does not affect the
naming used for snapshots output by the emulation, which
remain yaLVDC.core.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>--run<br>
</tt></td>
<td valign="middle">By default, at startup, the emulation
pauses just prior to executing the first LVDC/PTC
instruction, and instead drops to a debugging interface
under user control. When <tt>--run</tt> is used, the
LVDC/PTC program instead runs freely without requiring any
user interaction, although it can be interrupted by hitting
any key on the keyboard.<br>
</td>
</tr>
<tr>
<td valign="top"><tt>--panel-pause</tt><br>
</td>
<td valign="top">(PTC only; see <tt>--ptc</tt> below.)
Starts the emulation in a state where it is not
free-running, but is instead waiting for commands from the <a
href="#Running_the_PTC_ADAPT_Self-Test_Program">emulated
PTC front panel</a>, which hasn't been discussed yet but
is covered later. <br>
<br>
This <i>superficially</i> appears to be the opposite of
--run, but in fact it is not. In fact, <tt>--panel-pause</tt>
would generally be used with <tt>--run</tt>, or not at
all. The explanation is that while LVDC emulations
have a single debugger, namely the gdb-based one built
natively into yaLVDC, PTC emulations instead have two
debuggers that are essentially separate an
independent. The first of these is still yaLVDC's
native debugger, but the second one is based instead on the
PTC front panel. While the two debuggers can be used
at the same time, to a certain extent, they are not designed
to do so. Normally, therefore, when using PTC
front-panel based debugging, one would let the emulation
free-run from the yaLVDC debugger's point of view, so the
command-line switches <tt>--run --panel-paused</tt> would
be used together. Conversely, when using yaLVDC based
debugging, one would let the CPU run freely from the PTC
panel's point of view, and thus neither of those
command-line switches would be used.<br>
</td>
</tr>
<tr>
<td valign="middle"><tt>--ptc<br>
</tt></td>
<td valign="middle">By default, an LVDC CPU is emulated.
When the <tt>--ptc</tt> switch is used, a PTC CPU is
emulated instead.<br>
</td>
</tr>
<tr>
<td valign="top"><tt>--divisor=<i>N</i></tt><br>
</td>
<td valign="top">Slows the LVDC/PTC's CPU clock down by a
factor of <tt><i>N</i></tt> (an integer). The default is
1. I'm not certain there's as much need for this
switch as I thought there was when I invented it. The
motivation is that <a
href="#Running_the_PTC_ADAPT_Self-Test_Program">the
existing software emulation of the PTC front panel
(yaPTC.py)</a> has been designed with short-term
convenience (mine!) in mind, rather than speed of
execution. It is therefore possible under some
circumstances for it to fall behind the much quicker yaLVDC
software when the two are interacting. Using a switch
such as <tt>--divisor=3</tt> can mitigate this problem.<br>
</td>
</tr>
<tr>
<td valign="top"><tt>--port=<i>N</i></tt><br>
</td>
<td valign="top">Select the port number used for connecting
emulated peripheral devices to the emulated CPU. This
is a networking-based system of "virtual wires".
Because the interface is network based, yaLVDC and emulated
peripherals could run on separate computers, as long as
there is an networking connection between them. The
default port-number, 19653, memorializes the notion that our
version of the PAST program is from March 1965.</td>
</tr>
</tbody>
</table>
<br>
As mentioned above, by default the emulation runs in a debugging
interface intended to allow you do things like single-step the
LVDC/PTC software, set breakpoints, examine or change memory or
registers, etc. The interface is loosely based on the GNU "<a
href="https://www.gnu.org/software/gdb/">gdb</a>" debugger, but is
a limited form of it. Once yaLVDC is running, but the
emulation is halted at a debugger command line, you can get a
complete list of the available debugger commands with the the
command<br>
<blockquote><tt>HELP<br>
</tt></blockquote>
Some useful commands you'll read about there are <tt>STEP</tt>
(single-step some number of instructions), <tt>NEXT</tt> (single
step instructions, but executing subroutines as indivisible blocks
without seeming to descend into them), <tt>BREAK</tt> (set
breakpoint), <tt>X</tt> (examine memory), <tt>SET</tt> (change
memory contents), <tt>BACKTRACE</tt> (list the jumps that got us to
the present point in the program), and so on. yaLVDC does not
presently have the ability to be embedded within GUI debuggers such
as Code::Blocks, but hopefully someday it might.<br>
<br>
When the PAST program is being emulated (as opposed to an LVDC
flight program), the <tt>x</tt> command (examine memory) is
particularly useful when applied to the 50-word table at label <tt>ERR</tt>,
the command for which is:<br>
<blockquote><tt>X/50 &ERR</tt><br>
</blockquote>
This table is a record of the last 10 self-test failures which have
occurred. Each of the failures contributes 5 successive words
in the table, obviously, and the 5 words are interpreted as follows:<br>
<ol>
<li>The current value of the program pass counter.</li>
<li>A HOP constant referencing an individual test or block of
tests. This is the beginning of the block of code
containing the test, and not the specific point in the code
where the error occurred. In the debugger, you can change
the program counter (and data sector) directly to the referenced
block of code with the command <tt>GOTO <i>HopConstant</i></tt>,
though in doing so, you won't be restoring any other aspect of
the the machine state to what it was at the time the error
occurred.</li>
<li>The contents of the accumulator at the time the error was
detected.</li>
<li>A HOP constant referencing an individual test. Used when word
#2 above refers to a block of several tests. <br>
</li>
<li>A data word defining an individual test. Used when a
subroutine is performing several tests with a block of test data
and test patterns.<br>
</li>
</ol>
<blockquote> </blockquote>
<i>A general example:</i> Let's the PTC ADAPT Self-Test Program
without any emulated peripheral devices, thus being dependent on the
built-in yaLVDC debugger. Assuming you had copied the
assembler's output files (yaASM.tsv, yaASM.src, and yaASM.sym; see
the next section) into the folder containing yaLVDC, you'd start the
program something like this:<br>
<blockquote>
<div align="left"><tt>./yaLVDC --ptc --cold-start --assembly=yaASM</tt><br>
</div>
</blockquote>
yaLVDC starts up and then pauses prior to emulating the very first
instruction in the PAST program, giving you a "debugger" interface
that may be something like this:<br>
<blockquote> <tt>HOP = 000000000
(ADR=0-00-0-000/0-00) VAL = 01037 ACC =
000000000</tt><tt><br>
</tt><tt>(777)= ????????? (empty
address ) (776)= ?????????
(empty address )</tt><tt><br>
</tt><tt> RET = 000000000 (ADR=0-00-0-000/0-00)</tt><tt><br>
</tt><tt>Instructions: 0, Cycles: 0, Elapsed time: 0.000000
seconds</tt><tt><br>
</tt><tt>Source line: 369</tt><tt><br>
</tt><tt>L1P1 CLA ZERO</tt><tt><br>
</tt><tt><br>
</tt><tt>> </tt><br>
</blockquote>
<p>What this is trying to do is to compactly display a lot of info
about the state of the CPU and of the emulation itself:<br>
</p>
<ul>
<li>The emulation has paused at code address 0-00-0-000 (i.e.,
instruction module 0, instruction sector 00, syllable 0,
location 000), with a "HOP constant" of 000000000. </li>
<li>The data context (for fetching or saving variables in memory)
is 0-00 (i.e., data module 0, data sector 00).</li>
<li>The value stored at the code address (i.e., the numerical
representation of the next instruction to be emulated) is 01037<sub>8</sub>.</li>
<li>The value stored in the accumulator is 0.</li>
<li>The memory locations often designated as 777 and 776, used to
store return addresses of subroutines, are currently empty;
i.e., nothing has yet been stored in them.</li>
<li>"RET" refers to the so-called "HOP save" register, which
currently is 0-00-0-000 (code) and 0-00 (data). The HOP
save register contains the code address and data context of the
instruction in memory that immediately follows the last
instruction that was executed. In other words, usually
this will just be the same as the current code address and data
context. But if the previously-executed instruction sas a
<tt>HOP</tt>, <tt>TRA</tt>, <tt>TNZ</tt>, or <tt>TMI</tt>,
and thus the current instruction was out of order with the last
one executed, then the HOP save register will differ from the
current HOP constant. So in that case, the HOP save
register is basically the return address from the immediately
preceding <tt>HOP</tt>, <tt>TRA</tt>, <tt>TNZ</tt>, or <tt>TMI</tt>.
The program then must immediately use a <tt>STO 777</tt> or <tt>STO
776</tt> to save the return address, or else the information
is permanently lost.</li>
<li>So far (suprise!), 0 instructions have been executed, 0
instruction cycles have elapsed, and that has taken 0 seconds of
real time.</li>
<li>The current address corresponds to source-code line
#369. However, the line numbers shown do not relate to
line numbers in the PAST program source file
(PTC-ADAPT-Self-Test-Program.lvdc), but rather to the line
numbers in the yaASM.src file. That's because the LVDC/PTC
assembler is a macro assembler, in which a single line of source
code may sometimes be transparently converted to several
LVDC/PTC instructions. For example, in the PTC, the
"instruction" <tt>SHL 25</tt> is really the sequence of
instructions <tt>SHL 6 / SHL 6 / SHL 6 / SHL 6 / SHL 1</tt>.
<br>
</li>
<li>The source-code line associated with the current memory
location is "<tt>L1P1 CLA ZERO</tt>". As it happens, all
LVDC/PTC software is potentially self-modifying, and all of the
original LVDC/PTC source code at our disposal is actually
self-modifying. If the instruction value found at the
current code address is different than the one the debugger
expected to find, the debugger will show you both the original
source line and for comparison a source line that it generates
by disassembling the current instruction.</li>
</ul>
<p>Of course, the final "<tt>></tt>" is a user-prompt, indicating
that the debugger is waiting for user input, and as I said above,
wherever possible those commands are based on gdb. <br>
</p>
<p>So, for instance, if we used the command <tt>LIST</tt>, we'd see
the following:<br>
</p>
<blockquote><tt>Assembly ../PTC-ADAPT-Self-Test-Program/yaASM:</tt><tt><br>
</tt><tt> 369: 0-00-0-000 0-13
01037 L1P1
CLA ZERO</tt><tt><br>
</tt><tt> 370: 0-00-0-001 0-13
03673
STO INTIND</tt><tt><br>
</tt><tt> 371: 0-00-0-002 0-13
04033
STO STOP</tt><tt><br>
</tt><tt> 372: 0-00-0-003 0-13
04073
STO CTR</tt><tt><br>
</tt><tt> 373: 0-00-0-004 0-13
02633
STO LC8</tt><tt><br>
</tt><tt> 374: 0-00-0-005 0-13
11556
CDS 1,13</tt><tt><br>
</tt><tt> 375: 0-00-0-006 1-13
00013
STO TIME</tt><tt><br>
</tt><tt> 376: 0-00-0-007 1-13
00053
STO CSCTR</tt><tt><br>
</tt><tt> 377: 0-00-0-010 1-13
00113
STO DDCTR</tt><tt><br>
</tt><tt> 378: 0-00-0-011 1-13
10556
CDS 0,13</tt><tt><br>
</tt><tt> 379: 0-00-0-012 0-13
10605
CIO 214</tt><tt><br>
</tt><tt> 380: 0-00-0-013 0-13
00654
TMI L1P1A</tt><tt><br>
</tt><tt> 381: 0-00-0-014 0-13
00710
TRA L2P1</tt><tt><br>
</tt><tt> 382: 0-00-0-015 0-13
05500 L1P1A TRA
L1P1A1</tt><tt><br>
</tt><tt> 383: 0-00-0-016 0-13
03537 L2P1
CLA VAR3</tt><tt><br>
</tt><tt> 384: 0-00-0-017 0-13
05547
ADD =O000000002</tt><tt><br>
</tt><tt> 385: 0-00-0-020 0-13
03533
STO VAR3</tt><tt><br>
</tt><tt> 386: 0-00-0-021 0-13
10205
CIO 204</tt><tt><br>
</tt><tt> 387: 0-00-0-022 0-13
01037
CLA ZERO</tt><tt><br>
</tt><tt> 388: 0-00-0-023 0-13
03573
STO VAR4</tt><tt><br>
</tt></blockquote>
What we see above is simply the original source code juxtaposed with
the associated contents memory and the line numbers. Or if we
used the command <tt>DISASSEMBLE</tt>, we'd see something like
this:<br>
<blockquote><tt>Disassembling:</tt><tt><br>
</tt><tt>
0-00-0-000 0-00 01037 L1P1
CLA ZERO, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-001 0-00
03673
STO INTIND, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-002 0-00
04033
STO STOP, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-003 0-00
04073
STO CTR, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-004 0-00
02633
STO LC8, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-005 0-00
11556
CDS 1,13</tt><tt><br>
</tt><tt>
0-00-0-006 1-13
00013
STO TIME, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-007 1-13
00053
STO CSCTR, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-010 1-13
00113
STO DDCTR, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-011 1-13
10556
CDS 0,13</tt><tt><br>
</tt><tt>
0-00-0-012 0-13
10605
CIO 214</tt><tt><br>
</tt><tt>
0-00-0-013 0-13
00654
TMI L1P1A</tt><tt><br>
</tt><tt>
0-00-0-014 0-13
00710
TRA L2P1</tt><tt><br>
</tt><tt>
0-00-0-015 0-13 05500 L1P1A
HOP L1P1A1 (destination), 160030160
(operand)</tt><tt><br>
</tt><tt>
0-00-0-016 0-13 03537 L2P1
CLA V3, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-017 0-13
05547
ADD =O000000002, stored value =
000000001</tt><tt><br>
</tt><tt>
0-00-0-020 0-13
03533
STO V3, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-021 0-13
10205
CIO 204</tt><tt><br>
</tt><tt>
0-00-0-022 0-13
01037
CLA ZERO, stored value = 000000000</tt><tt><br>
</tt><tt>
0-00-0-023 0-13
03573
STO V4, stored value = 000000000</tt><tt><br>
</tt></blockquote>
In this case, the original source code has been ignored, but the
disassembler has recreated a sort of facsimile of it by analyzing
the contents of memory. That's important, because LVDC/PTC
code is self-modifying ... i.e., it sometimes replaces the
instructions originally in memory with different ones. The
regeneration of the source code by <tt>DISASSEMBLE</tt> is quite
good, and the disassembly looks much like the original. In
some ways it's even more useful than the original, though lacking
comments, since it not only tells you the names of variables, but
goes out of its way to tell you what values are stored in those
variables. You do notice a few differences, such as <tt>VAR3</tt>
in the one vs <tt>V3</tt> in the other. That's because <tt>VAR3</tt>
and <tt>V3</tt> are <i>synonyms</i> in the original source code
(via the <tt>SYN</tt> pseudo-op), so the disassembler has no way to
know which of the two synonyms was originally used ... but it
doesn't matter. You may also see things that you at first <i>think</i>
are bugs: for example, at address <tt>0-00-0-017</tt>, you find an
"<tt>ADD =O000000002</tt>" instruction, for which you're helpfully
informed that the value stored in memory for <tt>=O000000002</tt>
is really <tt>000000001</tt>. A discrepancy? No!
In constructs like <tt>=O000000002</tt> in LVDC/PTC assembly
language, the 26-bit data is aligned at the most-significant (27th)
bit when stored in memory, leaving the least-significant bit open
for storing parity. In other words, from a "modern" point of
view, they're left-shifted on place from where they ought to
be. So <tt>=O000000002</tt> is really, logically, the integer
1. A nice, constant source of confusion! <img
src="smiley.png" alt="" width="16" height="16"> Don't blame me,
blame mid-1960's IBM.<br>
<p> </p>
<h2><a name="yaLVDCASM_the_LVDC_Cross-Assembler"
id="yaLVDCASM_the_LVDC_Cross-Assembler"></a>yaASM.py, the
LVDC/PTC Cross-Assembler</h2>
The original IBM 360 based LVDC assembler used during Project Apollo
itself is no longer available 50+ years later ... or at least, not
available to <i>us</i>. So I've written an LVDC assembler
completely from scratch. It's capable of accepting the
original LVDC AS206-RAM Flight Program or the PTC ADAPT Self-Test
Program, and producing an assembly listing similar to the original
one, as well as an executable image (i.e., a list of the contents of
all memory locations) that's 100% identical to the memory contents
listed in the original printouts. <br>
<br>
In saying this, I suppose it's important to reiterate that while we
have decent contemporaneous documentation of the LVDC/PTC
instruction set, we have no contemporaneous documentation whatsoever
of the format of LVDC assembly language, and specifically of the
pseudo-ops or operand syntax of the language. In other words,
while the new assembler works with the LVDC/PTC language
documentation as described on this web page, portions of this web
page's documentation are based on what I've personally inferred from
reading the specific LVDC/PTR program printouts available to
me. A listing of a different version of the original LVDC or
PTC software, were one to become available, could easily have
features which I've never seen before and which therefore are not
yet accounted for in the new assembler.<br>
<br>
With that warning out of the way, <a
href="https://github.com/virtualagc/virtualagc/tree/master/yaASM.py">the
modern LVDC assembler is called yaASM.py and is available in the
Virtual AGC software repository</a>. Both the files yaASM.py
and expression.py found there are necessary for running the
assembler. As the naming implies, the assembler is written in
the Python language — specifically Python 3, and it will not work
with Python 2. Python programs such as this assembler are
ready to run, as-is, and require no preparation or setup other than
installation of Python itself.<br>
<br>
(Note: The yaASM.py program should not be confused with the
yaASM program, which also appears in the repository. yaASM is
an assembler program for Gemini OBC assembly language. The
naming of these two programs is similar due to the fact that the
LVDC and OBC are such similar computers. The original
intention was that yaASM would be able to handle both OBC and LVDC
assembly languages. However, yaASM was written in advance of
any <i>true</i> samples of LVDC source code becoming
available. When true LVDC samples became available much later,
the inadequacy of yaASM with respect to the language features that
it would need to handle became apparent, and the idea of using yaASM
for the LVDC was abandoned.)<br>
<br>
Usage of the LVDC assembler is quite simple:<br>
<blockquote><tt>yaASM.py [<i>OPTIONS</i>] [<i>OCTALS</i>.tsv] <<i>INPUT</i>.lvdc
><i>OUTPUT</i>.lst</tt><br>
</blockquote>
By default the assembler targets the LVDC and expect LVDC-specific
source code as input. To target the PTC instead, the
command-line switch --ptc is required. Specifically, I'd
recommend the following commands for the AS206-RAM Flight Program
and the PTC ADAPT Self-Test Program:<br>
<blockquote><tt>yaASM.py LVDC-AS206RAM.tsv <LVDC-AS206RAM.lvdc
></tt><tt><i>assembly.listing</i></tt><tt><br>
</tt><tt>yaASM.py --ptc [--past-bugs]
PTC-ADAPT-Self-Test-Program.tsv
<PTC-ADAPT-Self-Test-Program.lvdc ></tt><tt><i>assembly.listing</i></tt><br>
</blockquote>
Notice that the <tt>--past-bugs</tt> switch is shown as
optional. If present, it mimics a bug in the original PTC
assembler which botched messages in the output assembly listing
associated with the <tt>BCI</tt> pseudo-op. If the <tt>--past-bugs</tt>
switch is omitted, more-helpful non-botched messages appear
instead. The octal executable is not affected by the use or
disuse of <tt>--past-bugs</tt>.<br>
<br>
The assembler simply takes an input file of LVDC or PTC source code
(<i>INPUT</i>.lvdc), and produces as output a human-readable
assembly listing (<i>OUTPUT</i>.lst). Additionally, it
produces the following files:<br>
<ul>
<li>yaASM.tsv — an octal listing of the assembled code</li>
<li>yaASM.sym — a symbol table</li>
<li>yaASM.src — an address-by-address listing of source code</li>
</ul>
<p>Each of these files is ASCII, with tabs delimiting fields.
(Or in the case of the .src file, UTF-8 rather than ASCII if any
non-ASCII characters appear in the input LVDC/PTC source-code
comments.) They are intended to be easily machine readable,
for use as the inputs to our (eventual) LVDC/PTC emulator
software. The files are produced whether or not there are
fatal errors in the assembly process, so don't take their
existence as an indication that assembly succeeded. The
format of the files will be discussed in a moment.<br>
</p>
There is also an optional <i>input</i> file (<i>OCTALS</i>.tsv) for
the assembly process. <i>OCTALS</i>.tsv, if available, is a
tab-delimited octal listing of an LVDC rope in the same format as
the original LVDC/PTC assembly listing. Note, by the way, that
the original LVDC and PTC assemblers used somewhat different formats
for octal fields, thus the input files for LVDC octals and PTC
octals differ somewhat. If present, OCTALS.tsv is not used for
generating the assembled output; rather, the assembler performs a
comparison during the assembly process of the contents of the input
file <i>OCTALS</i>.tsv against that of the eventual output file
yaASM.tsv, and provides messages indicating mismatches between the
two. This can be helpful in validating the transcription of
the input source code or the action of the assembler.<br>
<br>
In contrast, the <i>output</i> octal listing file (yaASM.tsv)
always conforms to the (superior) LVDC format, even if the input
files were in PTC format. <br>
<br>
Rather than describe any of these tab-delimited file formats in
detail here, I'd suggest that they're reasonably straightforward,
and you can simply look at the files themselves to get a better idea
of how they work.<br>
<br>
Finally, as a convenience, the PTC ADAPT Self-Test Program has been
pre-assembled, and you can find its files in the yaLVDC folder of
the software repository. There, they are named PAST.tsv,
PAST.sym, and PAST.src, with PAST.listing thrown in for good
measure.<br>
<h2><a name="Running_the_PTC_ADAPT_Self-Test_Program"></a>Running
the PTC ADAPT Self-Test Program in the LVDC/PTC Emulator</h2>
<p>Running the PAST program and its many test procedures in the
emulator remains an elaborate process, even after all of the
elaborate discussion above. To maintain a <i>little</i>
clarity without unnecessarily further cluttering this page, I've
split discussion of the PAST program test procedures into a
separate page:<br>
</p>
<div align="center">⟶<a href="PTCTestProcedures.html">Go to
discussion of running the PAST program's test procedures</a><br>
</div>
<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
LVDC 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
LVDC 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 explaning the syntax of LVDC assembly-language.</li>
<li>Source code for the software run by the test &
checkout computers, as opposed to the LVDC itself.</li>
<li>Any documents missing from the <a href="links.html#LVDC">Document
Library</a>.</li>
<li>Developers' notes.</li>
</ul>
<h2><a name="Homage" id="Homage"></a>Homage<br>
</h2>
Well, we haven't made much progress on the homage
front. I have a handful of names, though too few yet
to really form any picture as to who did what. Hopefully
be able to flesh this out somewhat as time progresses and to
provide that info here. A lot of the information on this
page that doesn't come directly from the surviving documentation
is largely due to conversations with Barry Silverman, who has
made a significant effort to find and talk to original LVDC
developers.<br>
</div>
</div>
<br>
<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-08.<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>
</body>
</html>
