Відео

Wow, yeah, the wording in that control pulse table is needlessly confusing. TSGU does not affect BR2; it simply copies U16 into BR1. AGC4 memo 9's descriptions of the control pulses are a bit more clear here. Figure 4-136 in ND-1021042 might be the best way to directly confirm which control pulse affects which branch register -- it has logic equations for both printed on the left sides of their respective pages. TSGU appears in BR1's equation but not BR2's.

I think you may need another level of selection for writing into EB, for the "TS BBANK" possibility: in this case, EB is loaded from bits 1-3 of the write lines, without going through U. The erasable memory in the AGC is traditional coincident-current core memory, not core rope -- only the fixed memory used rope. And unlike more modern SRAMs, core memory (of either variety) needs no refresh! Once the data is written, it will be retained indefinitely (at least 50+ years), even through complete loss of power. The Apollo missions made use of this capability to power down the computer in flight (e.g. on the lunar surface) without worrying about needing to reload anything once the computer was powered back up -- the RAM was nonvolatile, and the computer was designed in such a way to expect (but validate) data to still be there during boot. The problem is that readout from core memory is destructive. Whenever you read from a core memory location, all of the corresponding cores get set to 0. To account for this, all data that is read out must be written back. In the AGC design, this is all handled through the control pulse sequences: instructions that do not modify erasable make sure that they have stored the original value back into G before the erasable write cycle starts. Instructions that do change erasable simply put the new desired value there instead of what was read. It's definitely worth implementing the parity logic! Even though you'll almost surely never encounter an erasable memory parity error, fixed parity errors are easy to trigger, and the computer test procedures involve steps to intentionally trigger them. This is because all unused fixed memory locations are completely unwired in the rope memory modules, causing them to read as all 0 bits, including the parity bit. So all you need to do to trigger a parity alarm is attempt to read from a fixed location not used by the current program. Also, resetting S with your GENRST isn't strictly necessary, although I don't think it will have any ill effects. The original AGC design allowed the S register to start with any random value, with no reset inputs. The boot process forces the GOJ1 subinstruction to execute first, which sets S to a known initial value through control pulse action. Digital Development Memo #340, "Block II GOJAM Actions", contains a nice concise list of all of the things that the global RESET signal did in the original design.

Small historical correction: Block I was also referred to as "AGC4", and was already the fourth iteration on the design -- making Block II arguably the fifth. Block I already had the EXTEND instruction, although it was implemented in a different way. Its predecessor, the Mod 3C ("C" for "Complex", because it included hardware multiplication!), did not. The Mod 3C only implemented 8 instructions, all directly encodable with the 3 opcode bits: TC, CCS, INDEX, XCH, CS, TS, AD, and MP. Block I's EXTEND is kind of weird in one sense but also makes a lot of sense. It's not its own (pseudo-)instruction like Block II; instead, it is activated by using INDEX to cause an overflow condition on the following instruction. This overflow essentially allows you to write into a fourth bit for SQ. The assembler does recognize the "EXTEND" mnemonic, for which it emits INDEX 5777. By convention it is expected that the programmer has left the constant 47777 there (this must actually be part of your program! If it's not and you use the EXTEND mnemonic, you will have a bad day).

Awesome project! Something I would mention is that the erasable core memory is non-volatile when it loses power. I am more of a software guy than a hardware guy, but when developing an AGC emulator, I found that deliberately initializing erasable memory to random values at computer startup (excluding registers), would frequently cause crashes or failure to boot properly. If you aren't already, that might be something to consider since you mentioned you plan to use static RAM for erasable memory, which I think might have a similar issue in practice due to its volatile nature.

Great video! It's great to see the progress, and I'm excited to see everything on GitHub! There was actually a hardware design bug related to NEAC that wasn't fixed until quite late in the Block II design process: NEACOF comes too early in the MP3 control pulse sequence. It clears NEAC at time 6, but the multiplication has not quite finished yet and end-around-carry still needs to be inhibited for the addition happening during times 7-10. Since it was a late fix, not all of the documents we have include it, and not all of the logic drawings show the change. Updated documents describe NEACOF as "Permit end-around-carry after end of MP3". The actual fix was very simple but slightly hacky: they simply treated the subinstruction selection signal MP3 as another inhibit for end-around-carry, such that no EAC will ever occur during MP3, regardless of the state of NEAC. This was done using a spare expander gate in module A2. In the original schematics, it's on sheet 3, right next to the spare pins. The fix is also visible in Figure 4-153 in earlier revisions of ND-1021042 (they dropped it in later versions, possibly by mistake...): MP3A (equivalent to MP3) is used as an additional inhibit for EAC, along with NEAC. In your design, I think the equivalent fix would be to add MP3/ as a third input to U1121C, alongside NEAC/.

I am so much looking forward watching your series. I think this is an amazing project that combines 2 of my great interests the Apollo program computers and 74 logic series breadboard computers.

Wow that is a serious bit of work just to build it let alone actually work out the circuits etc way above my ability for sure but I'll be really interested to see the final machine albeit I have no idea how one would interface it to the outside world. I too followed CuriousMarc and those guys are nothing less than stunning. My background is hardware primarily PCB and thick film design and I like your generic board approach however I might suggest I suspect you could regret wiring over the chips, if it were me I think I would try and run them between the devices . I just have a feeling as the wiring increases you are going to have trouble digging down to test points but up to you and all the best in what is a major undertaking

All of those simplifications are great to see! 😃L has one more unique feature: even though it is implemented in hardware as (and can be written to as) a 16-bit register, it behaves as a 15-bit register when reading data out onto the write lines. Bit 15 of L can never make it out onto the write lines; instead, bit 16 of L is placed onto both WL15 and WL16. The AGC software sometimes uses this feature for overflow correction, since writing something into L and then reading it back out will effectively copy the upper sign bit into the low one. From software's perspective, I don't _think_ there is any way to test the value of bit 15 of L once it's been written to. Sometimes more software-focused documentation will call L a 15-bit register because of that -- but the hardware makes extensive use of bit 15 of L for multiplication and division, so that's not really fully true. Everything that needs the true value of the bit can still access it through your L15 pin.

That approach for handling the multiple-read-pulses-at-the-same-time thing with modern devices is really clever! That works in the original computer because of its use of RTL logic. RTL has a kind of funky feature in that you can tie the outputs of any two gates together, and it works like a wired-AND. For AGC purposes, if you tie the outputs of two 3-input NOR gates together, you get a fully functional 6-input NOR gate. Electrically this works because every RTL output is essentially open-collector with a built-in pullup. The write lines don't have any special drivers, so they operate the same way. When multiple R* pulses go off, all of the registers really do drive their outputs onto the write lines at the same time and it all gets wired-AND'd together. But crucially, the write lines are distributed inverted, so logically the contents of all of the registers are being OR'd together. This is true for all instances, so if you see RA RC, that's (A or C); RU RB is (U or B); etc. Since the computer can only invert things through B/C and perform logical ORs on the write lines, in order to compute a logical AND, the MSK0 subinstruction mechanizes De Morgan's law A & B = ~(~A | ~B). It first inverts the accumulator (3. RA WB; 4. RC WA); then it sticks the word from memory into B so that it can be accessed inverted as C (7. RG WB); then it logically ORs the already-inverted A and C together by reading them at the same time, using the adder as temporary storage (9. RC RA WY; writing to Y naturally zeros X); then it fetches number back from the adder and again inverts it to achieve the final result (10. RU WB; 11. RC WA). In case you haven't spotted them: in addition to the six cases you've highlighted, RXOR0 has two more (3. RC RCH WY; 11. RC RG WA), and DV0 has an RSC that could possibly trigger one (7. RG RSC WB TSGN). Certain instructions also use this same mechanism to logically OR a constant with a register, like DV3 (5. 1X RG WL TSGU RB1F). The AGC Monitor can also logically OR whatever it wants onto the write lines at any time with the MDT01-MDT16 test connector inputs, which may or may not matter depending on your plans for test equipment.

This is a good observation and I bumped into it when starting to lay out my S register (still a work in progress), but I’ll be generating the XB signals from there (helps me save a line on the backplane for SCAD as it’s getting crowded as it is, 96 pins just isn’t enough lol). I had considered putting XTO on the backplane (and I may need to do so) based on the last quirk you mentioned (bit 10). I’ve only looked at the channel side of things at a high level so far.

How are you defining XB2? It sounds like you're using it to mean "the whole address is 0x0002", but in the original design it only covers bits 1-3 of the address. XT0 then covers bits 4-6. This is *maybe* an important distinction because channels use a different number of address bits than normal accesses. If Q is accessed as an addressable register, it is accessed via RSCG/WSCG instead of RSC/WSC directly. The G versions of these control pulses combine them with SCAD (Special/Central ADdress, or something like that). SCAD will be 1 if and only if bits 4-12 of S are all 0; therefore, if RSCG/WSCG are active, it is sufficient to use XB2 to only examine the bottom 3 bits of S to figure out which special/central register is being accessed. As a result, all 12 bits of S are inspected. Channel accesses on the other hand are not combined with SCAD. Instead, only XT0 is combined with XB2 -- meaning that only bits 1-6 of S are examined. This produces a weird quirk of the AGC design where, even though the channel address space is nominally 9 bits, all channels implemented inside the AGC are accessible with any combination of bits 7-9. So Q is channel 2, but it's also channel 102, 202, 302, etc.... This behavior is never exploited, and we don't even emulate it in VirtualAGC at the moment, so it's no big deal if your replica doesn't replicate it. More importantly though, I/O opcodes take 6 bits to encode. The control pulse sequences for the I/O instructions do the usual quarter-code thing of using RL10BB WS to clear out bits 11 and 12 of S, but they don't clear bit 10, so during WRITE, WAND, and WOR, bit 10 of S is going to be still be set at the time of the RCH and WCH control pulses. Thus, while addressing Q as a special/central register requires looking at all 12 bits of S, accessing it as a channel requires ignoring at least bit 10. Sorry if you've already thought about this and have handled it a different way, or if I'm misinterpreting your logic!

I'm really enjoying your videos so far -- you're doing a great job explaining everything. I'm excited to see how it all comes together!

An AGC and a DSKY would make an amazing DRO for a machine tool like a mill. The three-number I/O of the DSKY would be perfect for X/Y/Z axis measurements.

The restoration of the AGC by CuriousMarc and his team was wonderful to see. Seeing the AGC working on a breadboard also seems very exciting to me, so I'm looking forward to see it.