Note: Throughout this page you'll see a number of videos illustrating the Initial Program Load (IPL) process, but you may notice that the appearance of the simulation varies somewhat from one to the next. That's because the simulation software was advancing too. As long as the video illustrated the basic points I wanted to make, I saw no reason to remake the videos.Elsewhere on this website we've discussed various topics related to the Space Shuttle's flight software, such as:
Our focus here will be OI-34.07, though as a longer-range
goal, we'd like to eventually extend our coverage to the other
versions as well.
What make it all as nightmarish as I claim? Here's the
synopsis:
So in order to get a working setup in which PASS can be run on a
modern computer, we need not only emulators for the GPC, the MMU,
and other peripheral devices in the spacecraft, but also need to
know how to compile PASS source code (i.e., which ordering and
which options), how to combine the object files into PHASES, and
how to get those PHASES onto tape in a format that the GPC can
correctly understand. And hope that any patches we're missing
aren't too important.
Before building any PASS source code, you need an appropriate setup for doing so. First, you'll need to have installed the development tools, i.e., the HAL/S compiler, the assembler, and so on. The first step is to locally clone the Virtual AGC software repository, if you have not done so already. This will give you a local directory called "virtualagc". Since I don't know where you will put this directory on your own computer system, I'll refer to it as virtualagc, and when you see this in the discussion below you'll just have to remember to use the path that's correct for your own computer system.
TBD
An important decision for you: Perhaps you just don't care about how to compile the flight software, or about building a "tape" from it, but just want to run it. If that's you, then you can simply skip all this dreadful, nerdy stuff and jump right down to the other dreadful, nerdy stuff.
Next, you'll need PASS source code. As has been discussed
in depressing detail elsewhere (TBD), this software is being
treated as restricted out of fear of legal repression — or in the
dreadful euphemism people are using at the time I'm writing this,
"in an abundance of caution" —, so if you qualify to get this
material, download it. It's a compressed git
repository. Unpack it, and you'll have a directory called
"PFS". Since I don't know where on your computer this
directory will be, I'll refer to it as PFS,
and when you see this in the discussion below you'll just have to
remember to use the path that's correct for your own computer
system.
Building PASS source code produces a lot of files that
are created by the compiler et al., so as a practical
measure you need to do your work in a scratch directory used only
for that purpose, which you won't feel bad about disposing of
later. (It's your computer, of course, so you can do what
you want.) I'll refer to this directory as scratch, and when you see
this in the discussion below you'll just have to remember to use
the path that's correct for your own computer system.
Depending on which PASS version you're going to build, you need
to make sure that the source code you need is accessible from scratch. Here's how we set
it up:
Finally, copy the following directories into your scratch/OI301700 or scratch/OI340600 or scratch/OI340700 directory:
This is a long process, but at the end you should see that the objects/ directory has been filled with object files.cd scratch/OI340700 # Or someday, OI340600 or OI301700
prepareTEMPLIB --clear
prepareINCLIB --clear --include=INCL80
mkdir SDFLIB # Or just clear the directory if it already exists.
mkdir objects # Or just clear the directory if it already exists. compilePASS
For OI-34.07 only, we have disassembly reports generated
from dumps of GPC memory back in the Shuttle era by a program
called MAFGEN. It is therefore possible to verify the
build process up to this point by comparing the linked memory
images created in the
preceding step with memory images extracted from those
disassembly reports. This verification process is, of course,
entirely optional, and isn't needed if you're just interested in
running PASS.
TBD
When we linked the
PASS software earlier, we produced images of the contents of
GPC memory for the various memory configurations (MC), or in
more-conventional terms, for the various "operational sequences"
(OPS) familiar to actual users of PASS.
TBD
In principle, it should be possible to load one of these memory
images into an AP-101S emulator and run it. In practice,
that's much more difficult than it sounds, because in actual use
one of these memory images will only be loaded after the
IPL process (or other software) has initialized the GPC and other
peripheral devices, and without that prior setup the memory image
cannot be run even if 100% correct. For example,
counter/timers need to be running, interrupt vectors need to be in
place and interrupts enabled, and so forth. There are other
issues as well, in that the GPC has memory-protection features,
and PASS software can be run only if (roughly speaking) all memory
containing code is "protected" and all data areas
are "unprotected". Any of these (and other) setups which
have not already been performed will cause PASS software to halt.
TBD
As I mentioned above, for the PASS software to be used in real
life, the GPC has to load it into memory from the Mass Memory Unit
(MMU). That was originally a tape drive, though it later
flights it was apparently a drop-in replacement using solid-state
memory instead, but we'll just continue to call the storage
mechanism a "tape".
Getting the built PASS software onto the tape is an adventure.
TBD
Depending on the particular contents of the tape and the current
legal thinking on the matter, it may be better for distribution
purposes to keep the tape in a compressed, encrypted form rather
than in the raw form as described above. My recommendation
at the moment is to use the 7z format. In Linux, the
compression step would look like this:
7z a -t7z -mhe=on -p TAPE.7z TAPE.mmv
On Mac OS and Windows it might be carried out differently.
The -mhe=on switch means to compress header as well
as data. The emulator itself recognizes that a compressed,
encrypted format has been used by the filename extension (".7z")
rather than the usual (".mmv"), and in the encrypted case prompts
for a password (with no echoing to the screen) or optionally lets
you input a password from a command-line option or an environment
variable, depending on how paranoid you may be about security. In
any case, the "tape" obtained from decrypting only ever exists in
memory, and not ever in the filesystem.
If everything above (other than the optional steps) has been done
correctly, it should now be possible to run PASS from the
tape! You will, however, have to understand a little bit
about the Initial Program Load (IPL) process, because it's not
automatic. And not fast, either. Why anyone would find
that acceptable in a flight-critical system in an object whizzing
through space, or possibly pointed toward the ground, at a high
rate of speed ... well, that's beyond my pay grade.
(Admittedly, everything is beyond my pay grade since I get
paid nothing for this, but you know what I mean.)
The minimal set of emulated equipment you'll need for an IPL is
fairly substantial:
Don't worry, if you've followed the setup instructions, all of
these things are available. Other combinations of
currently-existing emulated equipment are possible as well, but
won't be discussed here. These various emulations interact
via networking, as did the corresponding physical equipment in the
Shuttle itself. There, that network consisted of
MIL-STD-1553 buses, which are emulated via what's known as UDP
broadcasting.
Here's a basic IPL process we'll follow, though many variations
are possible. If you want to know more, the OI-32
PASS User's Guide has a more-extensive if still
abbreviated discussion.
Having reached OPS 000 (the "system sofware" or SSW), the
remainder of PASS is accessible via additional commands.
Although as I've mentioned so endlessly that it's probably
boring, for legal reasons we are afraid at present provide a full
copy of PASS on tape, so I've had an abridged tape prepared for
PASS OI-34.07 that includes only the IPL code and the following
major functions:
(Recall that GNC is for guidance & navigation, SM is for
system management, and PL stands for "payload" but is a misnomer
since it has nothing to do with the Shuttle's physical
payload.) Or in short, everything is provided on the
abridged tape except OPS 1/6 (Ascent / Return-to-launch-site) and
OPS 3 (Entry), so that you can't smash your simulation into
anything! Or to put it differently, so that you can't do
anything really interesting either. Still, it should give
you enough to play with, and I figure it's legally safe,
ITAR-wise.
We've provided a handy-dandy wrapper program (TBD) that
runs the simulation for you from the abridged tape:
TBD
Note: If you happen to have a different tape, such as the full OI-34.07, or OI-34.06, OI-30.17, or indeed something of your own devising, perhaps called MYTAPE.mmv, you could run it as follows:
In principle, it's even possible to directly run one of the memory-configuration images (SSW, G16, G2, G3, G8, G9, S2, P9) corresponding to the OPS directly, without ever going through the MMU "tape" or IPL process. This is trickier than it sounds, because the IPL process provides critical setups like memory protection, interrupt vectors, timer settings, and so forth, that aren't available otherwise. But we've tried to provide those to the extent that we can, so here are some commands you could try if you wanted:TBD ...
TBD ...
Let's look at the IPL process first, as it's a prerequisite to
everything else — after all, if you can't load a program, how are
you going to run it anyway? —, and yet it's ultimately the least
interesting thing. It's the equivalent of performing your morning
ablutions: a necessary preliminary to your day's activities, but
usually not something worthy of a "Dear Diary" entry.
Here's a video that shows going through an IPL process for GPC 1,
from power-up all the way to an OPS-101 (Ascent) menu screen. This
is not quite the easy, hand-off process we're familiar with on the
computers we use in everyday life. Rather, it's a hands-on
experience involving keypad entries and flipping switches on the
control panel, and it pretty much won't work unless you have a
pretty good idea what you're doing. As I'm sure you realize, the
control panel of the Orbiter is a rather large thing with hundreds
of switches, dials, indicator lamps, and so on, and we don't
pretend to emulate all of that stuff. For one thing, most of
it is irrelevant to you at any given time. For another,
there wouldn't be enough space on your computer's display screen.
Instead, we compromise and show just enough of the control panel
to deal with whatever "operational sequence" (OPS) of the flight
software (or boot software) that you happen to be in at the time.
During the course of the video, you'll actually pass through a
couple of different boot-loader programs, followed by a number of
PASS's so-called "operational sequences": FCMBOOT → GPCIPL → OPS-0
→ OPS-9 → OPS-0 → OPS-1. You'll start out with the 3 control-panel
chunks needed by the boostrap loader, and end up in OPS-1 with no
less than 14 control-panel chunks being displayed.
It's sometimes hard to see what's going on with the control-panel
manipulations if you don't know what you're doing — and even if
you do! — so I've taken the liberty of accentuating the
controls that are about to be manipulated by drawing a red circle
around them; of course, you wouldn't expect to see those during an
actual simulation. There are also some subtitles giving very
general descriptions of what's going on.
How do we know what to do with the keyboard and all of those
switches? The PASS
User's Guide (OI-32) goes through it step-by-step, as
well as providing some extra explanation of what's going on behind
the scenes, so I won't waste my or your time by rehashing
something you could read just as easily there as here.
Before proceeding, there are a few
general things worth knowing. PASS software is partitioned
into up to 10 Memory Configurations (MC) or Operational
Sequences (OPS), which as far as I can tell are essentially
the same things, although a purist can probably tell me some
difference between them which at that instant seems significant to
whoever is doing the telling. These are are identified in a number
of confusing ways by/for particular audiences:whereOPS O 0 N PRO
O0N is the MM's
3-digit number as in the diagram. For example, if you were in
MM 901 (in OI-34.07, "TBD") and wanted to transition to MM 201 (in
OI-34.07, "UNIV PNTR"), you'd use the command "OPS 201 PRO".
But if you
try to jump around at random from MM to MM, you'll quickly get into
trouble because not all transitions from MM to MM are allowed.
In the diagram to the right, for example, you see the allowed
transitions in OI-32. (Again: Are the identical transitions
allowed in OI-34? Don't ask me!) And indeed, if
you look at the table in relation to the example I gave earlier, of
transitioning from MM 901 to MM 201, you'll see that in fact it is not
legal: From MM 901, you can only transition to MM 000, so if you
want to get from MM 901 to MM 201, you'd have to do something likeBut that brings up another point, which is that this involves transitioning from OPS 9 to OPS 0 and then to OPS 2. You may recall that I equated each OPS to a "memory configuration" (MC). That's because there's too much PASS software to fit into GPC memory at any given time, so when you transition from one OPS to another it requires downloading the MC for the desired OPS from the MMU (or from a cache in another GPC) and replacing the MC already loaded into the GPC. So if you wanted to go from MM 901 to MM 201, you'd find that the GPC first downloaded the MC for OPS 0 (which happens also to be MC 0), and then a little while later download the MC for OPS 2 (namely MC 2).OPS 0 0 0 PRO
OPS 2 0 1 PRO
LMN,
the keyboard command would beThe available specialized screens tend to vary according to the current OPS, although some are available in most or all OPS:SPEC L M N PRO
SPEC 0 PRO — The "GPC MEMORY" screen, as in the
illustration at the right. TBD SPEC 1 PRO — The "DPS UTILITY" screen. TBDSPEC 2 PRO (not in OPS 1, 3, 6) — The "TIME"
screen. TBDSPEC 6 PRO — The "GPC / BUS STATUS" screen. TBDSPEC 9 9 PRO — The "FAULT SUMMARY" screen, which
allows you to see a list of the logged faults. You can also
quickly get to this screen via the keyboard's FAULT SUMM
button.
But that's only scratching the surface: There
are lots of specialized screens, and to learn more about them
you'll have to consult the Shuttle-era documentation. I'd
suggest the PASS User's
Guide OI-32.
whereITEM N + V EXEC
N is the option number and V
is the new value. For example, you see from "46 GPC _"
that for the "STORE" function, GPC has no default value. To
change it to GPC 3, the command would beNext to some items, like "DATA 20" for the READ/WRITE function, there is no underlined area. That means it's a toggle, with an asterisk ("*") next to it if enabled or selected, but no asterisk if disabled or not selected. The command to toggle it is justITEM 4 6 + 3 EXEC
or more generally, "ITEM 2 0 EXEC
ITEM N EXEC".Aside: Here's a heads-up on the computer resources you need to run the simulation in this form. Roughly speaking, to run a simulation using N GPCs, with N being 5 or less, you'll want at least N+1 cores. That's not to say that you couldn't get by with less in a pinch, but on my computer (which is new as of August 2026, and chosen to be as fast as possible at that time, consistent with what I think is a reasonable budget), each GPC takes about 80% of a core. These things will only get faster in the future, of course — knock wood! —, but I'm just saying that your experience may be less satisfactory on an older machine. The memory resources for the simulation are meager, around 30MB, and shouldn't concern anyone. But why is so much CPU needed to simulate such an old, slow computer system? I really can't point to any one factor. We've uncovered no obvious culprits so far. The need to insure synchronization between the GPCs and between the GPCs and the MEDS form some pretty hard constraints on what we can try, since a couple of hundred microseconds discrepancy here or there is enough to destroy synchronization.
In truth, there's very little visual indication that any of these
is going on, unless you call up specialized screens that detail
some of it for you. However, the control panel has a 5×5
array of indicator lamps, called the Computer Annunciation Matrix
(CAM), in which you can see what all of the GPC votes are. So when
it's working properly, all there is to see is a CAM array with
none of its lamps lit.
In the video below, you see a simulation run I IPL 4 GPCs and 2
displays, taking it all the way to OPS 2, and explain it as I go
with nifty subtitles. In this particular run no GPCs
experienced redundancy-sync problems, but believe me, if they had
done so you'd see it on the CAM.
If you want to get even more hard-core, below you'll the big
brother of the video above, in which all five GPC's are IPL'd, all
the way to OPS 1 (Ascent). This particular configuration is
as real as we can get, because normally you'd expect GPCs 1-4 to
run PASS while GPC 5 runs BFS, but we don't have BFS, so GPC 5
fakes it by stopping when it reaches OPS 0, just so it's not
running the same software as the other four. (Actually, this
is a bit more demanding than the realistic configuration, because
a computer running BFS doesn't participate in voting against the
computers running PASS, or vice-versa, but in this configuration,
all five of the computers are voting.) This video takes 15 minutes
to run, versus 8 minutes for the video above, but spices it up a
little more with some additional explanations.
