Table of Contents

• Introduction
• References
• PASS, BFS, and Other Shuttle Source Code
• Is this the Original Source Code?
  
• HAL/S
  
• Software Versioning
• Multi-Function Display Formatting and Versioning
• Computer-to-Peripheral Interface
  
• HAL/S and AP-101S Assembly-Language Processing

Introduction

Insofar as the Space Shuttle is concerned, the Virtual AGC Project's present goals — or if you'd prefer, my goals — are the following:

• To provide the complete source code for the software for the most-significant of its onboard computer systems, to the extent allowed by U.S. law.
• To provide all of the official documentation needed to understand that software and to work with it.  See the References.
  
• To provide development tools suitable for working with the software source code, and in particular for compiling/assembling it into executable form.
• To provide an emulator suitable for running that executable code.
• For the emulator to be integrated into space-flight simulation systems such as Orbiter+SSU or FlightGear.

In essence, we'd like to do the same kinds of things for the Space Shuttle's onboard computers, and in particular the computers' software, as we have done for Apollo's onboard computer systems and software.

I don't pretend to be putting together an "everything about the Space Shuttle" site.  If you want to know about the Space Shuttle's Main Engines (SSME) or Reaction Control System (RCS), or hear marvelous facts such as the maximum payload size being a 15×60 foot cylinder weighing 65,000 pounds, then this is not the place to look.  (But that's big, isn't it?  I never knew.)

Now, there are various nuances to the statements above, such as whether access to source code must be restricted in some ways, rather than being freely available.  And by "the" source code, do I mean all revisions?  Do I mean for all components of the system?  And by "the" development tools, do I mean the original ones, or do I mean partial work-alikes?  And by emulation, do I mean emulation of the entire stack of code, or just for some restricted portion of it?  And besides which, how do I really know which documents may be relevant to these matters and which may be completely irrelevant?

For example, although I explicitly said above that this isn't the site to come to if you want to learn about engines (SSME), the engines were in fact controlled by a dedicated controller containing two redundant Honeywell HDC-601 digital computers ... so shouldn't those computers and their software be covered here?

Answers to those questions will become clear in the sections below ... or at least, clearer than they are now.  There are a lot of gray areas.  And I don't pretend to know all of the answers yet, so we may need to await future events to have a more-complete picture.  But there aren't necessarily unique, permanently-correct answers anyway.  One thing I can say unequivocally is that integration into space-flight simulation systems is my hope rather than anything that I'll actively pursue personally; integration is the prerogative of the developers of those space-flight simulators, rather than mine, if they feel it's worthwhile for them.  But it's a bit premature to worry about that yet.

The upshot is that my explanation of the Shuttle's computer systems will by necessity be rather limited.  The system is simply too complex, and there are too many resources already available on the web for me to suppose that a presentation by a johnny-come-lately like me would be worthwhile or even interesting about a topic this big.  Perhaps the best place to get a general introduction would be Chapter 4, "Computers in the Space Shuttle Avionics System", of James Tomayko's Computers in Spaceflight: The NASA Experience, but there are numerous other documents in our Shuttle Library to provide more detail.

With that said, here's a brief synopsis.  As with any engineering system of substantial complexity, prepare to descend into acronym hell!

The portion of the Shuttle's full avionics system which primarily concerns us is the Data Process System (DPS), which includes the General Purpose Computers (GPC), the crew interface (display and keyboards), the mass-memory units, and the data-bus network interconnecting all of them.  Here's a diagram, swiped from the aforementioned Computers in Spaceflight, that gives a very high-level view of the system architecture:

As you can see, there were five separate GPCs.  Each of the GPCs on later flights was an AP-101S computer, designed and manufactured by IBM's Federal Services Division (as were the Apollo LVDC or Gemini OBC, though the GPC was not similar to them in any noticeable way).  Although I may not talk about the AP-101S much, it's worth mentioning that it was a kind of embedded version of the IBM System/360 mainframe, in that it shared roughly the same assembly language, known as Basic Assembly Language (BAL).

Aside:  To be perfectly pedanticaccurate, the GPCs were originally AP-101B computers.  The AP-101S is an upgrade of the AP-101B, replacing 416KB of core memory with 1024KB of semiconductor (CMOS) memory, and possibly other improvements that I've so far not been able to identify for certain, though there are various machine-code instructions that I believe were newly-added in the AP-101S.  The upgrade effort began in 1989, and was first flown in 1991 on STS-37 with software version OI-8F.  More on the topic of flight-software versioning will appear later.

Four of the GPCs nominally redundantly ran identical software, known as the Primary Flight Software (PFS) atop the Flight Control Operating System (FCOS).  PFS and FCOS together are collectively referred to as the Primary Avionics Software Subsystem (PASS). 

Aside: In spite of this technical distinction between the acronyms PFS and PASS, I find in practice (and have been chided by veterans of the Shuttle project) that the term PASS was always used in preference to PFS.  In other words, people speak of PASS vs BFS rather than PFS vs BFS, and stare at you blankly if you mention PFS to them.  Since that is the common usage, I'm going to adopt it throughout the remainder of this article, and will not bull-headedly use the acronym PFS (even though I think it's technically correct) even where the distinction vs PASS is significant.

Nominally, the behaviors of these four copies of FCOS were synchronized ... not on a CPU-cycle by CPU-cycle basis, but to the extent that inputs to the GPCs from the spacecraft, as well as commands output from the GPCs to the spacecraft, occurred at the same time.  In particular, the fact that outputs from the GPCs were synchronized allowed detection if one of the GPCs was behaving abnormally.  I say they did this "nominally", because this extreme level of redundancy was warranted only during critical flight phases ... in particular, during ascent and reentry.  During the more-leisurely phases of the mission, if additional computing power was needed, the four principal GPCs did not necessarily need to run identical, redundant software.

The fifth GPC instead ran the Backup Flight Software (BFS), created entirely separately from PASS in a clean-room fashion.  This fifth GPC served roughly the same purpose in the Shuttle as the Abort Guidance System (AGS) did in the Apollo LM.  BFS was specialized for abort functionality, i.e., reentry in the absence of a reliable set of GPCs running PASS.  And as I said above, this capability was really (potentially) needed only during ascent or reentry.

The data buses interconnecting the GPCs and peripheral devices, physically and electrically, were MIL-STD-1553 buses.

The crew-interface devices included:

• 26 line by 51 character displays, capable also of displaying some graphics.  Prior to about the year 2000, the pilots had 3 of these displays and the crew specialist had 1; they were monochrome (green text on black background) cathode-ray tubes (CRTs).  After 2000, the CRTs were replaced by multi-color liquid crystal displays (LCDs), 9 for the pilots and 2 elsewhere.  Collectively, the CRTs and LCDs were referred to as Multifunction Display Units (MDUs). 
  
• Keyboards.  The pilots had 2 of these, and the mission specialist station had a 3rd.

The pre-2000 configuration was known collectively as the Multifunction CRT Display System (MCDS), while the post-2000 configuration was known as the Multifunction Electronic Display Subsystem (MEDS).

In the diagrams below, the pre-2000 configuration is shown on the left, while the post-2000 configuration is shown on the right.  Notice that the LCD-based displays (on the right) have 6 buttons along the bottom edges that the CRTs (on the left) lack, as well as being taller relative to their width.  The LCDs continued to display 51×26 textual characters, just as the CRTs had, but the text was scrunched into the upper part of the screen, while a strip along the bottom of the LCD could display additional stuff that the CRTs hadn't been able to, such as menu options selectable by the edge buttons.  These differences were transparent to the PASS / BFS flight software, because the additional stuff displayed along the bottom was not controlled by the PASS / BFS software.  In contrast, keyboards were the same in type and number throughout the duration of the Shuttle program.

Older configuration:  4 CRT displays (Multifunction CRT Display System, or MCDS)

Newer configuration:  11 LCD displays (Multifunction Electronic Display Subsystem, or MEDS)

There's a more-inclusive diagram below (click to enlarge) of the entire older configuration of the avionics system, if you feel the need for one.  Personally, I'm just including it because it's colorful, and you'll need to dig into the actual documentation if you want real detail.  By the way, you can tell it's the older configuration (MCDS) rather than the newer one (MEDS), because if you look in the upper-left area, you'll see "CRT 1", "CRT 2", "CRT 3", and (somewhat below the others) "CRT 4", rather than the 11 MFDs you'd see in the newer configuration:

Below, on the other hand, is an extremely-informative diagram of display-system interconnections that specifically for the newer MEDS configuration.  Don't be confused by the fact that some of the LCDs are designated by names like "CRT N", because they're not CRTs; they're just legacy names!

Like the AGC, AGS, and LVDC, which were programmed essentially in the assembly language native to their CPU types, the Flight Control Operating System (FCOS) and were written the assembly language of the AP-101S CPU.  But once you get past those infrastructural software components, the bulk of PASS application code was written in a higher-level language called HAL/S, as was the BFS.  The DPS Overview Workbook explains the overall structure of PASS better than I can: 

"PASS software consists of two types of software: system software and application software. System software runs the GPC. It is responsible for tasks such as GPC–to–GPC communication, loading software from MMUs, and timekeeping activities. Application software is software that runs the orbiter. This includes software that calculates orbiter trajectories and maneuvers, monitors various orbiter systems (such as power, communications, and life support), and supports mission–specific payload operations. The application software is divided into broad functional areas called major functions; in turn, each major function consists of Operational Sequences (OPS), which are loaded into the GPCs for each major phase of flight.

"Finally, each OPS has one or more Major Modes (MMs) that address individual events or subphases of the flight."

Schematically, you can see how the application software was structured, at least in one version of the flight software.  Over the decades in which the Shuttle's flight software was in use, there were certainly changes to this structure.

References

All documents I can find that I feel are relevant to discussion of the Space Shuttle's onboard computer systems and their software have been collected on our Space Shuttle Library page.  That should be your first stop in a documentation pilgrimage!  However, here are some websites that have additional documents that you may find interesting, and which may still contain relevant materials that I've overlooked:

• The FlightGear wiki entry on Space Shuttle avionics.  FlightGear is a flight simulation system.
• Ken Hollis's Space Shuttle page.
• The NASA Technical Reports Server (NTRS).

PASS, BFS, and Other Shuttle Source Code

I have become aware of the survival of late revisions of the Shuttle's flight software, both primary (PFS/PASS) and backup (BFS).  This is remarkable, given that a former developer of Shuttle software has told me that:

"When NASA shut down the Space Shuttle project, they erased all of the backup storage media — since there WAS NO REQUIREMENT for saving source code!  Most of the HAL/S compiler and related tools (like ... other support software were not saved), but all of the HAL/S-based flight code was preserved."

In fact, I filed a Freedom of Information Act (FOIA) request with NASA's FOIA Office to get a copy of the flight software from NASA, but after several months of looking around they asserted that they didn't have a copy of it.  So apparently NASA fully lived up to the lack of a requirement for preserving it, in spite of the assertion of my informant that the flight code had in fact been mysteriously saved (somewhere) after all.  My developer informant also told me that the Shuttle flight-code was the most-expensive software-development project of all time.  Good job all around, U.S. Government agencies, preserving tax-payer investment!

But I digress. 

Unfortunately, confirming that the source code for the Shuttle's flight software still exists is not the same thing as saying that I've convinced anybody to give me all of it.  Without being too specific, I will simply say that I presently have significant quantities of PASS source-code files in hand, along with some BFS files, but that I am not at liberty to show them to you due to issues which I hope can eventually be resolved.  Indeed, I can't even necessarily tell you yet everything I have managed to acquire.  It's an unpleasant situation that I hope and expect to improve over time.

On the other hand, here is some software source code we do have, and which you can see right now in our source tree:

• HAL/S-FC — the HAL/S compiler, used to actually compile PASS and BFS.  More specifically, HAL/S-FC release 32V0, written mostly in an enhanced version of the XPL high-level language, with bits in BAL (IBM 360 Basic Assembly Language) and in AP-101S assembly language as well.  More on this below.
  
• XCOM — the source code for the original "standard" XPL compiler.  Alas, it is guaranteed not to compile HAL/S-FC, since HAL/S-FC was written in an enhanced version of the XPL language, which I call "XPL/I", but which Intermetrics unfortunately continued to call just "XPL".  I will persist in calling it XPL/I, however, because there are reasons the distinction is important.  Intermetrics's compiler for XPL/I, to the best of my knowledge, has not survived the end of the Shuttle program.  Nevertheless, there are reasons why the source code for the standard compiler remains useful, and perhaps those reasons will become clear below.  Although it is not the contemporary software used during Shuttle development, I have myself written an XPL/I compiler called XCOM-I which is capable of compiling HAL/S-FC.
  

Is this the Original Source Code?

To the extent that we can present the contemporary source code for Shuttle-related software here, or to work with it using the tools provided on this site, some alterations from the original source code files have been needed.  We hope that these changes are not substantive, but a difference is a difference, and you're entitled to know about it if you're interested.

For one thing, Virtual AGC header blocks, consisting of program comments, are added at the top every contemporary file we receive, so that you can understand the provenance of the files as much as possible.  These comments are crafted in a way that lets you distinguish such "modern" comments from the original contents of the files. 

Flight software files, when they become available, are expected to be "anonymized" or "depersonalized", so as to remove all personally-identifying information related to the original development teams; thus, whenever the name or initials of a programmer are discovered in the program comments of Shuttle flight software, we have replaced them by a unique but impersonal numerical codes.  This is at the behest of some holders of the original source materials, as a condition for obtaining the software.  Whether this is a temporary or permanent condition, I cannot say.

Most significant, I expect, is the fact that the character encoding of all contemporary Shuttle source code has been completely changed.  This necessity arises directly or indirectly from the fact, unfortunate from our point of view, that the contemporary character-encoding system used was an IBM system called EBCDIC (Extended Binary Coded Decimal Interchange Code), while modern source code (as far as I know) is universally encoded using 7-bit ASCII (American Standard Code for Information Interchange) or extension of it such as UTF-8.  But EBCDIC and ASCII are essentially 100% incompatible, with only rare, accidental overlaps.  The recoding of the source-code files from EBCDIC to ASCII has been done before we ever received any of the files, and was performed by unknown people, at an unknown time, using an unknown process.  Nor was it always perfectly done, and has required occasional corrections by us.

Moreover, the EBCDIC vs ASCII issue isn't quite as simple as the preceding paragraph suggests, because not all of the EBCDIC characters used originally actually have ASCII equivalents.  There are special considerations regarding how you need to work with HAL/S source code in light of those characters not supported by ASCII.

Here are the general rules:

1. HAL/S source code should be encoded using 7-bit ASCII characters.
2. Two characters originally used in HAL/S source code and in the original documentation, namely the logical-not character "¬" and the U.S. cent character "¢", are not present in 7-bit ASCII.  So instead, we use the ASCII characters "~" and "`", respectively, in place of them.   For example, every time you might have seen something like "x ¬= y" in the original HAL/S source code or documentation, we'd expect "x ~= y" instead!
3. A compiler directive of the form "D VERSION v" was sometimes used in original HAL/S source code or template-library files.  Here, "v" is a numerical version code in the range of 1 through 255, represented as a single EBCDIC character.  To reiterate, a single character position in this compiler-directive string must represent up to a 3-digit version number.  The way they did this originally was simply to pretend that the version code was the numeric byte encoding for a character, and to insert that single-byte numeric code into the string.  For example, if the version was 1, then instead of using the character "1" in the compiler directive, the numerical byte 1 was inserted.  This would have been legal in EBCDIC, even though rather inconvenient since in most cases the character would have been unprintable.  In ASCII or UTF-8, the problem goes beyond that, and such a single-character usage doesn't even represent a valid ASCII or UTF-8 character half of the time.  So we cannot continue to follow this odd practice.  Our change is to instead require this compiler directive to have the form "D VERSION xx", where xx is a 2-character string of hexadecimal digits.
   

Aside:  With that said, if your operating system supports UTF-8 character coding rather than simple 7-bit ASCII, you can continue to use "¬" and "¢" in HAL/S source code.  The compiler transparently converts them to "~" and "`" during the compilation, and then converts them back to "¬" and "¢" in printouts or in messages it displays.  In particular, this does work fine in Mac OS and Linux, though there may be special considerations trying to do this in Microsoft Windows, discussed later.  In some of the source code we receive, ¬ has instead already been replaced by "^".  Thus any software we provide also silently converts "^" to "~".

HAL/S

HAL/S is a high-level programming language in which the PASS and BFS application software was written.  Whereas infrastructural software (like operating systems and run-time libraries) was written in whatever assembly-languages were native to the particular CPUs running that code.

HAL/S is a compiled language, and the HAL/S flight-software source code was compiled down to a machine-code executable before it could be run.  Compilers existed for it that could be used on several different types of computers.  Some of the compilers produced code that could be run on an IBM System/360 mainframe; others could produce executable code for the Shuttle's IBM AP-101S onboard computers; others produced executable code for other computers.

I'm sure you can't help but notice that "HAL" was the name of the computer in the movie 2001: A Space Odyssey, which came out in 1968, not too many years before the HAL/S language was invented.  In the movie, H.A.L. stood for "Heuristic Algorithmic Logic", and many people have observed that H.A.L. was just one letter away from I.B.M.  (I.e., "H" is one letter before "I" in the alphabet, "A" is one letter before "B", and "L" is one letter before "M".)  The writer of the movie, Arthur C. Clarke, maintained that that was simply a coincidence.  Where the "HAL" in HAL/S comes from has likewise been explained in several ways, none of them relating to 2001: A Space Odyssey.  The HAL/S language was invented (and the flight software was written) by a company called Intermetrics, many of whose employees were refugees from the same Draper Laboratories (MIT Instrumentation Laboratory) at which the Apollo flight software had been written.  One of those refugees was Ed Copps, one of Intermetrics's founders, who is said to have named the HAL/S language in honor of Hal Laning, perhaps the most-prominent among the designers of the Apollo Guidance Computer's hardware.  Others offer the explanation that HAL/S is an acronym for "High-order Assembly Language / Shuttle".  Still others state that "the acronym 'HAL' was never formally defined".  I have even seen one report (NASA-CR-141758) that refers to it as "Houston Aerospace Language".  Well, who knows?  It's fun to make up your own mind about which constellation of facts matches your own preferences.  Probably not Houston Aerospace Language!  But all I can really say for sure is that there's nothing "heuristic" about HAL/S, even if 2001 may secretly have been somewhere in the back of somebody's mind.

But I digress.  As I was saying, the HAL/S software for some revisions of the Shuttle's PASS and BFS still survives, which is much better than the alternative of it not existing anywhere.  At present, I am enjoined to keep that which I do have private.

Assuming that we can eventually get access to it, working with the application software's source code requires knowledge of the HAL/S language.  Fortunately, we have a fair amount of documentation of that:

1. The recommended starting point is "Programming in HAL/S" by Michael Ryer, which was intended as an introduction to programming in HAL/S and is organized as a tutorial.
2. A great supplement to Ryer is the course material for "Basic HAL/S Programming" by Craig Schulenberg.  Additional material associated with that course can be found on our Shuttle library page.
   
3. Ryer's book points out that it is not a definitive exposition of the language, and recommends proceeding afterward to the "HAL/S Language Specification", which contains a much-more-formal specification of the language syntax, both in the form of graphs of the syntax and in Backus-Naur form (BNF).
4. Or to the "HAL/S Programmer's Guide".
5. And then there's the "HAL/S-FC User's Guide" explains how to compile and execute a HAL/S program.  That explanation is, of course, completely irrelevant to our present situation, but you may find that the document answers some questions left unanswered by the preceding documents.  (You many notice as well that our library contains a "HAL/S-360 User's Guide"; that's simply a predecessor of the "HAL/S-FC User's Guide".  The former assumes that the computer on which the compiler ran was an IBM-360, while the latter assumed it was some arbitrary "mainframe" to which the compiler had been ported.)
   

We actually have quite a few revisions of some of these documents in our library, spanning the mid-1970's to the mid-2000's, though I've only chosen to link the latest versions of those documents above, even though from time to time the latest revision isn't always the most complete one. 

Here's a brief sample of HAL/S code from "Programming in HAL/S", just to give you its flavor:

  FACTORIAL:
  PROGRAM;
     DECLARE INTEGER,
             RESULT, N_MAX, I;
     READ(5) N_MAX;
     RESULT = 1;
     DO FOR I = 2 TO N_MAX BY 1;
         RESULT = I RESULT;
     END;
     WRITE(6) 'FACTORIAL=', RESULT;
  CLOSE FACTORIAL;

What this program does is to read a number (N_MAX), compute its mathematical factorial, then output the result.  While I won't dissect this short program in detail, I can make a couple of observations.  For one, the language is strongly typed, meaning that every variable has a type that's declared at compile time, and that storage for it is fixed and unalterable at run-time.  Nor is there any dynamic memory allocation (as well as no stack and no recursion), so RAM usage is completely known at compile time.  HAL/S programs never unexpectedly abort because memory has filled up.  The other observation is that the READ(5) and WRITE(6) statements are very familiar to FORTRAN users ... or at least to FORTRAN users of (say we say?) a certain vintage.  In FORTRAN-speak, the 5 and 6 are "logical unit numbers" (LUN) whose specific interpretation as keyboard and printer (or keyboard and display, or even as files) are assigned externally by the Job Control Language (JCL) used to run the job.  This reflects the fact that the first HAL compilers targeted IBM 360 computers rather than the Shuttle's computers.  In the Shuttle software, these READ and WRITE constructs, I think, wouldn't have been used, and keyboard input or display output would instead have been handled by calls to the run-time library.

C Compute corners of a parallelogram.

  CORNERS: PROGRAM;
     DECLARE SCALAR,
                LONG, SHORT, ALPHA;
     DECLARE VECTOR(2),
             AB, BC, CD, DA;
     READ(5) LONG, SHORT, ALPHA;

E    -
M    AB = 0;

E    -
M    BC = VECTOR (LONG, 0);
S               2

E    -
M    DA = VECTOR (SHORT COS(ALPHA), SHORT SIN(ALPHA));
S               2

E    -    -    -
M    CD = BC + DA;

E             -   -   -   -
M    WRITE(6) AB, BC, CD, DA;
  CLOSE CORNERS;

E         DEX$J

E       I              I

M   COEF          ALPHA

S                      L

S                       M**2

• '-' for vectors.
• '*' for matrices.
• ',' for strings.
• '.' for booleans.
• '+' for structures.
  

  CORNERS: PROGRAM;
     DECLARE SCALAR,
                LONG, SHORT, ALPHA;
     DECLARE VECTOR(2),
             AB, BC, CD, DA;
     READ(5) LONG, SHORT, ALPHA;
     AB = 0;
     BC = VECTOR$2(LONG, 0);
     DA = VECTOR$2(SHORT COS(ALPHA), SHORT SIN(ALPHA));
     CD = BC + DA;
     WRITE(6) AB, BC, CD, DA;
  CLOSE CORNERS;

DECLARE SCALAR, X, Y, Z;
DECLARE INTEGER, I, J, K;
X = Y Z ;
I = 2 J K ;

By the way, SCALAR is what HAL/S calls its floating-point type; thus SCALAR contrasts with INTEGER or BOOLEAN datatypes, but not with VECTOR or MATRIX.  In fact, all VECTOR and MATRIX objects consist entirely of SCALAR values.  You can't have (say) a VECTOR of INTEGER values.  On the other hand, there is an ARRAY type, of arbitrary dimensionality, which can hold values of any datatype you like, including VECTOR and MATRIX.  And as it turns out, there actually is an operator '*', but it is the vector cross-product operation, not a multiplication of two numbers.  Similarly, the '.' operator is a vector dot product.

Software Versioning

As I've described above, any given shuttle had a number of computers, running a lot of different software components — more than just the GPCs running PASS/BFS we're discussing here.  Each of these software components had their own unique versioning.  I couldn't begin to tell you what those all are; I don't even have a list of all the different computers or their software components, let alone details about their versions.

However, in all but the very earliest missions, the collection of all of the software components at their various revision levels was itself identified by what's called the Operational Increment (OI).  You thus see various Shuttle documents specifying "OI-24" or "OI-33", and what this means is that those documents are specialized to those particular overall software versions.  The versioning of individual software components of the overall software version was apparently by Version Increments (VI), such as "VI 1.23".

At this point, I have no authoritative single document that links software versions to specific Shuttle missions.  For what information I do have, I'd refer you to the Space Shuttle Missions Summary.  In the following tabulation, sorted by software version, notice that a higher STS mission number sometimes has a lower software version number, presumably partially because the mission numbering doesn't perfectly agree with the chronological order in which the missions were flown.  For that matter, notice confusing duplicate numbers, like the entire range STS-26 through STS-33 (skipping STS-29); not my fault, blame NASA!

For example, the presentation for the STS-121 Flight Readiness Review (FRR) tells us that the software version was OI-30, in agreement with the table above, while just the Integrated Display Processor (IDP) software component was version VI 4.01 and the Multifunction Display Unit Function (MDUF) was version VI 5.00.

Multi-Function Display Formatting and Versioning

As was mentioned earlier in the Introduction, the principal method by which the General Purpose Computers (GPC) running the primary flight software (PASS) and backup flight software (BFS) interact with the crew includes keyboards and display screens.  What's unusual about the display screens is that what appears on them is only partially controlled by the PASS or BFS software.  Instead, there was another processor sitting between each of the displays and the GPCs, and it was this extra processor that directly controlled what was displayed and how the display was formatted.  (For that matter, the keyboards also were attached to one of these extra processors rather than to the GPCs, so whatever keystrokes were seen by the PASS / BFS software had already been pre-digested by these extra processors.)

In the case of the older, pre-2000 cockpit configuration (MCDS, 4 CRTs), this extra processor was known as the Display Electronics Unit (DEU), and it consisted of an IBM SP-0 CPU with 8K×16 bits of RAM.  In the case of the newer, post-2000 cockpit configuration (MEDS, 11 LCDs), the extra processor was known as the Integrated Display Processor (IDP), an Intel 368DX microprocessor.  The basic schema is seen in the diagram to the right.  While the diagram is specific to the older (MCDS) configuration, the newer (MEDS) configuration is conceptually quite similar.  In the case of the MEDS configuration, the software for the IDP that was specifically tasked with formatting the display was called the Display Application Software (DAS).  But these kinds of details are of little interest to us in the absence of the DAS or other software that actually ran on the DEU/IDPs.  So the only use of these factoids I'll make in the context of the present discussion is to refer from now on to what I've been calling the "extra processor" instead as the "DEU/IDP".

What is of importance to us, however, is that in addition to inputs from the GPCs via the MIL-STD-1553 databuses, the DEU/IDP's RAM was used to store a set of templates that controlled the formatting of the display screen.  These templates were loaded from mass memory into RAM at power-up.  In other words, the screen templates are independent of the PASS / BFS source code.

PASS GNC SYS SUMM 1 screen, STS-96

BFS GNC SYS SUMM 1 screen, STS-96

As you can probably deduce from these images, some of the areas are supposed to be updated with data from the GPC (or elsewhere in the spacecraft), such as the HH, MM, and SS in the upper-right corner or the X's and S's that are all over the place.  Other markings, like the "SURF", "POS", "MOM", and "DPS" are simply features of the template, and don't change at the whim of the GPC or more specifically, of PASS or BFS.

The screen templates don't quite fall under the Operational Increment (OI) top-level software-versioning scheme we've already discussed.  They do, but they are also controlled by Program Change Notices (PCN).  The examples above are for STS-96 which flew software version OI-27, but that doesn't mean that all missions using OI-27 necessarily had identical screen templates.  In a practical sense, what this means is that to know the screen templates and consequent display-screen formats for any given Shuttle mission, we must have not merely the screen templates for that generic OI, but also the differences to those templates that were made due to specific PCNs ... and of course, actually have the associated documentation so that we can consult it. 

Several documents provide screen templates that can be related to one or more missions or software versions.  The most-available seems to be JSC-48017,  the "Data Processing System Dictionary".  We have several revisions of JSC-48017 in our Shuttle Library, and in principle, if we could collect all of the different revisions, then we'd have all of the screen templates for all of the missions.  The GNC SYS SUMM 1 sample templates above came from one such DPS Dictionary.  There are also reference-card-like summaries that are very helpful, such as this one for OI-34.

On the other hand, the Functional Subsystem Software Requirements (FSSR) documents also contain these templates, and seem a lot more authoritative, as well as providing a lot more information. In fact, the FSSR goes so far as to give screen coordinates for each field, and to explain how every datum received by the DEU/IDP via the databus relates specifically to each X and S on the display screen!  Unfortunately, the FSSRs are also a lot more numerous and a lot harder to find than DPS Dictionaries are, so the dream of obtaining a complete set of them seems more whimsical than obtaining a complete set of DPS Dictionaries.  Nevertheless, on balance, it seems as though the FSSRs should be regarded as the controlling documents for the screen templates.  We just need to collect all of them, or failing that, fall back on DPS Dictionaries when available.  For example, here are the same GNC SYS SUMM 1 templates, but for software version OI-34 (say, mission STS-128), taken from the FSSR.  They're different than the ones shown above for STS-96, though only barely so.  Personally, I see only 4 differences, some sensible, some nonsensical, and some (I suspect) misprints; perhaps you can find more.  Incidentally, STS-96 had the MCDS (pre-2000) cockpit configuration, while STS-128 had the MEDS (post-2000) cockpit configuration, so perhaps that has something to do with the differences.

PASS GNC SYS SUMM 1 screen, STS-128

BFS GNC SYS SUMM 1 screen, STS-128

Computer-to-Peripheral Interface

Keyboard data was supplied to the General Purpose Computers (GPC), and hence to the PASS/BFS software, by means of messages on the MIL-STD-1553 databuses interconnecting the GPCs and DEU/IDPs.  Similarly, data was output by the GPCs for display by passing messages on the databuses as well.  Technical details about this messaging can be found in the Data Processing System Brief.  I won't bother to summarize that information here, since the document's presentation is at least as readable as anything I might write up to supplement it.  While our only available revision of this document so far is for the MCDS, recall that the change from the MCDS to MEDS cockpit configurations was done in a way that was transparent to the existing software.  That implies, I hope, that the messaging format would have been the same in either configuration.

TBD

HAL/S and AP-101S Assembly-Language Processing

• A HAL/S compiler.  Known as HALSFC, this is available and is covered on its own dedicated page, though it is not 100% bug-free yet.
  
• An IBM AP-101S/AP-101B assembler.  Known as ASM101S, this is a work in progress.
  
• An IBM AP-101S linker.  Tentatively designated HALLINK101S, this is not actually anything on which work is being done, and so far it has no place as such on the roadmap.  However, there is a page covering my preliminary thoughts on the subject, especially details of the (reverse-engineered) format of AP-101 object files.
  
• An IBM AP-101S emulator.  Known as ap101s, this is a work in progress, but as the effort is external to the Virtual AGC Project per se, I have few worthwhile details to share other than that it is somewhat based on the similar System/360 emulator, sim360, that I have described elsewhere.  But I have no up-to-date status or other information concerning it.
  

This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2024-12-01