Contents

• Introduction
• Available Documentation
• Block I Computer System
• Computer
• DSKY
• Uplink
• Downlink
  
• Other Peripherals
  
• Computer Hardware Architecture
• Memory Map
• Registers
• 15 Bits, 16 Bits, Parity, 1's-Complement and Overflow
  
• I/O Channels
• Counters and Timers
• Interrupt Processing
• Software
  
• The Interpreter vs. the CPU's Basic Instruction Set
  
• Source-Code Formatting Information
• Data Representation
• Basic Instruction Representation
• Basic Instruction Set
• Pseudo-Operations
• Interpreter Instruction Set
• Available Block I AGC Software
• Available Supporting Software
• Virtual AGC's Assembler (yaYUL)
• CPU Simulators
• Comparison
  
• John Pultorak's Assembler and Simulator
  
• Virtual AGC's CPU Simulator (yaAGCb1)
• Status of yaAGCb1
  
• Virtual AGC's DSKY Simulator (yaDSKYb1)
• Virtual AGC's Digital Uplink Simulator (yaUplinkBlock1)
  
• Taking Solarium for a Spin

Introduction

The design of the AGC went through several stages, which for the sake of this discussion we'll call "blocks".  However, the different block designs, while similar in many ways, were quite different in others.  Rather than try to cover all of them on this one page, the different blocks are covered in separate pages:

• "Block 0" — Earliest preliminary design of the AGC for which I have any documentation, not used in any missions, and with no known existing code.  There's a single document (that I know of) describing it, so the link is simply to that document, rather than to a separate page.
• "Block I" — Used for the earlier designs of the Command Module, which were also referred to a Block I spacecraft.  Used for the unmanned AS-202 ("Apollo 3"), Apollo 4 and Apollo 6 unmanned missions, and would have been used for the Apollo 1 and Apollo 2 manned missions, if the Apollo 1 tragedy had not precluded those missions.  No missions were ever flown with Block I LM AGCs.
  
• "Block II" — Used for the later designs of the Command Module, which were also referred to a Block II spacecraft.  Used for the (unmanned) Apollo 5 mission's Lunar Module, and for all manned missions, both with an without Lunar Modules.
• "Block 3" — There was no such thing in the Apollo program, but Hugh Blair-Smith has given us some ideas about what it might have looked like if there were.

However, this page confines itself just to the Block I design.

It would be very easy, I think, particularly if you only looked at it very superficially, to dismiss the Block I AGC as a computer that was merely a rebranded but otherwise almost-identical version of the Block II.  But in fact, I think it would be fairer to say that in spite of family resemblances, these are quite-different machines for which somebody went to a lot of difficulty to make the development experiences seem very similar.  Having dealt with both of them at some level of detail, I'll say that using what you know about the one with the other is a quick path to frustration.

Here is a nice little 30-minute documentary in which the Block I AGC and DSKY are demonstrated and various interesting details of their internal construction and manufacture are discussed, by people such as Eldon Hall, Albert Hopkins, and Ramón Alonso, whose names you will see mentioned elsewhere on this page and this site:

Available Documentation

1. R-410:  General Design Characteristics of the Apollo Guidance Computer, by Eldon C. Hall, May 1963.
2. Lots and lots of the official MIT/IL electrical-schematic and mechanical drawings.  I would be lying if I said our engineering-drawing collection is 100% complete, but we have a stunning level of detail on eight different models of the Block I AGC, assuming I haven't miscounted, and on a similar array of Block I DSKYs.  If you could get the components that the engineering drawings use, you could build a working Block I AGC and DSKY from them.
   
3. AC Electronics document ND-1021041 (volume 1 and volume 2).  This is essentially a theory-of-operation document for the Block I AGC and DSKY, and indeed even contains its own set of electrical schematics which often seem to be slightly later revisions than the official MIT/IL drawings mentioned above.
   
4. R-393:  Logical Description for the Apollo Guidance Computer (AGC 4), by Albert Hopkins, Ramon Alonso, and Hugh Blair-Smith, July 1966.
5. FR-2-102A, "Apollo Guidance Computer Information Series, Issue 2: Machine Instructions", 03/10/1963, by Raytheon.
6. FR-2-106A, "Apollo Guidance Computer Information Series, Issue 6: Interpreter and Interpretive Instructions", 09/25/1963, by Raytheon.
7. FR-2-106B, "Apollo Guidance Computer Information Series, Issue 6B: Interpreter and Interpretive Instructions", 05/29/1964, by Raytheon.
8. ... and other of the Apollo Guidance Computer Information Series.
   
9. R-467:  The Compleat Sunrise being a description of Program Sunrise (Sunrise 33 - NASA DWG# 1021102), by R. Battin, R. Crisp, A. Green, T. J. Lawton, C. A. Muntz, J. Rocchio, and E. Smally, September 1964.
10. E-1574: Keyboard and Display System Program for AGC (Program SUNRISE), by Alan I. Green and Joseph J. Rocchio, August 1964.
    
11. John Pultorak's Block I simulator source code.
12. Solarium 055 (Apollo 6 unmanned mission) assembly listing, December 4, 1966.
13. Personal communications by Hugh Blair-Smith.
14. Hugh Blair-Smith's book, Left Brains for the Right Stuff, or as he refers to it, LB4TRS.

Of these, MIT/IL document R-393 is the principle documentation of the Block I computer system — or at least it was prior to obtaining engineering drawings and ND-1021041 as mentioned above — but it is important to recognize that its descriptions are not entirely accurate.  By this I mean not merely that it contains mistakes — as, indeed, any documentation of a sufficiently-complex system will — but that the design of the system was extended after document R-393 was written, so that some of the later-superceded information in it is blatantly wrong to the point of making anything based on it non-functional. The most-glaring discrepancy is the memory map, which R-393 describes as being 1024 words of read/write memory and 12 1024-word banks of read-only memory, whereas there were in fact 24 banks of read-only memory by the time of the Solarium (Apollo 6 unmanned mission) software mentioned above.   In other words, Solarium wouldn't have fit into the amount of memory R-393 describes. 

Finally, it's worth noting that people often seem to believe that the electrical schematics of the Block I AGC are contained in the original PDFs which John Pultorak published of his Block I AGC simulation.  While those are fine schematics, and worked well for John's purposes, they are not transcriptions of the original Block I schematics, but are rather schematics John designed from scratch, based on the textual descriptions he found in R-393.  In the first of his PDFs, there is a detailed diary of what he did, and everything in it refers back to R-393, but not to the original schematic diagrams of the Block I, which were not available to him.  Thus, while John's work on reverse engineering the Block I AGC essentially from R-393 alone is a stunning tour de force — after all, his gadget ended up working! — his schematics may or may not be valuable resources for you, depending on your purposes.

Block I Computer System

Computer

The Block I AGC was provided in two different configurations, one for the Command Module (then referenced as the C/M), and one for the Lunar Module (at that time still called the LEM, or Lunar Excursion Module).  Even though personally still bummed out (fifty years later) over the change from LEM to LM, for consistency I'll refer to the spacecraft here as the CM and LM and forego the temptation to instead talk about the LEM.

The physical configurations of these were different in terms of form factor, weight, and memory capacity — and of course, software — and here are the highlights:

• CM Block I AGC:
• about 2 cubic feet
• about 110 pounds
• 24,576 words of "fixed" memory (i.e., read-only memory).
• Controls two DSKYs, one for the main control panel, and one for the navigational bay.
  
• LM Block I AGC:
• about 0.9 cubic feet
• about 50 pounds
• 12,288 words of "fixed" memory (i.e., read-only memory).
• Controls one DSKY.
  
• Common:
• Power:  180 watts active, 10 watts idle.
  
• Fixed memory comprised 16-bit "words", each consisting of 15 bits available for data, and 1 parity bit, all consisting of cores, made of the magnetic alloy called Permalloy, and sewn together into a "rope".
  
• 1024 words of "erasable" memory (i.e., read-write memory), based on ferrite cores.
• 1's-complement arithmetic, plus overflow.
• Memory cycle time (MCT): 11.7 μs.

Of course, that's merely the summary.  If you really wanted full details of what the Block I AGC was like, then you'd have to narrow your focus to just the specific mission you were interested in and consult the engineering drawings themselves.  In fact, here are some links to those engineering drawings for the Block I (unmanned) missions flown:

• AS-202 ("Apollo 3") CM AGC
  
• Apollo 4 CM AGC
• Apollo 6 CM AGC
  

That's not to say that those were the only versions of the Block I AGC, and there were plenty more that never went on a flown mission!  On the other hand, also not intended to imply that all of these models were very different.  They were, after all, completely compatible in terms of the software they could run.

No Block I LM missions ever flown, and I'm not aware of any Block I LM software, so I can't comment on whether the LM Block I AGC requirements listed above are accurate.

DSKY

   

• AS-202 ("Apollo 3") CM:
• Main DSKY
• Nav DSKY
• Apollo 4 and Apollo 6
  
• Main DSKY
• Nav DSKY ... we don't actually have the specific top-level drawing for this one, but here's the closest match in our drawing collection.
  

• Solarium 055 also seems to use the relay word 014, which isn't known to correspond to anything in this scheme.
  

Uplink

The digital uplink was simply a way to have a remote keypad on the ground, which could transmit keystrokes via radio to the AGC aboard the spacecraft as if it were a DSKY.  In other words, the only data the uplink could transmit corresponded to DSKY keypad codes.  The keycodes were identical to the 5-bit DSKY keycodes as described in the preceding section, but if (say) a 5-bit keycode of bits B5 B4 B3 B2 B1 were to be transmitted, they were supposed to be packaged into the following 16-bit format for the uplink:

1 B5 B4 B3 B2 B1 B5 B4 B3 B2 B1 B5 B4 B3 B2 B1

Downlink

TBD

Other Peripherals

What the MIT Instrumentation Laboratory designed and provided for the Block I Command Module included not merely the AGC and its DSKYs, but rather than entire Guidance & Navigation (G&N) systems for the Command Module.  The G&N system consisted of quite a few additional components, of which some of the more important were:

• The Inertial Measurement Unit (IMU)
• The Scanning Telescope (SCT)
• The Sextant (SXT)
• The Coupling Display Units (CDU)
• etc.

In some sense, the IMU is the most important of all, more so than the AGC and DSKY, since (I believe) the IMU was what Doc Draper originally developed and attempted to hawk to the military, and was the Instrumentation Lab's entrée into Apollo in the first place.  The IMU existed long before the AGC was even a gleam any any designer's eye.  The AGC and DSKY, from that point of view, were just a way of interacting with the IMU, and without the IMU there really wasn't much of an excuse for MIT/IL to be involved in Apollo at all.  But since our focus here is really just the AGC and DSKY, I won't really be covering these other very-important "peripheral" components at all.

Nevertheless, if you want to know about them we do still have quite a collection of documents and engineering drawings covering the entire G&N system.  Here's a portal into electrical and mechanical engineering drawings for the flown versions of the Block I G&N system:

• AS-202 ("Apollo 3") G&N system
• Apollo 4 G&N system
• Apollo 6 G&N system
  

Computer Hardware Architecture

Memory Map

• Addresses 00000-01777 — erasable memory.
• Addresses 02000-03777 (or theoretically, 01,06000-01,07777) — Bank 1 of fixed memory.
• Addresses 04000-05777 (or theoretically, 02,06000-02,07777) — Bank 2 of fixed memory.
• Addresses 03,06000-03,07777 — Bank 3 of fixed memory.
• ...
• Addresses 14,06000-14,07777 — Bank 14 of fixed memory.
• Though logically present as far as software is concerned, banks 15, 16, 17, and 20 are not physically present in the hardware.
  
• Addresses 21,06000-21,07777 —Bank 20 of fixed memory.
• ...
  
• Addresses 034,06000-034,07777 — Bank 34 of fixed memory.
  

BB,AAAA

15 Bits, 16 Bits, Parity, 1's-Complement, and Overflow

The information in this section should not differ from equivalent information for Block II, so if you are confident you understand that, then there's no reason to read it.  However, it is not merely cut-and-pasted from corresponding Block II descriptive material, and so may (or may not) be useful in itself.

Almost all AGC memory words consist of 16 bits, of which 15 bits is "data", and a 16th bit is a parity bit that the AGC hardware can access for the purpose of testing for corruption.  If you were to build an AGC or to create a hardware simulation of an AGC, that parity bit would be an important thing to understand and account for, since parity violations are detectable by hardware, cause alarm indicators to trigger, and so on.

On the other hand, my own preoccupation in this site, in so far as Block I is concerned, is making Solarium and other Block I programs available within a software simulation of the AGC.  Parity is completely irrelevant to that usage, because such an environment is not an embedded one, and parity is just a confusing distraction ... so I don't care about parity, my software simulation doesn't care about parity, and I won't mention parity again.  As one of the original AGC developers commented to me, "parity schmarity", and I think that about sums it up.  Consequently when I talk about AGC memory, it will almost always be in terms of 15-bit words.

But there are some exceptions.  Certain reserved memory locations, which aren't always (strictly speaking) contained in erasable memory even though addressed as such, consist of 16 bits, but  the 16th bit is not parity; rather, it is an indication of "overflow".  The principal example of such a privileged location is the "accumulator register", A, discussed in the next section.  That's because all results of most kinds of arithmetical operations are deposited directly into the accumulator, and if an operation such addition has overflowed, that will first be manifested in the accumulator.  Various subsequent operations on that data will behave differently depending on whether or not (or how) overflow is manifested within the accumulator.  There are also hidden registers, not addressable by software, and overflow within those registers may have significant implications just like overflow in the accumulator does.

I have been chided for liking to think of "overflow" is if it were a condition that has occurred, such as "the accumulator has wrapped around from positive to negative" and thus overflowed, or "the accumulator has wrapped around from negative to positive".  That's a poor way to think about overflow in this architecture, for a couple of reasons:

1. Arithmetical overflow does not "wrap around", in the sense of changing sign, because the AGC employs 1's-complement arithmetic rather than 2's-complement arithmetic.  Wrap-around with sign-change is a characteristic of 2's-complement arithmetic.  However, with 1's complement, overflow does not work that way.  If, say, you add 1 to the largest possible positive number, it will indeed wrap around, but it will wrap around to +0 and not to a negative value.
2. Overflow is not an instantaneous condition that disappears, but rather is encoded within the 16-bit value, and continues to be manifested there until some operation occurs which converts the value back to a 15-bit one incapable of retaining the overflow information.

Before getting to the exact encoding of overflow information, though, let's briefly talk about the 1's-complement representation of numbers.  Consider a 15-bit number with bits B15 B14 ... B1.  This representation can store 2¹⁴-1=16383 distinct positive numbers (1 through 16383), and 2¹⁴-1=16383 distinct negative numbers (-1 through -16383).  Zero actually has two distinct representations, +0 and -0, which act the same for some purposes and differently for others.  In other words, +0 and -0 are not completely interchangeable with each other.  The positive numbers are encoded the same way they would be in 2's-complement:

0 (decimal) = 000 000 000 000 000 (binary)
1 (decimal) = 000 000 000 000 001 (binary)
2 (decimal) = 000 000 000 000 010 (binary)
3 (decimal) = 000 000 000 000 011 (binary)
4 (decimal) = 000 000 000 000 100 (binary)
...
16383 (decimal) = 111 111 111 111 111 (binary)

12345 (decimal) = 011 000 000 111 001 (binary)

so

-12345 = 011 000 000 111 001 = 100 111 111 000 110

Now, in 1's-complement there is no "sign bit" as such.  In other words you can't turn (say) 3 into -3 or vice-versa by just flipping one bit.  Nevertheless, in the examples above, the most-significant bit, bit 15, does indicate the sign, and therefore you can tell whether a number is positive or negative by testing bit 15.  For that reason, bit 15 is sometimes called the "sign bit" and is sometimes designated by the special symbol

SG = bit 15 = "sign bit"

For those special 16-bit memory locations, like the accumulator, a regular, non-overflowed number will have its 16th bit identical to its 15th bit.  It also has a special designation:

UC = bit 16 = "uncorrected sign bit".

In other words, for numbers without overflow, SG = UC (=0 if positive or =1 if negative).  For numbers with overflow, though, this is not the case.  There are two possibilities for numbers with overflow:

• "Positive overflow":  UC = 0 and SG = 1.
• "Negative overflow": UC = 1 and SG = 0.

The tricky aspect here is that when overflow exists, it is UC that is regarded as the "real" sign of the number, and not UC.  When the 16-bit form of a number (say, in the accumulator) needs to be converted to a normal 15-bit number (say, to be stored at a location in erasable memory), what happens is that the UC bit steps in and kicks the SG bit out of the way:

UC SG B14 ... B1 (16 bits)  →  UC B14 ... B1 (15 bits)

Let's consider an example of this in action.  Imagine we want to increment the largest possible positive number, 037777, by 1.  Start by just using the same old binary arithmetic you're familiar with, without worrying about "1's-complement" vs "2's-complement" or overflow:

0 011 111 111 111 111 + 0 000 000 000 000 001  →  0 100 000 000 000 000

Having done that, though, we now have overflow, and specifically "positive overflow", since UC = 0 and SG = 1 do not agree with each other.  And if we were to save this as a 15-bit number, UC = 0 would shift down to overwrite the SG = 1, and we'd simply have 000 000 000 000 000, or just 0.

Registers

• A (address 0000) — the "accumulator", at address 0 in erasable, though normally accessed by it's name, "A". This register is the primary source or destination for most operations, and in particular, is where the results of most arithmetical operations are deposited.
• Q (address 0001) — primarily used to hold the return addresses for subroutines. It is automatically written to by the TC command when a jump is made to a different memory location. There is no hardware stack, so the subroutine has the responsibility of saving the contents of Q and restoring it before returning to the calling program, if appropriate.
• Z (address 0002) — pointer to the next instruction to be executed in the normal flow (i.e., barring a jump instruction like TC or CCS or an interrupt) after the current instruction is completed. The Z register is already set up with this value by the previously-executed instruction, before the current program counter is reached. (Note, though, that when using the yaAGCb1 CPU simulator program in their debugging mode, the value displayed is always for the current instruction rather than for the next one, since I find it more instructive that way.) Though the register is 16 bits, in theory, this pointer is just 12 bits (0000-7777), and the full address, if in banked memory, is formed by adding in the value stored in the Bank register.
• LP (address 0003) — principally for holding results of MP or DV operations, but do not make the mistake of equating it with the Block II's L register.  It's not very useful for much else (a point on which I'm open to correction) because it's an example of something called an "editing register", of which the other examples (described below) are CYR, SR, CYL, and SL.  What that means is that when you try to store a value in this register, using an assembly-language instruction such as TS, it is not stored as-is, but is instead "edited" in a particular way.  Furthermore, various assembly-language instructions which seemingly only read this register, will in fact rewrite the register, causing the editing operation to be re-performed in-place.  There is a table (3-2) in R-393 that defines the various editing operations that are performed on this select cadre of registers, but it's perhaps a bit hard to figure out for the uninitiated.  The specific editing operation performed by LP is as follows:  If you try to write a set of bits like B15 B14 B13 ... B2 B1 to LP, it will in fact be written as B1 0 B14 B13 ... B1.  Thus, the most-significant original bit B15 is discarded, and then what's left over is shifted downward, wrapping the old least-significant bit into the new most-significant position.

There's also a variety of 15-bit registers:

• Bank (address 015): When fixed memory having addresses of the form BB,OOOO (i.e., bank,offset), only the offset (OOOO) is supplied by the instruction operands.  (Yes, those are all upper-case letters Oh and not zeroes.)  The bank (BB) comes instead from the Bank register.  Only bits B15 B14 B13 B12 B11 of this register are used, and so all of the lower-order bits of the register are zero.  Perhaps confusingly, when the contents of this register are discussed, they are usually discussed as if they were the same as BB: i.e., that the register contains values in the range 0-037; in reality, it contains that range of values, but shifted upward by 12 binary places.  Consequently, there are tricks that have to be used to effectively store a bank number in the Bank register, and those tricks are discussed later when the instruction set is covered.
• CYR (address 020), SR (address 021), CYL (address 022), SL (address 023):  These are "editing registers", like LP as discussed earlier, which automatically modify values explicitly stored to them, or implicitly rewritten to them as side-effects of various instructions.  Table 3-2 of R-393 covers the editing operation with is performed for each of these, but frankly it is very confusing.  It is best to think of it as follows:
• CYR:  "Rotates" the value to the right.  I.e., shifts the (15-bit) value downward by one bit position, and cycles the least-significant bit back upward into the most-significant position.
  
• SR:  Shifts the 15-bit value downward, duplicating the most-significant bit.  In other words, it is a signed divide-by-two operation.
  
• CYL:  "Rotates" the value to the left.  I.e., shifts the (15-bit) value upward  by one bit position, and cycles the most-significant bit back downward  into the least-significant position.
• SL:  Shifts the 15-bit value upward.  In other words, it is a multiply-by-two.
• QRUPT (address 027), ZRUPT (address 024), BRUPT (address 025):  When an interrupt is processed, the existing values of the Q, Z, and B registers are automatically copied into these registers.  B is a hidden register, not addressable by software, and hence was not discussed with the registers already mentioned, however, it has the important role of holding the numerical value (as opposed to the address) of the next instruction to be executed after resumption from the interrupt-processing.
  
• ARUPT (address 026), BANKRUPT (address 030), OVRUPT (address 031), LPRUPT (address 032), DSRUPTSW (address 033):  These registers are available for storing the values of other registers during interrupt processing.  However, that storage isn't done automatically, and (if desired) has to be done explicitly by the interrupt-service routine itself.  In short, these are just regular erasable-memory locations like any other, that just happen to have names that hint at an appropriate use for them.
  

I/O Channels

• IN0 (address 0004): This register is used principally to receive keyboard input from the DSKY, with the following bit assignments:
• B1-B5 contains a keycode, if a keypad key is pressed, as follows.  Note that not all codes are used:
• 00 (octal) for "no key pressed".
• 20 (octal) for the digit 0.
• 01-11 (octal) for the digits 0-9.
• 21 for the VERB key.
• 22 for the ERROR RESET key.
• 31 for the KEY RLSE key.
• 32 for the + key.
• 33 for the - key.
• 34 for the ENTER key.
• 36 for the CLEAR key.
• 37 for the NOUN key.
• B6 is set when any of the B1-B5 or B15 is active, and is what triggers a "KEYRUPT" (keypad interrupt).  It is perhaps worth noting that the KEYRUPT software expects for the entire lower 6 bits, B6-B1 (and not just B6) to return to zero after the pushbutton is released, and will refuse to process additional keystrokes until this occurs.
  
• B7-B13 are not used.
• B14 is active when the AGC can be put into partially-powered-down "standby mode", and is, I believe, connected to a control-panel switch that's not on the DSKY.
• B15 is active when the MARK key, not on the DSKY itself, is pressed, and activates B6 just like the DSKY-keypad keys do. It is used to cause the AGC to "mark" the current IMU data ... i.e., to snapshot it in memory.
• IN1 (address 0005):
  
• B1: 1600 pps
• B2: 800 pps
• B3: 400 pps
• B4: 200 pps
• B5: OR C1, 2, 3, 4, 10 (IMU relay drivers)
  
• B6: OR C5, 6, 7, 8, 9 (S/C alarm lights)
• B7: OR C11, 12 (OP relay drivers)
• B8-10: not used
• B11: PARITY alarm.  Any of bits B11-B15 (i.e., their logical OR) generate an error interrupt (ERUPT).
  
• B12: CROSSPOINT FAIL alarm
• B13: SR INACTIVE (GO) alarm
• B14: RUPTLOCK (GO) alarm
• B15: TCA Trap (GO) alarm
  
• IN2 (address 0006):
• B1: OR CDU Zero
• B2: OR SXT Zero
• B3: OR TRACKER Zero
• B4: Photocell -
• B5: Photocell +
• B6-7: Not used
• B8: Tracker Fail (RUPT)
• B9: OPTICS Fail (RUPT2)
• B10: CDU Fail (RUPT2)
• B11: ACCEL Fail (RUPT2)
• B12: IMU Fail (RUPT2)
• B13: ABORT (RUPT2)
• B14: BAD BOOST (RUPT2)
• B15: AGC Power Fail (RUPT2)
• IN3 (address 0007):
  
• B1: K1 Zero CDU SW
• B2: K2
• B3: K3
• B4: K4
• B5: ATTSW
• B6: TRNSW
• B7: ZERO OPT
• B8: MODE SELECT OPT
• B9: MODE SELECT OPT
• B10: MODE SELECT OPT
• B11-12: Not used.
• B13: MODE SELECT S/C
• B14: MODE SELECT S/C
• B15: Lift-off
  
• OUT0 (address 0010):  These are outputs from the AGC to the DSKY.  Each 15-bit word is of the following format, as a bit-pattern (with the B15 to the left and B1 to the right):  WWWWSAAAAABBBBB.  The field WWWW specifies one out potentially 16 distinct sets of 11 relays in the DSKY, and the fields SAAAAABBBBB are latched into those sets of relays when this value appears.  The behavior of these patterns is quite simple, but is too complex to fix into this one bullet point, so I will describe the behavior of OUT0 in more detail at the end of this bullet list below.
  
• OUT1 (address 0011).  Note that the bits of this register do not, in fact conform entirely to any of the available written documents.
  
• B1:  PROG alarm on LM DSKY
  
• B2:  COMP FAIL and alarm on DSKY
  
• B3:  KEY RLSE indicator on LM DSKY
  
• B4:  SCALER FAIL or TM FAIL (not sure which) alarm on LM DSKY
  
• B5:  CHECK FAIL alarm on DSKY
  
• B6:  Block UPLINK
  
• B7:  ERRUPT trap
  
• B8:  Slow speed, STANDBY
  
• B9:  Word Order Telem
  
• B10:  Block Endpulse
  
• B11:  PIPA SCALE FINE
  
• B12:  PIPA SCALE EMERG
  
• B13:  ENG START
  
• B14:  START CLOCK
  
• B15:  ENG OUT-OFF
  
• OUT2 (address 0012):  This output-register is dedicated to generating pulses for driving peripherals such as the CDUs, and the various bit-fields are described in some detail in the "METHOD FOR GENERATING OUTPUT RATES" section in R-393.
• B1:  OPT X
  
• B2:  OPT Y
  
• B3:  THRUST (RATE II)
  
• B4:  +
  
• B5:  -
  
• B6-7:  Not used
  
• B8:  GYR X
  
• B9:  GYR Y
  
• B10:  GYR Z
  
• B11:  CDU X (RATE I)
  
• B12:  CDU Y
  
• B13:  CDU Z
  
• B14:  +
  
• B15:  -
• OUT3 (address 0013):  Not used.
  
• OUT4 (address 0014):  This is a 16-it register, in which a word to be DOWNLINK'd is placed.  The 16th bit is the parity.
  

                               PROGRAM
                             [MD1] [MD2]

    VERB                         NOUN
[VD1] [VD2]                  [ND1] [ND2]

               REGISTER 1
[R1S] [R1D1] [R1D2] [R1D3] [R1D4] [R1D5]

               REGISTER 2
[R2S] [R2D1] [R2D2] [R2D3] [R2D4] [R2D5]

               REGISTER 3
[R3S] [R3D1] [R3D2] [R3D3] [R3D4] [R3D5]

• WWWW=000:  0 is the normal state of the OUT0 register when no new DSKY activity is currently being commanded, and the register is returned to this state by T4RUPT every few tens of milliseconds.
• WWWW=014:  In Solarium, this relay-word is created by the CDRVE function, which program comments indicate as pertaining to "SPACECRAFT RELAYS".  TBD.
• WWWW=015:  In Solarium, this relay-word is created by the CDRVE1 function, which program comments indicate as pertaining to "IMU AND CAUTION LIGHTS".  TBD.
• WWWW=016:  In Solarium, this relay-word is created by the CDRVE2 function, which program comments indicate as pertaining to "OPTICS".  TBD. 
• WWWW=017:  017, while a theoretically-possible value for the register, cannot be created by the AGC software (at least not in Solarium). 

Counters and Timers

Counter/timer registers are registers in erasable memory which are automatically incremented or decremented by specific actions of the hardware, independent of the operation of the software.  Thus, the software may (in some cases) usefully load an initial value into them, but for the most part just polls the contents of these registers when it needs to do so.  In some cases too, an overflow of one of these registers may trigger an interrupt.

• OVCTR (address 034):  This counter is incremented every time an addition or subtraction operation (i.e., AD or SU) creates positive overflow in the accumulator register.  Conversely, it is decremented every time an addition or subtraction creates a negative overflow.  However, just the existence of overflow outside of that context has no effect.
  
• TIME2 (address 035):  This 14-bit counter increments every time TIME1 (see below) wraps from 037777 to 0; this occurs every 163.84 seconds.  TIME2 and TIME1 together form a single 28-bit timer counting the number of 10 ms intervals that have elapsed since power-up, and will itself wrap around to zero after just over 31 days ... comfortably longer than any possible Apollo mission.
  
• TIME1 (address 036):  This 14-bit counter increments every 10 ms.  It will wrap around from 037777 to 0 every 163.84 seconds.
  
• TIME3 (address 037):  This 14-bit counter increments every 10 ms, and triggers a T3RUPT interrupt when it counts past its maximum value of 037777.  However, it is pre-loaded via software to maintain a nominal interrupt rate of TBD.  It is used for managing the "waitlist", which is part of the multi-tasking capability of the system.
  
• TIME4 (address 040):  This 14-bit timer increments every 10 ms, and triggers a T4RUPT interrupt when it counts past its maximum value of 037777.  It is generally pre-loaded by software in a such a way as to do this every 60 ms, although sometimes that interval is split into a 20 ms interval followed by a 40 ms interval.  The section entitled "T4RUPT OUTPUT CONTROL" in R-467 covers the functionality of the T4RUPT in some detail, but in brief, it handles all sorts of time-sensitive i/o other than the DSKY.
  
• UPLINK (address 041):  This 16-bit shift-register receives the data stream of digital-uplink data, as described earlier.  It is included in this section because it is implemented in hardware similar to a counter register, although the software simulation simply treats it as any other 15-bit input register.  (The reason for the discrepancy between 16-bit and 15-bit here is that the 16th bit, which is physically the first one transmitted, is simply a "start bit" used for synchronization purposes, and carries no data accessible to the software.)
  
• OUTCR1 (address 042), OUTCR2 (address 043):  Used for counting the logical OR of all the set pulses to the CDUs and gyros.  See the "METHOD FOR GENERATING OUTPUT RATES" section in R-393.
  
• PIPAX (address 044), PIPAY (address 045), PIPAZ (address 046), CDUX (address 047), CDUY (address 050), CDUZ (address 051):  Used for capturing accelerometer (PIPA) and angular (CDU) data from the IMU, by means of PINC and MINC unprogrammed sequences, I believe.
  
• OPTX (address 052), OPTY (address 053), TRKRX (address 054), TRKRY (address 055), TRKRR (address 056):  Used for locating fixes from the sextant, by means of PINC and MINC unprogrammed sequences, I believe.
  

Interrupt Processing

• T3RUPT (address 02000) — T3RUPTs are triggered when CPU TIMER3 overflows. This is used for servicing the WAITLIST ... i.e., for managing multi-tasking.
• ERRUPT (address 02004) — ERRUPTs are triggered upon various error conditions reported by hardware, and specifically upon any of the bits B8-B15 in input register IN2 becoming active.
• T4RUPT (address 02010) — triggered when CPU TIMER4 overflows. This is used for servicing outputs to the DSKY.
• KEYRUPT (address 02014) — triggered when bit B6 in input register IN0 becomes active ... i.e., when a DSKY key (or the MARK key) is pressed.
• UPRUPT (address 02020) — for servicing uplink data, which is in the same form as (and treated the same way as) DSKY keystrokes.
• DOWNRUPT (address 02024) — for servicing the digital downlink (the telemetry data).
• Address 02030 — the power-up entry-point of the software.

• Interrupts can be explicitly disabled using the assembly-language instruction INHINT, and remain disabled until a subsequent RELINT instruction is encountered.
• Interrupts are inhibited if there is overflow in the A register, because there is no way to store and restored overflow during the interrupt.
• Interrupts are inhibited if there is overflow in the hidden B register. This condition occurs if the next instruction that would have been executed is an MP, DV, or SU, and relates to the fact that the opcodes for these instructions are otherwise identical to other instructions, and the only way to distinguish them is if this overflow condition can be checked.

Software

The Interpreter vs. the CPU's Basic Instruction Set

Source-Code Formatting Information

• A source-code file is an ASCII (text) file, consisting of a series of lines.
  
• Blank lines are ignored.
• The character '#' is used to begin comments. Everything on a source line following the '#' symbol is discarded. (In the original YUL, the source code was on punch cards, with one line of code per card. I believe that the entire card was a comment if a certain non-blank character appeared in column 1. I'm not certain how comments at the end of a line of source code were recognized; they were either column-dependent, or else the parser simply gave up after all valid fields had been parsed. In any case, yaYUL does not support any of the original YUL's specific commenting methods.)
• If the character '$' is encountered in column 1 of a line, then the line contains the name of a source file which is to be inserted at that point. For example, if "$INTERRUPT_LEAD_INS.agc" is encountered in column 1, then yaYUL will process all of the file INTERRUPT_LEAD_INS.agc before proceeding to process the remainder of the original source file. (The original YUL had no such source-code directive, since it did not process "files".)
  
• Programmer-defined names (such as program labels and constants being defined) begin in column 1. They are 8 characters or less in size, and may contain any character except '#', and may not begin with the character '$'. (For example, "-1/(D)+A" would be a legal constant name or program label.)
• A typical arrangement of items on a line of assembly-code would be this: optional program label, followed by an AGC opcode or interpreter instruction, followed by an operand for the opcode, followed by an optional comment. In some cases, additional option fields may appear between the operand and the comment. All fields are separated by whitespace, except that no space needs to precede the '#' delimiter for a comment.  Stylistically, my preference is for the opcode or interpreter instruction to begin at the second tab stop, the operand (if any) at the third tab stop, options to the operand are separated by spaces, and the comment (if any) to begin at the fifth tab stop, assuming that tab stops are 8 characters apart.
  
• In some cases, a line may have no program label but may have a field such as "-1", "+1", "+110", etc., preceding the opcode. These notations appear to serve merely as comments, and are simply ignored by yaYUL. These notations cannot begin in column 1, or else they would be taken for program labels.  Stylistically, I prefer that these notations begin at the first tab stop.
• There is two column-based dependences, which must be observed: 
  
1. The assembly language operator or pseudo-op, or the first interpreter command on a line, must begin at the 17th column, and will not be recognized as a an operator, pseudo-op, or command otherwise.  Tab stops are assumed by the assembler to advance by multiples of 8 columns, so the 17th column is the one after 16 non-tab characters, or two tab characters, or any of the usual combinations of non-tab characters and tab characters you would expect.
2. Sometimes, a '-' character appears in the 16th column, i.e., the character preceding the assembly-language operator if there is one.  The is a directive to logically-complement the output binary at that location, and is not recognized at any other column position.
   

Data Representation

Numerical formats are identical to those for the Block II AGC, and I advise you to read the description of them that appears in the Block II discussion.

Basic Instruction Representation

Basic Instruction Set 

In reading about the effects of the various "basic" instructions below, there are several notational conveniences that you should be aware of:

• An MCT is a "machine cycle time", and is 12/1024000 seconds long, or about 11.7 μs.
• The location of the current instruction is generally referred to as L, so the instruction following the current instruction is L+1, the instruction following that is L+2, and so on.
  
• C(x) refers to the contents of location x, which will often be the accumulator, C(A), or of the operand, C(K).
• On those rare occasions when it is necessary to distinguish between the "before" and "after" contents of a location, C(x) will be the "after", and b(x) will denote the "before".

As for why it may be necessary to distinguish "before" from "after", one reason is the so-called "editing registers" discussed earlier, namely LP, CYR, SR, CYL, and SL.  Recall that when you write to such a register, what's saved in the register isn't the value you're theoretically writing to it, but rather an "edited" form of that value.  For example, with CYL this editing process is to rotate all the bits to the left.  Some instructions have as a side effect re-writing the operand, denoted (if the operand is K) by

C(K) = b(K)

Thus even though a given instruction is seemingly using its operand as input rather than for output, if the operand is an editing register, it may be automatically rewritten, and that means it will be re-edited every time the instruction is used.

A couple of points about the Block I basic instruction set that may not be obvious at first glance are:

• There is no instruction for loading the accumulator from erasable memory, though there is one for loading the accumulator from fixed memory (namely CAF).  There are several workarounds, but one which guarantees no side-effects, unless K is an editing register, is "CS K" (C(A) = -C(K)) followed by "COM" (C(A) = -C(A)).
• There is no instruction without side-effects for saving the accumulator to erasable memory.  The TS instruction is almost always used for this but can have an unwanted side-effect which must be guarded against, if the accumulator contains overflow.
  

AD

CAF

CCS

COM

CS

DOUBLE

DV

EXTEND

INDEX

INHINT

MASK

MP

NOOP

OVIND

OVSK

RELINT

RESUME

RETURN

SQUARE

SU

TCAA

TC or TCR

TS

XAQ

XCH

Pseudo-Operations

The pseudo-ops are a subset of those in Block II.  Actually, yaYUL supports the identical pseudo-ops for Block I as it does for Block II, but some of those pseudo-ops simply make no sense for Block I and therefore will never appear in actual code.  I know I should have yaYUL exclude the nonsensical pseudo-ops, but I have no present intention of doing so.  See the Block II description.

Interpreter Instruction Set

Source Code and Encoding

# Pattern 1:
OPERATOR
            OPERAND₁
            .
            .
            .
            OPERAND_N

# Pattern 2:
OPERATOR_A   OPERATOR_B
            OPERAND₁
            .
            .
            .
            OPERAND_N

# Pattern 3:
OPERATOR₀   M
OPERATOR_1A  OPERATOR_1B
.
.
.          
OPERATOR_MA  OPERATOR_MB
            OPERAND₁
            .
            .
            .
            OPERAND_N


# Pattern 4:
OPERATOR₀   M
OPERATOR_1A  OPERATOR_1B
.
.
.          
OPERATOR_M
            OPERAND₁
            .
            .
            .
            OPERAND_N

Control-Pulse Sequences

As has been explained above, the Block I AGC's "basic instructions" (i.e., the assembly-language instructions as opposed to interpretive instruction) mostly require 2 machine cycle times (MCTs) to executed, although the TS instruction usually takes only 1 MCT, and others like MP or DV take considerably more.  One MCT requires about 11.7 μs, or more-precisely, 12/1.024 = 11.71875  μs (plus or minus whatever the clock tolerance is, of course).

That is the viewpoint from the abstraction level of "basic instructions", and is the world-view enforced by our Block I CPU simulator, but does not represent the underlying physical reality of hardware AGC.  From the physical standpoint:

• The CPU operates at a 1.024 MHz clock rate.
• During each clock period (which for the sake of discussion we'll call an SCL), from 0 to 5 "control pulses" can execute simultaneously and independently of each other.  These "control pulses" are essentially microcode instructions that operate on a set of hidden registers, mostly not addressable directly by basic instructions, and are of many types:  many more types than there are basic instructions.
• The basic instructions are simply abstractions consisting of 12 or 24 (or some other multiple of 12) sets of 0-5 control pulses each.

The sequence of control pulses corresponding to a basic instruction is, of course, its "control-pulse sequence".  In theory, any question about the ultimate behavior of any given basic instruction can be answered by analyzing its control-pulse sequence closely enough, although this can be quite a challenging proposition, particularly for complex instructions like MP or DV.  For example, when the DV instruction was defined earlier, certain constraints were placed on the dividend vs the divisor, and if those constraints weren't satisfied, we merely stated that the results were undefined.  However, they're not undefined, and you can find out what the result should be if you analyze the control-pulse sequences.  However, CPU simulator does not do that, and you cannot expect agreement with the physical AGC in those cases.  Of course, the danger is that original AGC developers could have used their inside knowledge of what should have happened, rather than abide by the documented constraints, and hard-coded that tribal knowledge into a program like Solarium.  Well, if they did, then it will make me sad.

Control-pulse sequences are used for more than just basic instructions, however.  All manner of auxiliary operations are coded as control-pulse sequences, and thus occupy CPU time when they occur.  These include:

• Vectoring to interrupts.
• Shifting in digital-uplink data.
• Incrementing timer registers.
• Incrementing or decrementing counter registers.
  

My focus in this project is to provide useful software simulation of the AGC and so, while I consider simulation of the control-pulse sequences to be the technically "correct" way of creating such a simulation, I also believe that reaching the point of having a satisfactory practical understanding of control-pulse sequences has a far-steeper learning curve than obtaining a practical understanding of basic AGC assembly-language programming.  Moreover, programming the basic instructions much have been what AGC developers did 99% of the time, with teasing out control-pulse sequences (or asking an on-site expert about them) must have represented very little of their time.  So from that standpoint, I consider simulating the basic instructions themselves, and ignoring control-pulse sequences, to be the "correct" overall approach.  Your opinion may, of course differ.  Plus, it never occurred to me to do it that way.

The only knowledge of control-pulse sequences you need in order to follow the remainder of the discussion on the present page is that the control-pulse sequence that increments a CPU counter register is called a PINC, and one which decrements it is called a MINC.

If you do want to find out more about control-pulse sequences in the Block I AGC, the discussion of them (intermixed with discussion of basic instructions) is spread throughout Chapter 3 of R-393.

Available Block I AGC Software

This has been written up in more detail on our Colossus page, which is where I advise you to look if you want more information.  But in summary, what's available to us in the way of true Block I for the AGC is the following:

• Trivium — A short sample program that simply demonstrated how to use the original assembler, YUL.
• Sunrise 45 — The program used for Block I system tests.
• Sunrise 69 — The program later used for Block I system tests.
• Corona 261 — Flight software for the unmanned AS-202 mission.
  
• Solarium 55 — Flight software for the unmanned Apollo 4 and 6 missions.

What has me pulling out what's left of my hair is the absence of Sunspot 247, the flight software for Apollo 1.  (If you have it, give it to me!)

See also the section on John Pultorak's assembler and simulator.

Available Supporting Software

Virtual AGC's Assembler (yaYUL)

CPU Simulators

Comparison

There are two Block I CPU simulators.  Because each has its advantages, both are described in more detail in the sections dedicated to them that follow.  However, a capsule comparison is given by the following table. 

The table above refers to the version of John Pultorak's simulator which has been ported to gcc and corrected, rather than to his original code, which is also available.  Both versions are discussed in the following section.

John Pultorak's Assembler and Simulator

cd DirectoryContainingTheSource
make

./yaAGC-Block1 --power

• m<Enter> — displays a menu of commands.
• n<Enter> — toggles between stepping through control-pulses vs stepping through basic instructions.  (The default is basic instructions.)
• t<Enter> — steps one control pulse or basic instruction.
• v<Enter> — begin a free run of the program.
• u<Enter> — stops a free run of the program.
  
• tN<Enter> — steps N control pulses or basic instructions.
• bE<Enter> or bB,O<Enter> — set a breakpoint at erasable or fixed-fixed address E (i.e., 0000-7777) or fixed address B,O (03,6000 through 34,7777).  All are octal.  A "flat" address can also be used.  Only one breakpoint can be set at any given time.
  
• b — clear a breakpoint if one is set.
• bcN<Enter> — break after a total of N MCT (instruction cycles) have elapsed since power-up.
• l<Enter> — (that's a lower-case L) if --log was used on the command-line, toggle logging off or on again.
• eN<Enter> — inspect memory words beginning at (erasable, fixed-fixed, or flat, but at present not banked) address N.
• f<Enter> — toggle source-code display on/off.  Default is on.
• q<Enter> — quit the program.

However, this is not necessarily a complete list, even of the commands I created for it, so please do use the 'm' command to see what additional ones there may be that I've forgotten to list here.  There are also commands for John's built-in textual DSKY, but I don't understand how they work, and I have only used the simulator essentially without a DSKY.

There are also command-line options that allow you to do various things, such as selecting a different program than Solarium 055.  The program will accept rope files and program-listing files created either yaYUL (with the --block1 switch), assuming you had some Block I program other than Solarium to work with, or else as produced by John's own assembler.  A yaYUL command like the following

yaYUL --block1 --unpound-page MAIN.agc >program.lst
mv MAIN.agc.bin program.bin

./yaAGC-Block1 --power --rope=program

"... Fine detail and internal consistency have been under-emphasized for the sake of promptness so that this report could be written within a few weeks of the inception of the design."

1. The memory model is undersized:  the amount of fixed rope memory in the device was increased after R-393 was written, from the 12 banks to 24 banks, and Solarium 055 will in fact not fit into 12 banks.
2. The (corrected) interrupt-vector table is at address 2000, and the entry point for the program is at 2030.  In the original version of the program, however, they are at 2004 and 2000, respectively.
3. Timer registers (TIME1, 2, 3, and 4) increment at 10× the speed they're supposed to. Specifically, TIME1, 3, and 4, which are supposed to increment every 10 ms., actually increment every 1 ms. TIME2, which is triggered by overflow in TIME1, increments every 16.384 seconds rather than every 163.84 seconds as it's supposed to.
4. Okay, I admit I'm not too sure about this one ... but the sim seems to integrate parity bits everywhere.  That gave me a lot of trouble, so I simply disabled it.
   
5. Bit assignments in output-register OUT1 (only OUT0-OUT1, of OUT0-OUT4 are implemented) are not correct. They unfortunately had to be taken from the bit assignments of the Block II output register of the same name, but those do not correspond to the Block I computers. (The corresponding OUT0 registers in Block I and Block II do, however, correspond perfectly to each other!)

yaAGC-Block1 [OPTIONS]

• --go=address, where the address, in octal, is the location of the AGC program's entry point.  This is always 02030, and that's the default, but the option is present for legacy reasons, because the program originally used a starting address of 02000.  However, this option is never needed for a true Block I program.
• --rope=basename.  The program expects by default to find the rope file Solarium055.bin and the assembly-listing file Solarium055.lst (both created by the yaYUL assembler) in the current working directory, as well as the Solarium055.pad file (generally created by manual editing).  The latter two are actually optional, but should be present for fully functionality, whereas the former two could theoretically have been produced by John's assembler rather than by yaYUL.  In any case, basename could be changed from the default "Solarium055" to some other string, if another Block I program becomes available some day.
• --log=filename.  Instructs the assembler to create a log file that traces the AGC program's execution.  By default, there is no log file.
• --extra=address.  Instructs the simulator to add the contents of the memory location at the flat-address address to its log file.
  
• --power.  Instructs the program to automatically issue the 'p', 'r', and 't' commands upon entry.  What this does is to set up the simulator's debugging facility to start out treating the AGC program as a set of assembly-language instructions, whereas by default it would instead treat it as a set of command-pulse sequences.  Unless you are trying to debug the simulator itself, as opposed to the AGC program that the simulator is running, the former is what's desired, and thus --power should almost always be used.
• --zero.  Instructs the simulator to automatically zero out all erasable memory before running the AGC program.  This is the default behavior.
  
• --uinint.  Instructs the simulator to automatically fill all erasable memory with the illegal value 0166666 before running the AGC program. In general, if the pad-load file (by default Solarium055.pad) is constructed correctly, there should be no behavioral difference in the AGC program between --zero and --uninit.  However, --uninit is helpful in determining of the AGC program is accessing uninitialized erasable memory.
  

Virtual AGC's CPU Simulator (yaAGCb1)

My own Block I simulator is written independently of John Pultorak's, and no code from John's has been reused in mine, nor served as a model for mine.  That isn't intended to imply that John's program was not used, or that there is great flaw that prevents it from being used.  In fact, I used it extensively as a cross-check on the functioning of mine, with the intention of being able to run the two side-by-side, and have them match up register-for-register, instruction-for-instruction, on a cycle-by-cycle basis.  Sometimes this revealed errors in John's simulator, which I corrected.  Other times, it revealed bugs in mine, which I corrected.  Often, there were just differences I hadn't anticipated, usually involving arithmetical overflow bits that got written into registers I hadn't expected; in which case, when they were reasonable even if unexpected, I did what checking I could but almost always adopted John's approach in place of my own.

So the upshot of that is that these programs now behave essentially identically.

Then why have two (other than the obvious advantage of being able to cross-check one against the other ... though one shouldn't underestimate the great advantage of being able to do that)?  Well, it mainly has to do with the fact that the CPU simulator has to be able to integrate with other Virtual-AGC style peripheral devices, such as simulated DSKYs, to be able to participate in the GUI code::blocks style debugging capabilities that other Virtual AGC simulators have, and so on, and after investigating it I just thought it was cleaner and simpler to start from scratch in doing so, given the programming style I personally preferred to use.  Obviously, others' opinions may differ, and the problems I perceived I was solving could easily be more in my mind than in John's program.

You can find code for my new simulator in our GitHub repository.  I have only worked with it in Linux, but I expect it should probably build in Mac OS X or Windows (with MinGW/Msys), as long as you have g++ and pthreads installed.  All you have to do is

cd DirectoryContainingTheSource
make

./yaAGCb1

• m<Enter> (or actually any unrecognized command) — displays a menu of available commands.
  
• t<Enter> — steps one control pulse or basic instruction.
• tN<Enter> — steps N control pulses or basic instructions.
• eN<Enter> or eB,O<Enter> — examine the memory at the specified address, and for a few addresses following it.
• eN=V<Enter> or eB,O=V<Enter> — set the value of an erasable-memory location (including registers, i/o ports, timers, and counters) or fixed-memory location.  The value can be 16-bit even though most of these locations are in principle 15-bit only.
  
• bN<Enter> or bB,O<Enter> — set a breakpoint or watchpoint at an address.  Up to 16 breakpoints are allowed.
  
• bcN<Enter> — break after a total of N MCT (instruction cycles) have elapsed since power-up.
• be<Enter> — break after a any read access to an uninitialized erasable.
• b<Enter> — remove all breakpoints.
• b?<Enter> — list all breakpoints.
• l<Enter> — (that's a lower-case L) if --log was used on the command-line, toggle logging off or on again.
• q<Enter> — quit the program.

1. Run the simulator with a command-line switch "--log=FILENAME".
2. Execute identical portions of the code in the simulator, for example with "t2000" to execute 2000 assembly-language instructions.
3. Quit the simulator ("q").

This capability is enhanced with the 'bcN' and 'l' commands, since those may allow you to avoid adding a large amount of information to the log when you know in advance that it will be identical.

Here is the full syntax at present for using the my Block I simulator is:

yaAGCb1 [OPTIONS]

• --go=address, where the address, in octal, is the location of the AGC program's entry point.  This is always 02030, and that's the default, but the option is present for legacy reasons, because the simulator originally used a starting address of 02000.  However, this option is never needed for a true Block I program.
• --rope=filename.  The simulator expects by default to find the rope file Solarium055.bin in the current working directory, but this option allows you to change that filename.
• --listing=filename.  The simulator expects by default to find the assembly-listing file Solarium055.lst in the current working directory, but this option allows you to change that filename.
• --pads=filename.  The simulator expects by default to find the pad-load file Solarium055.pad in the current working directory, but this option allows you to change that filename.
• --run.  By default the simulator immediately pauses the AGC program at its first instruction, and drops into an interactive textual-debugging mode.  With this option, you can simply cause the simulator to begin running the AGC program without pausing.
  
• --log=filename.  Instructs the assembler to create a log file that traces the AGC program's execution.  By default, there is no log file.
• --extra=address.  Instructs the simulator to add the contents of the memory location at the flat-address address to its log file.
  
• --zero.  Instructs the simulator to automatically zero out all erasable memory before running the AGC program.  This is the default behavior.
  
• --uinint.  Instructs the simulator to automatically fill all erasable memory with the illegal value 0166666 before running the AGC program. In general, if the pad-load file (by default Solarium055.pad) is constructed correctly, there should be no behavioral difference in the AGC program between --zero and --uninit.  However, --uninit is helpful in determining of the AGC program is accessing uninitialized erasable memory.
• --port=portnum.  By default, the simulator listens on TCP ports 19671-19680 for connection attempts by virtual peripherals like the simulated DSKY or simulated digital uplink.  This option allows you to change the starting address of that range.  In case it is not obvious, 19671 refers to the Apollo 1 tragedy, which occurred on January 27, 1967, and thus is a kind of memoriam for the crew of Apollo 1.  Apollo 1 and Apollo 2, if either had ever flown, would have flown with Block I AGCs.

Status of yaAGCb1

I have not fully completed yaAGCb1 in the sense that yaAGC is complete, and thus wouldn't expect it to fully work if integrated into a full spacecraft simulator.  While I don't have a complete list at the moment of what works and what doesn't, nor have all the parts of yaAGCb1 that I think work been fully tested, I can definitely say that I've not yet bothered with the following:

• I have not hooked up simulated input signals to the CPU's counter registers (CDU, PIPA, etc.)
  

Virtual AGC's DSKY Simulator (yaDSKYb1)

cd ParentDirectoryOfyaDSKYb1/
yaDSKYb1/yaDSKYb1main [--images=DIRECTORY] [--port=PORTNUM] [--nav-bay]

Virtual AGC's Digital Uplink Simulator (yaUplinkBlock1)

At present, a program called yaUplinkBlock1 is provided (in the similarly-named source-code directory in our GitHub repository. It is a simple command-line program, in which you can type (or feed in from a script) ASCII mnemonics for DSKY keys, which the program then converts to the proper uplink format and sends to the Block I AGC simulator.

The ASCII mnemonics for the various DSKY keys, rather straightforwardly, are:

• ' ' is a "blank" or no key pressed.
• '0'-'9' are the keys 0-9.
• '+' and '-' are the plus and minus keys.
  
• 'v' is the VERB key.
• 'n' is the NOUN key.
• 'c' is the CLEAR key.
• 'r' is the ERROR RESET key.
• 'k' is the KEY RLSE key.
• <Enter> is the ENTER key.

Thus, entering "v36<Enter>" in yaUplinkBlock1 is equivalent to V36E on the DSKY keypad.

The full command-line syntax is

yaUplinkBlock1 [--port=PORTNUM] [--batch]

The --port setting, of course, changes the default TCP port (19675) of the uplink program.  By default, yaUplinkBlock1 is suitable for accepting input interactively from a computer keyboard, but not from a (say) a script.  The --batch switch flips that around, so that (for example) with the --batch switch you could do something like the following if you wanted to:

echo "v11n16" | yaUplinkBlock1 --batch

Taking Solarium for a Spin

1. R-467, The Compleat Sunrise briefly covers what was available in the Block I SUNRISE program (September 1964). 
   
2. You can pick through the Solarium 055 source code (April 1968), to try and figure out what's available.
3. You can look at the available documentation for Colossus 237 (December 1968), though considering that Colossus 237 was a Block II program and Solarium a Block I program, it's unclear how much similarity we can expect to see.
   

	Startup screen, immediately after starting simulation.	Actually, this is not really the first thing you see, but just the first screen that persists long enough to take a screenshot of it.  At first, it will really show "PROGRAM 00" rather than "PROGRAM 77", because the AGC is in "major mode" 00.  What has happened, however, is that on power-up the AGC hasn't been able to detect any Inertial Measurement Unit (IMU), because we don't have a simulation for one hooked up to it!  Detecting this condition, a specific AGC program called the "Night Watchman" has detected this condition and decided to flip over to major mode 77 ... which isn't documented, as far as I can tell, and none of the original AGC developers I've contacted remember it, including Jim Kernan, who was Solarium's "rope mother". Of the other items displayed, "VERB 05" is an "octal display of data" while "NOUN 31" indicates that the data being displayed is "Failreg", the failure register.  The 5-digit displays, I believe, are the last three error conditions reported, of which only one, 00203 actually has an error code in it.  Thus, you are seeing "Alarm 00203".  According to the source code, alarm 00203 is "NO IMU MODE INDICATED TO COMPUTER". The IMU mode is communicated to the AGC through its input register IN2, I believe, which is all zeroes at this point, given that there is no IMU, and all zeroes is not recognized as a legitimate IMU mode.
	V36E	No problem.  Let's use V36E, "Fresh Start".  It doesn't get rid of the Alarm 00203 message, but at least it does put us into major mode 00, as we're entitled, I expect.
	V32EEE	I don't actually know how to get rid of that Failreg display, short of instructing the AGC to display something else ... or we could use V32E, "Bump displays", i.e., scroll the register display downward.  To get rid of all 3 error codes, we have to do it three times.
	V31N02E	We could use V32N02E to let us display the contents of the AGC's memory.  What you see if you use this command is that the "REGISTER 3" display clears, and we can enter an octal address.  These addresses are what I personally call "flat" addresses, though I think there may be some official buzzword for it that I don't recall at the moment.  With flat addresses, the entire AGC memory space is simply a continuous one from octal addresses 000000 through 071777, where 000000-001777 is erasable memory. 002000-005777 are "fixed-fixed" memory. 006000-007777 is bank 03 010000-011777 is bank 04 ... 070000-071777 is bank 34. So if, for example, I now entered 12345E (into the open space for REGISTER 3), what I should get is the contents of 05,6345, which a quick check of Solarium's assembly listing reveals to be 03136.  And amazingly, that's what the DSKY shows in REGISTER 1 as well. At this point, you can actually keep examining as many memory locations as you like, just by pressing ENTER, then a new octal address, and then ENTER again.  It doesn't seem to work for registers, though.  Perhaps the address should be kept at 060 or higher.
	V16N65E	Or perhaps, we might want to display the time since startup.  V16, " Monitor (in decimal) all component (s) of", combined with N65E, "Time (Hours and Seconds)", does the trick.  The terse descriptions of the verbs and nouns from resources like R-467 make it a bit tough to figure out what we're actually seeing on the DSKY's display, but you can figure it out with a little bit of cogitation: REGISTER 1:  The time, in decimal, in units of 1/100 hours.  Therefore, it increments every 3600/100=36 seconds. REGISTER 2:  The time, in decimal, in units of 1/100 seconds.  According to R-393, it should be updating every 1/2 second, but it's pretty clear that it's updating once per second instead.   Since it only goes up to +99999, obviously we expect it to wrap around to +00000 every 1000 seconds.
	V15N31E V21N27E 77777E KEY REL	Or, if you were crazy — but you are reading this page, so what does that say about you? And I'm writing it, so what does that say about me? — you could manually start SOLARIUM's built-in self-test program.  If an error is detected, it shows up in REGISTER 2.  REGISTER 2 holds 00000 if no failure has been detected, whereas otherwise it holds the address in AGC memory immediately following the point at which the self-test code detected the failure.  To interpret what that means you have to actually look at the assembly listing of SOLARIUM's self-test code.  Horrifying! For example, if REGISTER 2 held 06305, you'd look for the address 06304  (actually 11,6304) in the self-test code, and you'd find out that it was an error in the check of the DV (divide) instruction, because you'd find this: ... 010382,000238: 11,6244 36557 DVCHK CAF SCON3/8 010383,000239: 11,6245 50001 TS Q 010384,000240: 11,6246 34502 DV++ CAF SCON1/4 010385,000241: 11,6247 25777 INDEX 5777 010386,000242: 11,6250 50001 5 Q # C(A) = 25252, CHECKS RSC PULSE 010387,000243: 11,6251 51771 TS SKEEP1 010388,000244: 11,6252 30003 XCH LP 010389,000245: 11,6253 51772 TS SKEEP2 010390,000246: 11,6254 40001 DV+- CS Q # +1/4 010391,000247: 11,6255 25777 INDEX 5777 010392,000248: 11,6256 56560 5 SCON-3/8 # C(A) = 52525 010393,000249: 11,6257 61771 AD SKEEP1 # C(A) = -0 010394,000250: 11,6260 51775 TS SKEEP5 # SHOULD BE -0 010395,000251: 11,6261 30003 XCH LP 010396,000252: 11,6262 51773 TS SKEEP3 010397,000253: 11,6263 30001 DV-- XCH Q # -1/4 010398,000254: 11,6264 25777 INDEX 5777 010399,000255: 11,6265 56560 5 SCON-3/8 # C(A) = 25252 010400,000256: 11,6266 51771 TS SKEEP1 010401,000257: 11,6267 30003 XCH LP 010402,000258: 11,6270 51774 TS SKEEP4 010403,000259: 11,6271 30001 DV-+ XCH Q # -1/4 010404,000260: 11,6272 25777 INDEX 5777 010405,000261: 11,6273 56557 5 SCON3/8 010406,000262: 11,6274 61771 AD SKEEP1 # C(A) = -0 010407,000263: 11,6275 51771 TS SKEEP1 010408,000264: 11,6276 40003 CS LP # C(A) = 37776 010409,000265: 11,6277 61771 AD SKEEP1 # C(A) = 37776 010410,000266: 11,6300 61772 AD SKEEP2 # C(A) = 37777 010411,000267: 11,6301 61773 AD SKEEP3 # C(A) = -0 010412,000268: 11,6302 61774 AD SKEEP4 # C(A) = +1 010413,000269: 11,6303 61775 AD SKEEP5 # C(A) = +1 010414,000270: 11,6304 06033 TC -ONECHK -1 ... User friendly?  No!  But very fine-grained. And obviously not very instructive unless you can make the self-test fail somehow!  But that's not going to happen unless our Block I AGC emulator itself fails.  And the only way you could make it fail is to modify the source-code of the Block I emulator (yaAGCb1)!  Which wouldn't be my recommendation.  (Actually, I tell a lie:  If you used yaAGCb1's built-in debugger, you could introduce errors at will without modifying yaAGCb1's source code.  I'll leave this as an exercise for the advanced student.) But I can say that the self-test has revealed errors in the past, resulting in the correction of bugs in the emulator, so the emulator would not be what it is today without SOLARIUM's self-test.  On the other hand, I'll also point out that SOLARIUM's isn't the only Block I test code available, and there are more-comprehensive tests than those in SOLARIUM in the Block I program called SUNRISE.  SUNRISE flew in no missions, as its purpose in life was to act as a test suite.  So as an alternative demo of Block I, you could run SUNRISE 69 rather than SOLARIUM.  Some or all of the tests available in SUNRISE 69 are listed here.  (Read both the SUNRISE 45 and SUNRISE 69 blurbs!)

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