|
Virtual AGC — AGS — LVDC — Gemini
yaDSKY
The DSKY Emulator
|
|
|
|
Please enable javascript in your browser to see a site-search form here.
|
Contents
|
What
is a DSKY?
The DSKY is the "display/keyboard" (DSKY) used by
the Apollo Guidance
Computer (AGC). The DSKY provided only a means to input keyboard
data to the AGC, or to display visual information at command of the
AGC, and therefore had little or no functionality of its own, when
considered as a stand-alone device.
The DSKY may seem somewhat familiar from, for example, the movie Apollo 13. In the HBO mini-series, From the Earth to the Moon, the
DSKY appears so prominently that it almost becomes another character
(dramatically speaking).
For those of us who are familiar with it from these sources, it is easy
to think of the DSKY itself as being the computer. However, the
DSKY really was quite independent from the AGC. From the
computer's standpoint, the DSKY was just
another few i/o channels, more or less, as in the block diagram below. |
|
The Lunar Module had a single DSKY, at
the bottom center of the control panel. The Command Module had
two DSKY units: one in the main
control panel near the commander; the other at the navigator's station.
What is yaDSKY?
yaDSKY is a
computer program which emulates the DSKY. yaDSKY has now been superceded by yaDSKY2, though both programs are
still available, and with only minor differences are
interchangeable. So in speaking of "yaDSKY" I am really speaking
of either program unless I explicitly state otherwise.
The DSKY had little or
no functionality of its own, when
considered as a stand-alone device. The same is true of the yaDSKY emulation of the DSKY.
It requires the yaAGC program
(which simulates the AGC) to be useful. Just as the true
AGC and DSKY communicated between themselves by means
of wiring, the virtual yaAGC
and yaDSKY communicate between
themselves
using communication channels (sockets) that act like virtual
wires. In other words, yaDSKY
merely communicates keypresses to yaAGC,
and receives communications from the yaAGC
about which lights to activate.
If you don't like my yaDSKY,
or if you want to integrate yaAGC
into a larger simulation
project, or if you want something that works on a platform I don't
support, you can replace yaDSKY
with a program more to your liking. The method for doing so is
described in detail on the developer-info
page. In fact, Stephan Hotto has done just that (among other
things) with the LM_Simulator
software he has contributed to this project. At the right is a
very cute screenshot (click to enlarge) of yaDSKY and Stephan's "DSKY LITE"
running side-by-side and communicating with the same yaAGC.
Running yaDSKY
The yaDSKY2 program is invoked
as:
yaDSKY2
[OPTIONS]
while yaDSKY is invoked as
yaDSKY
[OPTIONS]
or
yadsky
[OPTIONS]
The available options are as follows:
--help
Display a list of options, something
like the information shown here.
--ip=addr
yaDSKY
and yaAGC are a client/server
pair, and can be running on the same computer or on different
computers. In order to connect to the yaAGC
server, yaDSKY has to know the
IP-address of the machine on which yaAGC
is running. By default this is "localhost"—i.e., the two are running
on the same computer. However, a different IP address may be specified
using this command-line switch. In Linux, this may be either the
machine's name, or else a numerical address in dotted format (n.n.n.n).
MS-Windows—at least Windows 98—is somewhat crippled in this
respect, and will only accept a host name rather than a numerical IP
address.
--port=port
Similarly (see above), in addition to
an IP address, a port number is needed. This must be in the range of
port numbers
yaAGC is scanning
(which by default is 19697-19706). If no port is specified,
yaDSKY will use 19697 (since the
Apollo 11 mission was in July 1969). A simulation of the Command Module
would require
two DSKY units,
one for the contral panel and one for the navigator's station; so two
copies of
yaDSKY would be run,
and would have to be assigned different ports (such as 19697 and
19698). The
developer page contains
suggested port assignments,
including the suggestion that Colossus should use the range 19697-19706
while Luminary should use the range 19797-19806.
--cfg=ConfigFilename
This switch configures the DSKY for
different Apollo missions or for CM vs. LM operation. Among the
things that differ in different configurations are the legends that
appear on the 14 indicator lights on the upper-left side of the DSKY
panel, and the labeling on the PRO key. The DSKY is reconfigured
through the use of configuration files, of which the ones that exist as
of this writing are CM0.ini, CM.ini, LM.ini, and LM1.ini. (A
description of the differences appears later.) If no "--cfg"
switch is
present, default values are used which are the same as those in the
distribution version of LM.ini, but the LM.ini file itself is not used
unless specified by the presence of "--cfg=LM.ini". Refer to the
developer page
for information on modifying
the legend sets or adding new sets. If a complete pathname for
ConfigFilename is not specified,
then
yaDSKY
will look first in the current directory, and then (for software
versions 05/06/2004 or later) in the installation directory (which is
/usr/local/bin by default, but which may be changed at
build-time).
--half-size
(Only versions 20040811 and
after.) yaDSKY's
graphical interface is simply too big for PC's with lower graphical
resolution (smaller than 1024×768). If the --half-size
switch is used, half-size graphics are used, and so the interface
should be usable even down to 640×480 resolutions. The
smaller interface doesn't really look very good, because it is
simply blindly scaled down from the larger interface, rather than being
optimized, but at least it's usable at 800×600 and 640×480
resolutions. If both the --half-size and --cfg switches are used,
the --half-size switch must be to the left of the --cfg switch on the
command line.
--delay=Milliseconds
(Versions 20040821 and after.)
Adds a delay at start-up, so that
yaDSKY
does not immediately begin attempting to communicate with
yaAGC. The current defaults
are 0 ms. in Linux and 500 ms. in Win32. This "feature" has been
added as a temporary work-around for
problem
report #23, and probably has no other sensible purpose. Even
on Win32 it isn't usually needed, but it's here for the 10% (or
whatever) of the time it's needed.
--debug-counter-mode
(Versions 20050515 and after.)
This is present only for debugging the AGC's "unprogrammed"
counter-increments, and has no useful purpose otherwise. In this
mode, the keys of the simulated DSKY—or at least, the VERB, NOUN,
0-7, and PRO keys—do not have their normal interpretations and
cannot be used to affect the AGC CPU in any normal way. Instead,
the combination NOUN-
digit-
digit is used to specify an (octal)
CPU counter-register number, and the combination VERB-
digit is used to select a
counter-increment type as defined on the
developer page. The PRO key
is used to send the selected counter-increment command to the AGC, to
increment/decrement the counter-register. Note that there are no
visual displays associated with this, since the AGC is still commanding
the DSKY visual display in its usual way, so you just have to mentally
keep track of what counter-register and which unprogrammed-increment
command you've chosen. This mode is terminated only by restarting
yaDSKY. Only counter
registers in the range 32-60 (octal, default 32) are accepted, and only
increment-types in the range 0-6 (default 1) are accepted. Any
time the PRO key is pressed with settings outside this range, no action
occurs. The only useful way to use this is to make sure that
yaAGC has been run in debug mode,
and to
use the
yaAGC debugger's
"dump" command to check the results of the various increment/decrement
commands. For example, if the default settings aren't changed,
the command "dump 32" will initially show 00000, but will show "00001"
after the PRO key has been hit once, "00002" after the PRO key has been
hit twice, and so on.
--test-uplink
(Versions 20050626 and after.) In
this mode, keystrokes are communicated to yaAGC via the digital uplink rather
than via the normal CPU input channel 015, but this is relatively
transparent to the user, other than the fact that the UPLINK ACTY
indicator lights up. Normally this facility
would have been used by the ground-station for uplinking data.
However, since the uplink consists of encoded DSKY keycodes,
"--test-uplink" provides a convenient method of testing this facility
without having to write a whole new program. I've noted that when
using this mode, the keystrokes seem to work properly, but updating the
DSKY display is very hit-and-miss. I assume this is a normal
property of the uplink—rather than a bug in yaAGC—but I don't really
know.
--test-downlink
(
yaDSKY
versions 20050628 and after. Not available in
yaDSKY2, but equivalent
functionality is provided instead by the
separate
yaTelemetry program.)
In
this mode,
yaDSKY provides the
additional function of displaying telemetry-downlink lists as they are
emitted from the AGC, in a manner similar to the
yaTelemetry program.
To use this mode effectively,
yaDSKY
should be run from a terminal window which is at least 80 text-columns
wide, and at least 36 text-rows high; otherwise, a complete downlink
list will not fit on-screen and portions will scroll off the top of the
screen. Furthermore, an ANSI terminal will provide the most
effective (and attractive) display, since some ANSI escape-sequences
are used for cursor positioning. In Linux this should be no
problem. In Windows, it is generally necessary to install
ANSI.SYS in order for the command-line interface to accept ANSI
commands. I must admit, though, that in experimenting with
Windows XP I have been unable to get ANSI.SYS to install. (If
somebody wants to send me the magic formula for this, I'd appreciate
it.)
--relative-pixmaps
(Final yaDSKY
version only. Not available in yaDSKY2.)
Alters the locations of the files containing graphics files used by the
yaDSKY program to locations
more congenial to use in VirtualAGC
GUI based installations as opposed to installation in system
directories (the default). The new locations used are the
./pixmaps/yaDSKY/ directory.
yaDSKY and yaAGC attempt to be insensitive to
each other's absence, but I'd recommend running yaAGC first and yaDSKY second, particularly in Win32.
Special Effects for Presentations,
Interactive Demos, etc.
(For related functionality which can be used for automated unattended
operation rather than interactively, it may be possible to use the digital
uplink facility.)
If you should find yourself in the position to give a presentation on
the AGC, the lunar landings, Apollo, etc., using Virtual AGC, versions
of the yaDSKY2 program
20090613 and later
have a "special effects" facility build into it which might be useful
to give your presentation a little more sizzle. Conceivably, this
facility could also be used in setting up an interactive AGC demo, AGC
self-study materials, etc. What the facility
allows you to do is to map selected sequences of DSKY keystrokes to
commands which will be executed on the computer running the
simulation. The only real restrictions are that the key-sequences
used
must begin with the VERB key and cannot contain a second VERB key in
the sequence; also, at most 100 keypad-to-command mappings can be
defined.
This keystroke-to-command mapping is independent of the processing done
by the AGC. In other words, if a certain keystroke pattern is
configured to execute a certain command on the simulating computer, it
will still cause the AGC to
perform whatever action the AGC would normally perform given those
keystrokes.
In order to configure yaDSKY2
to do this, you need to create a file called "DSKY2.matches" in the
Resources/ subfolder of the installation folder. (We discuss this
elsewhere, but for default
installations that folder is "~/VirtualAGC/Resources/" in Linux,
"c:\program files\virtual agc\resources" in Windows, and
"~/Desktop/VirtualAGC.app/Contents/Resources/" in Mac OS X.) This
ASCII file is simply a sequence of lines which begin with the keystroke
pattern being matched, followed by a space, followed by the command
which is supposed to be executed. The command can have spaces or
pathnames in it. The patterns are created from the characters
VN+-0123456789CPKER (capitalization is important!), which correspond to
the DSKY keys in an obvious way (see the following section). The
pattern must begin with V and contain no more than one V, since the
match buffer is cleared whenever the VERB key is pressed. You
can also use the special pattern "startup", in which the associated
command is executed when yaDSKY2
starts up rather than having to be
activated by any particular sequence of keystrokes.
Basically, anything which can be controlled from the computer's
command-line can be controlled by a DSKY key sequence in this
way.
What these things are depends on the operating system, the peripherals
installed on your computer, and the ease of controlling those
peripherals from command-lines (as opposed to GUI controls)—not to
mention your own creativity and computer skills—so I won't bother with
listing any specific commands you might use. But in a general
way, you might:
- Initiate playback of audio clips.
- Initiate playing of a CD or DVD.
- Cause a text window to pop up.
- etc.
For example, suppose that your PC was configured so that it could
control an X10 automation system which could (among other things)
turn off the room lights by executing the command-line command
"LightsOff.bat", and that to begin your presentation you wanted to turn
off the room lights and start a short introductory video; later in the
presentation you want to manually demonstrate some AGC operations, and
you want to trigger some special action when performing a "goto pooh"
operation ("V37E00E"). As mentioned,
the V37E00E command is still processed properly by the AGC and still
causes program P00 to start. For this example, your DSKY2.matches
file might look like this:
startup
LightsOff.bat
startup PlayIntroVideo.bat
V37E00E GotoPoohAction.bat
This example assumes that you are running Windows (since that's the
only place that a ".bat" file is used; on other supported platforms,
the equivalent concept would be a "shell script"). You provide
the batch files yourself, and yaDSKY2
has no understanding at all of what they represent, other than that it
is supposed to execute them. This example needs only a single
keystroke mapping, but if there were additional keystroke mappings, you
would simply add more lines to the
file. Also, while we illustrate this with batch files (shell
scripts), the commands could just as easily be executable programs with
command-line parameters as well.
It's very important to understand that yaDSKY2
has no means of locating the commands referenced by DSKY2.matches other
than the the local rules (such as the PATH environment variable) used
by your system. Furthermore, the setting of PATH isn't
necessarily the same when you are running VirtualAGC by clicking its desktop
icon than it is when you are testing out batch files or shell scripts
from a command line. Therefore, it may be best to specify the
full pathnames of the commands being used rather than just the simple
filenames as shown in the example above. Personally, I place
these command files in the same folder as DSKY2.matches itself, and
specify the names as "./filename"
or ".\filename".
In the future, this facility could be extended in various ways, such as
triggering commands based on the DSKY indicator lamps becoming active,
numerical patterns appearing in the DSKY display registers, adding
commands for initiating digital uplinks, etc. However, it is
unlikely that any of these capabilities will be implemented unless
there are explicit requests for them, so contact me directly if you
have a need for some or all of them.
The Different Parts
of the DSKY
It's important to understand that the various keys and displays of the
DSKY have no intrinsic interpretations of their own. The
interpretations of the keys and displays are entirely dictated by the
software running on the AGC; with different AGC software, different
interpretations might apply. Fortunately, though, the software
was fairly consistent in this regard, and the typical meanings of the
keys and displays are summarized below.
The Keys
Key
|
Description
|
0-9, +, -
|
Self-explanatory, I think.
|
VERB,
NOUN, ENTR
|
"Verbs" and "nouns" were used by
the astronaut to supply commands to the AGC. First a verb would be
entered, then a noun. (For example, verb 37 would indicate that the
astronaut desired the AGC to run a particular sub-program. The noun
would be the requested sub-program number.) In general, the sequence of
steps for keying in a noun/verb pair was: VERB, digit, digit, NOUN,
digit, digit, ENTR.
|
CLR
|
Clears the current data
display. Pressing CLR twice clears two data displays. |
KEY REL
|
This key was pressed by the
astronaut to "release" the DSKY. In other words, to tell the AGC that
he was done with what he was doing and that the AGC could begin
displaying other data on the DSKY, if it desired to do so.
|
PRO or
PROG or
STBY
|
Toggles "standby" mode on or
off. In other words, if in normal operating mode proceeds to
standby mode, but if in standby mode proceeds to normal operating mode.
|
RSET
|
Resets (turns off) the indicator
lamps.
|
In
yaDSKY, you use the mouse
to click the various buttons on the keypad. For
yaDSKY versions
2005-09-20 and later—but
not
in yaDSKY2—thanks to Christian Bucher you can also use the
PC's keys
0
1 2 3 4 5 6 7 8 9 + - v n e
(DSKY keys CLR, KEY REL, PRO, and RSET have no accelerator keys on the
PC's keyboard.) For
yaDSKY2,
alas! these hotkeys presently work only in Mac OS X, and don't work
either in Linux or Windows.
The Displays
Display
|
Description
|
COMP ACTY
|
This lit up when the computer
was busy.
|
PROG
|
The PROG lamp was normally lit.
The two-digit display underneath it showed the program number that was
currently running. The Luminary
and Colossus programs each
provided up to 100 sub-programs for various purposes. The sub-programs
were numbered 00, 01, ..., 99.
|
VERB
|
The VERB lamp was normally lit,
but flashed when the astronaut was supposed to key in a new verb
number. The last verb keyed, or the verb currently being keyed, was
shown on the two-digit display beneath the VERB lamp.
|
NOUN
|
Same idea as the VERB display,
but for nouns instead.
|
Register
1, 2, and 3
|
Three 5-digit displays (plus
sign) showed data that was dependent on the particular sub-program
being run at the time. The numbers were decimal if the plus or minus
sign was lit, but were in octal format otherwise.
|
The Warning or
Indicator Lamps
The DSKY panel had space for up to 14 warning lights in the upper-left
quadrant of its panel. Determining the colors of the indicators
(when lit) is tricky. I've seen a film clip from the Apollo 11
CM, in which all
of the left-hand column is white when lit, and all of the right-hand
column is amber when lit, so I've sort of extrapolated that coloring
scheme for yaDSKY.
Quite a lot of confusion will ensue if you try to determine the legends
of the indicator lamps from the available online materials. The official word, I think, comes from
the Guidance System Operations Plans (GSOP) for the individual
missions. (If you look on my links page,
for example, you'll see the GSOP documents for Colossus 1A rev. 249 and for Luminary 1C rev. 131. Look in
section 4 for detailed descriptions of the DSKYs.) I haven't yet
been able to locate a complete set of GSOP documents (for all of the
missions), but here's what I know right now:
Prior to
Apollo 7?
(CM0.ini)
|
UPLINK
ACTY
|
TEMP
|
AUTO
|
GIMBAL
LOCK
|
HOLD
|
PROG
|
FREE
|
RESTART
|
NO
ATT
|
TRACKER
|
STBY
|
|
KEY REL
|
OPR
ERR
|
|
The image below
(click to enlarge)
is from the GSOP
of the cancelled
AS-278 (1st LM
test mission).
|
CM,
Apollo 7
|
? |
|
CM,
Apollo 8-14
LM, Apollo 9-10
(CM.ini)
|
UPLINK
ACTY
|
TEMP
|
NO
ATT
|
GIMBAL
LOCK
|
STBY
|
PROG
|
KEY
REL
|
RESTART
|
OP
ERR
|
TRACKER
|
|
|
|
LM,
Apollo 11-14
(LM.ini)
|
UPLINK
ACTY
|
TEMP
|
NO
ATT
|
GIMBAL
LOCK
|
STBY
|
PROG
|
KEY
REL
|
RESTART
|
OP
ERR
|
TRACKER
|
|
ALT
|
VEL
|
|
The image below
(click to enlarge)
is taken from the
LM Systems Hand-
book for LM-5
through LM-9.
|
CM,
Apollo 15-17
LM, Apollo 15-16
|
?
|
|
LM,
Apollo 17
(LM1.ini)
|
UPLINK
ACTY
|
TEMP
|
NO
ATT
|
GIMBAL
LOCK
|
STBY
|
PROG
|
KEY
REL
|
RESTART
|
OP
ERR
|
TRACKER
|
NO DAP
|
ALT
|
PRIO DISP
|
VEL
|
|
|
CM,
Apollo-Skylab
|
? |
|
CM,
Apollo-Soyuz
|
? |
|
Legend
|
CM
|
LM
|
LM1
|
CM0
|
Description
|
UPLINK
ACTY
|
×
|
× |
× |
× |
Lit whan data was being
received
from the ground
|
TEMP
|
× |
× |
× |
× |
Lit when the temperature of
the
stable platform containing the sensors for the inertial measurement
unit (IMU) was out of tolerance.
|
NO ATT
|
× |
× |
× |
× |
Lit when the inertial
subsystem
could not provide attitude reference.
|
GIMBAL
LOCK
|
× |
× |
× |
× |
Lit when the middle gimbal
angle
(for the IMU stable platform) was greater than 70 degrees.
|
STBY
|
× |
× |
× |
× |
Lit when the computer system
was
in standby.
|
PROG
|
× |
× |
× |
× |
Lit when the computer was
waiting for operator input.
|
KEY REL
|
× |
× |
× |
× |
Lit when the computer wanted
to
display some information on the DSKY, but was locked out from doing so
because the crew were using the DSKY. The astronaut was supposed to
press the KEY REL key when this light came on, to indicate that he was
done with the DSKY.
|
RESTART
|
× |
× |
× |
× |
Lit while the computer was
restarting.
|
OPR ERR
|
× |
× |
× |
× |
Lit to indicate a data-entry
error by the crew.
|
TRACKER
|
× |
× |
× |
× |
Lit when one of the optical
coupling units failed.
|
NO DAP
|
|
|
× |
|
Lit upon failure of the
digital
autopilot (DAP).
|
PRIO
DISP
|
|
|
× |
|
A "priority display" is
exactly what it sounds like: data which is more urgent than the
data currently being displayed on the DSKY, usually for critical alarm
conditions. Though I'm not sure what happens when a priority
display is needed, it's probably something like this: The
priority-display data automatically replaces what's currently
being displayed, and the PRIO DISP lamp illuminates. When the
astronaut eventually dismisses the priority display, the original data
display returns, and the PRIO DISP lamp goes off. If more than
one priority display wants attention at the same time, it causes a
program alarm 31502.
|
ALT
|
|
× |
× |
|
Lit when the altitude was out
of
range.
|
VEL
|
|
× |
× |
|
Lit when the velocity was out
of
range.
|
AUTO
|
|
|
|
× |
TBD
|
HOLD
|
|
|
|
× |
TBD
|
FREE
|
|
|
|
× |
TBD
|
The Block 1 DSKY
(This section is very preliminary,
and hopefully will be drastically updated as information is uncovered.)
In all of the discussion above, we've been talking about the Block 2
DSKY. The terms "Block 1" and "Block 2" refer to different
generations of the spacecraft. Block 1 was earlier, and was never
actually used on any manned missions because of the Apollo 1 fire;
Apollo 1 would have used a Block 1 spacecraft, but after the fire there
was a long enough delay for the Block 2 spacecraft to become
ready. There was no such thing as a Block 1 Lunar Module.
In spite of its abbreviated history, Block 1 is still interesting
because in comparing Block 1 to Block 2 one can see the evolution of
the design. Of particular interest to us, John
Pultorak's famous AGC replica is a Block 1 AGC rather than a Block
2 AGC, and recreations of John's design are therefore also Block 1 AGCs.
Block 1 DSKYs differed from Block 2 DSKYs. As explained above,
the Command Module had two DSKYs (even though it had only one AGC), one
on the main control panel and one on the navigation side-panel.
The second DSKY was used for entering star or other landmark location
sightings. In a Block 2 CM, the main and nav DSKYs are identical,
and you have seen a number of pictures of them above on this
page. In a Block 1 CM, on the other hand, the main and nav DSKYs
were different.
The picture above is a crummy reproduction (mine!) of Plate 23
(courtesy of Raytheon and Jack Poundstone) in Eldon C. Hall's book, Journey to the Moon: The History of the
Apollo Guidance Computer, which anybody interested in this
website should immediately run out and purchase. (No, I don't
derive any personal benefit from you doing so.) The photo shows
Raytheon's first production DSKYs. On the left is the nav-panel
DSKY, while on the right is the main-panel DSKY. (Actually,
there is some question as to the use of the main-panel DSKY. All
Block 1 drawings I can find agree about the nav-panel DSKY. But
... some drawings show the main-panel DSKY as looking like a Block 2
DSKY while others are similar to the photo above.)
Below are some drawings from a set of Apollo
Guidance and Navigation System training slides, July 1965, which
are perhaps of greater practical utility, if lesser aesthetic
value. If you click the drawing of the nav-panel DSKY (on the
left), you can get a larger view in which the text is actually legible.
Last modified by Ronald Burkey on 2009-08-22.