Contents

Introduction

This page is devoted to the electrical and mechanical aspects of the AGC and DSKY, and more broadly, to the electrical and mechanical aspects of the entire Apollo CM and LM G&N (guidance and navigation) system.

This is an ongoing effort.  The long-range goal — or perhaps "wish" is a more-accurate term — is to provide the following engineering resources:

  1. The complete set of engineering drawings (electrical schematics and mechanical drawings) for AGC/DSKY and other G&N components, in all revisions, in the form of scanned images of the original Apollo Program drawings.
  2. Contemporary Apollo Program theory-of-operation documents for the above.
  3. Electrically and visually accurate transcriptions of those electrical schematics into a modern open-source electrical CAD program.
  4. Accurate translation of mechanical drawings of fabricated parts into reusable 3D models.
  5. Translation of AGC electrical design into Verilog hardware-description language or other standardized languages when appropriate.
  6. Simulation of the AGC hardware, via modern open-source Verilog-simulation software, or other software when appropriate.

Great strides have been made toward the goal, but it nevertheless remains very distant.

Accessing the Available G&N Engineering Drawings

There are three methods, covered in the three sections below.

Search by Drawing Number or Title

Go to the Apollo G&N engineering-drawing title search-engine page

Browse by Drawing Number

To find any given drawing by its drawing number, first look in the "box" that covers that drawing-number range.  Then consult the "miscellaneous" drawings if what you want is missing from the box or is illegible, or is simply too early a revision.  The exceptions are mil specs (drawings with numbers like MSxxxx or NASxxxx), since if we have them they'll always appear on the dedicated MIL-SPEC page rather than being mixed in with the other drawings.  I should point out some drawings appear in the wrong boxes, numerically, for several possible reasons, though perhaps 99.9% of the drawings are numerically in the correct boxes.
Box 431, 102010-1000275 Box 432, 1000283-1002237
Box 433, 1002240-1002323
Box 434, 1002323-1002325
Box 435, 1002325-1002349
Box 436, 1002349-1003081
Box 437, 1003082-1003733
Box 438, 1003733-1005799
Box 439, 1006002-1006898
Box 440, 1006904-1007131
Box 441, 1007141-1007547
Box 442, 1007548-1008271
Box 443, 1008283-1010253
Box 444, 1010254-1010493
Box 445, 1010494-1011399
Box 446, 1011400-1014219
Box 447, 1014221-1014999
Box 448, 1015000-1015739
Box 449, 1015740-1016118
Box 450, 1016122-1019690
Box 451, 1019691-1021200
Box 452, 1021200-1897187
Box 453, 1897190-1900098
Box 454, 1900100-1900712
Box 455, 1900713-1900943
Box 456, 1900943-1901695
Box 457, 1901700-1902397
Box 458, 1902404-2003120
Box 459, 2003121-2005061 Box 460, 2005062-2007114
Box 461, 2007115-2007239 Box 462, 2007240-2010084
Box 463, 2010085-2012508
Box 464, 2012509-2014643
Box 465, 2014644-2015500
Box 466, 2015502-2018632
Box 467, 2018634-2021670
Box 468, 2021971-2900541
Box 469, 2900542-2901129
Box 470, 2901143-6010677
Box 471, 6010678-6015000
Box 472, 6015000-8106098
Box 473, JDC0001-JDC04390
Box 474, JDC4409-JDC10709
Box 475, JDC10710-JDC12621
Box 476, JDC12622-JDC18874
Box 477, JDC19021-MC25922

Mil-Spec drawings
Miscellaneous drawings

Navigate the Mission Assembly Hierarchy

In this section, the engineering drawings are provided on a mission-by-mission basis.  I expect to be acquiring drawings to help fill in gaps in the drawing hierarchy at least through the end of 2020, though the collection will necessarily still be incomplete even when that process has come to an end.  Note, though, that there are assemblies in the engineering-drawing set that don't form any part of the spacecraft G&N system, and those assemblies aren't covered in this section; an example would be the AGC's test set.

Each mission had either one or two G&N (Guidance & Navigation) systems installed:  one for the CM and/or one for the LM.  Each G&N system is identified by a numerical assembly number (1014999 for Block I CM, 2014999 for Block II CM, 6014999 for LM) plus a 3-digit configuration number (-000, -021, -031, ... , -221) that changed from one mission to the next.  For example, the Apollo 11 LM had G&N system 6014999-091.  Note, by the way, that we're presenting these assemblies entirely from a NASA perspective; changes were made to the G&N system configurations after MIT/IL delivered them to NASA, and there's a completely different set of drawings (1015000, 2015000, 6015000) that describe the G&N system configurations at the time they were shipped to NASA.

Such a G&N system is represented by a set of engineering drawings. Given the drawings of the G&N system, you can then look at the drawings of any of its sub-assemblies (AGC, DSKY, CDU, etc.), any of the drawings of the sub-assemblies of the sub-assemblies, and so on.

G&N System
Part Number
G&N System Serial Number
(Spacecraft, Mission)
Block I CM Systems
1014999-000
5
1014999-011
6
1014999-021
7
1014999-031
8
1014999-041 12
1014999-051
17 (CSM-011, AS-202, "Apollo 3")
1014999-061 20
1014999-071 109
1014999-081 110 (Qualification system)
1014999-091 111 (Qualification system)
1014999-101 121
1014999-111 122 (CMO-17, Apollo 4)
1014999-121 123 (CMO-20, Apollo 6)
Block II CM Systems
2014999-011
201
2014999-021 202 (CSM-098, 2TV-1)
2014999-041 204 (CSM-101, Apollo 7)
2014999-051 205 (CSM-116, Skylab 2)
2014999-061 206 (CSM-106, Apollo 10)
2014999-071 207
2014999-081 208 (CSM-103, Apollo 8)
2014999-091 209 (CSM-104, Apollo 9)
2014999-101 210 (CSM-107, Apollo 11)
2014999-111 211 (CSM-108, Apollo 12)
2014999-121 212 (CSM-109, Apollo 13)
2014999-131 213 (CSM-119, Skylab, Rescue / ASTP Backup)
2014999-141 214 (CSM-110, Apollo 14)
2014999-151 215 (CSM-111, ASTP)
2014999-161 216 (CSM-113, Apollo 16)
2014999-171 217 (CSM-112, Apollo 15)
2014999-181 218 (CSM-114, Apollo 17)
2014999-191 219 (CSM-115)
2014999-201 220 (CSM-115A)
2014999-211 221 (CSM-117, Skylab 3)
2014999-221 222 (CSM-118, Skylab 4)
LM Systems
6014999-021 602 (LTA-8)
6014999-031 603 (LM-1, Apollo 5)
6014999-051 605 (LM-3, Apollo 9)
6014999-061 606 (LM-4, Apollo 10)
6014999-071 607 (LM-6, Apollo 12)
6014999-081
608 (LM-2)
6014999-091 609 (LM-5, Apollo 11)
6014999-101 610 (LM-7, Apollo 13)
6014999-111 611 (LM-8, Apollo 14)
6014999-121 612 (LM-15)
6014999-131 613 (LM-9)
6014999-141 614 (LM-10, Apollo 15)
6014999-151 615 (LM-11, Apollo 16)
6014999-161 616 (LM-12, Apollo 17)
6014999-171 617 (LM-13)
6014999-181 618 (LM-14)

Note that the webpages for the individual G&N configurations linked above are generated in an automated way which additionally outputs a JSON representation of the hierarchical assembly data.  The JSON files are not provided on this website, but you can use the software to generate them for yourself, or to generate JSON for other assemblies (such as an AGC or a DSKY by itself).  This is significant because it means that you can load this JSON into a program, perhaps written JavaScript or Python, and manipulate the assembly-hierarchy data programmatically.  That would allow you to do things like compute total parts counts, perform failure-rate analyses, and so forth ... if you have any need whatever to do so!  To generate such a JSON file, you will need to locally clone the "schematics" branch of our GitHub software repository.  You will also need to have Python 3 installed.  You generate the JSON for a given ASSEMBLY from a command line by changing into the DrawingTree/ folder and running the command
drilldown.py ASSEMBLY >OUTPUT.html
The ASSEMBLY name consists of a drawing number to which a configuration number is suffixed.  The only allowed drawing numbers come from the names of the files DrawingTree/*.csv.  The only allowed configuration numbers come from the "columns" of the .csv file (if you were, for example, to load it into a spreadsheet program).  For example, the file 2003200L.csv supports configuration numbers -011, -021, -031, -041, and -051, so you could generate JSON files for assemblies 2003200-011 through 2003200-051.  You are unlikely to want the output HTML file, and thus can discard it.  The JSON is always output with the filename drilldown-ASSEMBLY.json.

Additionally, the program drilldownCompare.py is provided.  It can make comparisons of two assemblies for which JSON has already been generated.  For example, to compare the guidance systems for the Apollo 11 and Apollo 12 LM, you would first generate their JSON
drilldown.py 6014999-091 >temp1.html
drilldown.py 6014999-071 >temp2.html
and could then use the command
drilldownCompare.py 6014999-091 6014999-071
You would find a number of differences in doing so, but perhaps the one that interested you most might be that assembly 2003993-031 (the AGC) had changed to 2003993-051.  If you now wish to compare those two AGC assemblies, recall that you need to generate the JSON for them ... which is easy, but is a hassle.  However, the data for assemblies 2003993-031 and -051 is already contained within the existing JSON for 6014999-091 and -071, respectively, so drilldownCompare.py lets you take a bit of a shortcut:
drilldownCompare.py 6014999-091 6014999-071 2003993-031 2003993-051
In doing this, you would find out that subassembly 2003983-021 had changed to 2003983-041, etc.  The general syntax is
drilldownCompare.py ASSEMBLY1 ASSEMBLY2 [SUBASSEMBLY1 SUBASSEMBLY2]
Note: The rather complete assembly drill-down and the software tools described above were preceded by a set of manually-crafted partial drilldowns of just the AGC and DSKY, and of just their "major" assemblies and components.  The last time at which those manual drilldowns were available on the website was at this commit of the software repository.  It is still possible to view the manual drilldowns, but to do so you should should clone the repository (at the commit linked above) onto your local system and browse ElectroMechanical.html locally.

Additional Engineering Drawings (LEM, etc.)

Beyond the Apollo G&N System engineering drawings already covered, we provide some related Apollo engineering drawings available that are less central to the basic purpose of the Virtual AGC project.  For that reason, they are not given the same intensive treatment as the G&N drawings.  In other words, there are no assembly drilldowns, no CAD transcriptions, etc.  In some cases, they are not even indexed, though I'll gladly accept the help of anyone who wants to do so for me!

Box 241
Box 242
Box 243
Box 244
Box 245
Box 246 Box 247 Box 248 Box 249 Box 250
Box 251 Box 252 Box 253 Box 254 Box 255
Box 256 Box 257 Box 258 Box 259 Box 260
Box 261 Box 262 Box 263 Box 264 Box 265
Box 266 Box 267 Box 268 Box 269 Box 270
Box 271 Box 272 Box 273 Box 274 Box 275
Box 276 Box 277 Box 278 Box 279 Box 280
Box 281 Box 282 Box 283 Box 284 Box 285
Box 286 Box 287 Box 288 Box 289 Box 290
Box 291 Box 292 Box 293 Box 294 Box 295
Box 296 Box 297 Box 298 Box 299 Box 300
Box 301
Box 302 Box 303 Box 304 Box 305
Box 306 Box 307 Box 308 Box 309 Box 310
Box 311 Box 312 Box 313 Box 314 Box 315
Box 316 Box 317 Box 318 Box 319 Box 320
Box 321 Box 322 Box 323 Box 324 Box 325
Box 326 Box 327 Box 328 Box 329 Box 330
Box 331
Various (GAEC vendor drawings)
Box 332
Various (GAEC vendor drawings)
Box 332
Various (GAEC vendor drawings)
Box 502
LDW140-11430 to LDW270-53010
Box 503
LDW270-53020 to LDW-280-10319
Box 504
LDW280-10321 to LDW280-10743
Box 505
LDW280-10744 to LDW280-11216
Box 506
LDW280-1127 to LDW280-11532
Box 507
LDW280-11533 to LDW280-11869
Box 508
LDW280-11870 to LDW280-14316
Box 509 Box 510 Box 511 Box 512 Box 513
Box 514 Box 515 Box 516 Box 517 Box 518
Box 519 Box 520 Box 521 Box 522 Box 523
Box 524 Box 525 Box 526 Box 527 Box 528
Box 529 Box 530 Box 531 Box 532 Box 533
Box 534 Box 535 Box 536 Box 537 Box 538
Box 539 Box 540 Box 541 Box 542 Box 543
Box 544 Box 545 Box 546 Box 547 Box 548
Box 549 Box 550 Box 551 Box 552 Box 553
Box 554 Box 555 Box 556 Box 557 Box 558
Box 559 Box 560 Box 561 Box 562 Box 563
Box 564 Box 565 Box 566 Box 567 Box 568
Box 569 Box 570 Box 571 Box 572 Box 573
Box 574 Box 575 Box 576 Box 577 Box 578
Box 579 Box 580 Box 581 Box 582 Box 583
Box 584 Box 585 Box 586 Box 587 Box 588
Box 589 Box 590 Box 591 Box 592 Box 593
Box 594 Box 595 Box 596 Box 597 Box 598
Box 599 Box 600
Box 601 Box 602 Box 603
Box 604 Box 605 Box 606 Box 607 Box 608
Box 609 Box 610 Box 611 Box 612 Box 613
Box 614 Box 615 Box 616 Box 617 Box 618
Box 619 Box 620 Box 621 Box 622 Box 623
Box 624 Box 625 Box 626 Box 627 Box 628
Box 629 Box 630 Box 631 Box 632 Box 633
Box 634 Box 635 Box 636 Box 637 Box 638
Box 639 Box 640 Box 641 Box 642 Box 643
Box 644 Box 645 Box 646 Box 647 Box 648
Box 649 Box 650 Box 651 Box 652 Box 653
Box 654 Box 655 Box 656 Box 657 Box 658
Box 659 Box 660 Box 661 Box 662 Box 663
Box 664 Box 665 Box 666 Box 667 Box 668
Box 669 Box 670 Box 671 Box 672 Box 673
Box 674 Box 675 Box 676 Box 677 Box 678
Box 679 Box 680 Box 681 Box 682 Box 683
Box 684 Box 685 Box 686 Box 687 Box 688

In the list above, "NAA" refers to North American Aviation, the manufacturer of the CSM, "GAEC" refers to Grumman Aircraft Engineering Corporation, the manufacturer of the LM, and "MIT" refers to the MIT Instrumentation Laboratory.

References

The official AGC/DSKY electro-mechanical drawings available to us at the present time are these:

Besides these primary sources, there are additional (sometimes overlapping) essentially complete electrical schematics available in:
These documents are theory-of-operation documents, which describe the circuits textually and often provide useful information like timing diagrams of what the circuits do.  In the process of providing this info, though, they provide the schematics themselves as figured embedded within the text.  In saying that the schematics provided in the theory-of-operation documents are "essentially complete", what I mean is that the schematics in these volumes aren't precisely in the form of the original drawings, but rather have been redrafted by AC Electronics to fit into the format of their volumes.  Thus, they are subject to mistakes (and potentially, corrections) by AC Electronics, and cannot necessarily be straightforwardly matched to specific drawing numbers or revisions.

Surprisingly, while we have schematics in one form or another for all AGC/DSKY modules, though not necessarily in all of the different forms or versions we like, and we have wiring diagrams for the DSKY backplane into which its modules are inserted, we do not have wiring diagrams for the AGC backplane.  (See this section for a discussion of how the AGC circuitry is partitioned up.)  Nevertheless, we do have enough information about it to be useful, compiled by two techniques:  Firstly, the electrical schematics for the individual circuit modules list "net names" for all of the connector pins going from the module to the backplane, so we do know how the modules were interconnected on the backplane; secondly, physical AGCs can have their backplanes mapped by means of continuity checking with an ohmmeter.  Mike Stewart has put together a helpful sqlite database and an interactive, online form of it, based on mapping out the backplane for AGC s/n 14.

Other useful resources may be available in the "AGC electrical schematics" section of our document-library page.

Besides the AGC Handbook, additional information used for cross-referencing the various drawings to specific AGC or DSKY part numbers and/or serial numbers came from a couple of sources:

Finally, you'll notice that almost every one of the original electrical drawings includes the notation "INTERPRET DRAWING IN ACCORDANCE WITH STANDARDS PRESCRIBED BY MIL-D-70327":

Further Information About Scanned Engineering Drawings

The index pages and search engine for engineering drawings are organized by drawing number.  Most of the G&N drawing numbers (from MIT/IL, AC Electronics, Kollsman, etc.) are 7-digit numbers.  Block I drawings generally have numbers like 10xxxxx, while Block II drawings generally have numbers like 20xxxxx, although other drawings (such as Specification Control Drawings, SCDs) are also mixed into that numbering system as 10xxxxx numbers as well.  Drawings for military specifications, from North American, from Grumman, and so on, use other numbering systems.

In the simplest case, a "drawing" is just a sheet of paper that has been scanned and is presented as a single scanned image.  However, there are more-complicated cases as well, in which case a single drawing number might be represented as several or even as many, many scanned images:

Most (but not all) of the scans in the collection were captured from aperture cards (held permanently at the U.S. National Archives).  Aperture cards are computer punch cards, into which a photographic negative has been attached.  The punch card itself encodes metadata about the negative, such as its title, the total number of sheets, the specific sheet number, the number of frames in the sheet, the specific frame number, and so on.  Among the metadata fields on G&N cards is a "type" field; these "types" aren't documented, as far as I know, but what I've noticed is that they're interpreted as follows:
It is currently an ongoing effort on my part to scan all of the boxes of aperture cards (nominally 1800 cards each) of Apollo G&N drawings, and then conceivably the LM drawings from Grumman.  At present only a miniscule part of this scheme has been completed,   Where those complete box scans have become available, they are the best places to browse drawings, since each box tends to contain a range of consecutive drawing numbers.  Failing that, the miscellaneous index contains mostly alternate scans of subsets of the cards in the complete-box scans, but also contains a few hundred drawings missing from the National Archives' boxes.

Note that the descriptive text in the "Link" column of the various index tables isn't really very significant.  If the scan is simply a stand-alone file on this Virtual AGC Project website, the link text reads "drawing", while if it is instead a page within a larger batch of drawings at our Internet Archive site, then it is the page number within the specific batch of scans it originally belonged to.  There are no references to drawings (if any) that may exist at unaffiliated websites.   Regardless, just ignore the text of the link and click on it! 

By the way, if you should happen to download an image from the Internet Archive site by using your browser's "save image as" function, or if you try to download a PDF from there, if you're not careful you will probably get a very low-quality (though usually adequate) image rather then the full-resolution scan.  To avoid or reduce this quality reduction in downloading from our Internet Archive site, you can do one of the following:

Finally, some of the electrical drawings in the index have been manually transcribed into CAD files, using the open-source KiCad schematic-capture program.  Those transcriptions can be found at our GitHub site, but aren't explicitly linked in the index, and renderings of the CAD files as images can be found here.  The latter will obviously be of much higher legibility than the scans of the original drawings, but also will potentially differ from them in some ways.

Versioning the AGC and DSKY

The AGC and DSKY part-numbering scheme looked like this:
PARTNUMBER-DASHNUMBER REVISION

For example, Block II AGCs had PARTNUMBERs 2003100, 2003200, and 2003993, with DASHNUMBERs like -011, -021, -031, and so on.  REVISIONs were letter codes, such as A, B, C, etc., or else a dash (-) for "no revision".  For example,

2003200-011A

Given a part number for a particular AGC (or DSKY) model, the part number then relates to a set of sub-assemblies (often represented by electrical schematics or mechanical drawings), many of which are circuit modules, which themselves may have varying versions over time, and have part-numbers like

PARTNUMBER REVISION

For example, the AGC with p/n 2003200-011A contained, among other things, an "oscillator module" which fit into a backplane socket labeled B7, and which itself had a p/n 2005003E ... and naturally, we have drawing 2005003E if you want to see it.

In general, those DASHNUMBERs cover different configurations handled within the same engineering drawing.  For example, drawing 2003100 might cover both configurations -011 and -021, and you'd have to read the drawing itself to understand how unit 2003100-021 differs from unit 2003100-011.

With rare exceptions, different REVISIONs of a drawing do not introduce any design changes within a specific configuration, but may be used to cumulatively add a new configuration.  In other words, as long as a particular revision of a drawing contains the configuration you're interested in, it doesn't really matter (usually) that later revisions of a drawing may also exist, because later revisions won't differ substantively as far as any given configuration is concerned.

CAD Transcriptions of Apollo Engineering Drawings

In addition to providing scans of original electrical and mechanical drawings from the Apollo program, there is an ongoing effort to transcribe these drawings into CAD files.

Such CAD transcriptions are made as faithfully visually to the original as is feasible, given the capabilities of the CAD program involved, as long as there is no compromise of electrical or mechanical correctness.  But realize that transcription is a human effort, so transcribed CAD files may at first contain errors; conversely, they may from time to time correct errors present in the original drawings — naturally, though, with suitable notes indicating that the change had been made, and why.  It has also been possible occasionally to reconstruct some currently-missing drawings from the original Apollo Program.

Electrical Drawings

As far as electrical CAD files are concerned, no community effort has developed to transcribe the electrical drawings into CAD, but it now appears as though one isn't really needed since I'm sure I can do them all myself ... eventually.  You can simply treat the CAD files as resources which appeared from nowhere, but which you are free to use or modify for your own purposes.

To do so, the open-source KiCad electrical-design software is used.  It is available, for free of course, on Windows, Mac OS X, and all of the major flavors of Linux.  The electrical schematics which have been transcribed into CAD, or are in the process of being transcribed, are stored in our GitHub repository:

Schematic CAD Drawing Repository

The CAD drawings are typically rendered as PNG images as well, and provided separately for convenient browsing.

There's plenty of online material to help you get started with KiCad, if you're inclined to do anything more with the CAD files as such.  Here's the executive summary of what you need to know if you want to specifically work with our electrical schematics in KiCad:

Though no help in transcription is really needed, help in proof-reading and/or correcting the CAD files vs the original drawings is welcomed, and you can contact me directly at the address at the bottom of this page if you're interested.  Just proof-reading doesn't actually require using CAD or even having expert electrical knowledge.  It just involves comparing two images like the ones below and seeing how they differ from each other (click to enlarge):

Click to enlarge  Click to enlarge

Mechanical Drawings

2D CAD

We presently have no 2D CAD transcriptions of the original AGC/DSKY mechanical drawings.  If you would like to make some 2D CAD transcriptions of the mechanical drawings, I am happy to accept them for inclusion in the collection.  Any such CAD files will be stored and made available in a folder in the "mechanical" branch of our GitHub repository:

2D CAD Drawing Repository

I would ask that submissions conform to the following:

3D Models

Alternatively, people seem to be more interested the creation of reusable 3D models of the various fabricated parts comprising the AGC and/or DSKY.  If you wish to make submissions of 3D models, they'll be stored and made available in a folder in the "mechanical" branch of our GitHub repository:
3D Model Repository

I'd like any submissions to conform to the following requirements:

Submissions

The best procedure for making your submissions to the repository is this:

  1. Create an account for GitHub if you don't already have one.
  2. Log into your GitHub account.
  3. If you don't already know how to create a "pull request" on GitHub, read this explanation of how to do so.  Basically, you want to upload your files to the "2D-CAD" or "3D-models" folder (whichever is appropriate) of the mechanical branch of the Virtual AGC GitHub repository.  GitHub will then ask us to approve the operation, which we presumably will if the requirement described above are met.

Digital Simulation of the AGC Electronics

Surprisingly, digital simulation of the electronics turns out not to be incredibly difficult.  Nevertheless, discussion of the topic can be rather involved, so to keep this page relatively short (really!), a separate page is devoted to discussing digital simulation.

Basic Partitioning of the AGC Electronics

The Block II or LM AGC contains two trays of electronics, the A-tray and the B-tray.


The trays contain connectors allowing A to be connected to B, or vice-versa, and to the outside world.  Each tray also contains a "backplane" into which electronics modules can be plugged.  The A-tray modules have designations like A1, A2, ..., A31, while the B-tray modules have designations like B1, B2, ..., B17.

Each of these modules has an associated drawing.  For example, in the 2003200-011 AGC, module A1 (the "scaler" module) has electrical drawing 2005259A.  In other words, each module is considered to comprise a single circuit, with a unique (though possibly multi-sheet) drawing.

Modules A1 - A24 consist entirely of "logic": i.e., their electrical drawings consist entirely of NOR-gates and the connectors for plugging the modules into the backplane.    For this reason, I suppose, the drawings aren't called "schematics", but are often given the special name "LOGIC FLOW DIAGRAMS".  But they're schematics anyway.  Modules A25 - A31 and B1 - B17 are entirely analog in nature and are specifically called "SCHEMATICS".

As far as the construction of the circuitry is concerned, three basic techniques were intermixed:

Module with nickel-ribbon logic



Of course, these details don't matter much in modern terms unless you're very enthusiastic about building an AGC re-creation and want to do it absolutely 100% authentically.  If you were, you would be defeated in the end by the fact that the electronic components originally used, such as the dual triple-input NOR gates, are no longer available in precisely the form they were originally used.  And while I haven't priced ferrite memory lately, I expect that it's probably not terribly cost-effective.    Though, surprisingly, you can get junked ferrite-memory systems from eBay; not from the AGC, naturally, but perhaps close enough that they could be made to work if mined for parts.

The pictures in this section, taken by Mike Stewart, are of Jimmie Loocke's model 2003100-071 AGC, s/n 14.

Supplemental Information for the Block I AGC


Some modules in an actual 1003700-011 AGC.  (Click to enlarge.)


Module Description
Related ND-1021041 Figures
A1 - A16: Logic Flow Bit
A17: Logic Flow C
A18: Logic Flow B
A19, A39: Interface
A20, A40: Interface
A21: Logic Flow S
A22: Logic Flow P
A23: Logic Flow E
A24: Logic Flow R
A25: Logic Flow Q
A26: Logic Flow J
A27: Logic Flow D
A28: Logic Flow N
A29: Logic Flow V
A30 - A31: Logic Flow H
A32: Logic Flow F
A33 - A34: Logic Flow G
A35: Logic Flow A
A36: Logic Flow T
A37: Logic Flow L
A38: Logic Flow M
A39: Interface
(See A19)
A40: Interface
(See A20)
B2 - B4: Power Switch Module
B5: Filter
B6: AGC Clock Osc
B7: Driver Service
B8: Current Switch
B9: Erasable Memory Stick
B10 - B11: Erasable Drivers
B12: Power Supply Control
B13 - B14: Erasable Sense Amplifiers
B21 - B24, B28 - B29: Rope Memory
B26 - B27: Rope Sense Amplifiers
B28 - B29: Rope Memory
(See B21 - B24)
B30: Rope Strand Select
B31: Strand Gate
B32 - B33: Rope Driver


Supplemental Information for the Block I Main and Navigation DSKY


   
Internal views of a 1003563-051 AGC.  (Click to enlarge.


Module Description
Related ND-1021041 Figures
D1 - D3: Decoding
D4 - D6: Decoding
D7 - D10: Relays
D11 - D14: Relays
D15: Power Supply
D16: Power Supply
D17: Keyboard
D18: Keyboard

Supplemental Information for LM/Block II AGC p/n 2003100-021

This is an interesting version of the AGC, in that the logic circuitry was constructed in a very different fashion than later dash numbers of 2003100 (and the later versions 2003200 and 2003993) were.  Those later versions used multi-layer printed circuit boards to hold the integrated circuits, whereas this version interconnected them via a nickel ribbon.  The nickel-ribbon design turned out to have too much capacitance, resulting in excessive signal delay, and the design didn't function in practice.  This is what resulted in the introduction of multi-layer printed circuit boards instead.  That's not to say, of course, that there's anything wrong with the electrical schematics for this design, since the physical construction of the circuitry is basically outside the scope of the electrical schematics.  I'm told that all existing functional 2003100 AGC units are of the multi-layer printed-circuit variety.

In addition to the nickel-ribbon interconnect, the circuitry for the various modules was actually divided into four separate "quadrants" of circuitry, which were mostly rather independent but did have some interaction with each other.  Later designs removed the concept of quadrants altogether.

Besides the reference sources mentioned earlier, AC Electronics document ND-1021043 of March 10, 1966, supposedly relates to AGC p/n 2003100-021 (according to its Tables 3-I and 7-I), and its Table 8-II lists all of the associated module drawings.  But I don't believe there are any differences between the circuitry it presents and that presented by ND-1021042.

Finally, there's the question of "signal wiring diagrams".  These are related to the nickel-ribbon interconnect described above. To understand what that is and how to read one, consult the Appendix.  It should be noted that because of the later reworking of the design to replace the nickel-ribbon interconnect with a multi-layer printed circuit board, the reference designators and pin numbering from later versions is not closely related to numbering of this version of the design.

Supplemental Information for LM/Block II AGC p/n 2003200

Module Description
Related ND-1021042 Figures
A1: Scaler Module
4-120
A2: Timer
4-119, 4-120, 4-122, 4-159
A3: S Q Register and Decoding
4-122, 4-128, 4-129, 4-131, 4-132, 4-221
A4: Stage Branch Decoding
4-130, 4-131, 4-132, 4-134, 4-135, 4-136, 4-152, 4-153
A5: Cross Point Generator I
4-132, 4-134, 4-135, 4-147, 4-156
A6: Cross Point Generator II
4-134, 4-135, 4-153, 4-200, 4-207
A7: Service Gates
4-134, 4-143, 4-144, 4-145, 4-146, 4-148, 4-149, 4-152, 4-153, 4-153B, 4-155, 4-175
A8: 4 Bit Module
4-142, 4-153A, 4-208
A9: 4 Bit Module
4-142, 4-153A, 4-175
A10: 4 Bit Module
4-142, 4-153A, 4-175
A11: 4 Bit Module
4-142, 4-175
A12: Parity and S Register
4-122, 4-136, 4-142, 4-149, 4-150, 4-154, 4-155, 4-157
A13: Alarms
4-120, 4-124, 4-159, 4-166, 4-221
A14: Memory Timing and Addressing
4-141, 4-142, 4-155, 4-166, 4-200, 4-206, 4-207, 4-208, 4-218
A15: RUPT Service
4-133, 4-141, 4-142, 4-153C, 4-155A, 4-163, 4-209
A16: In/Out I
4-172, 4-176, 4-178, 4-179
A17: In/Out II
4-155, 4-172, 4-174, 4-177, 4-178, 4-185
A18: In/Out III
4-120, 4-124, 4-172, 4-173, 4-181, 4-186, 4-190, 4-218
A19: In/Out IV
4-120, 4-124, 4-178, 4-182, 4-183, 4-184, 4-187, 4-189
A20: Counter Cell I
4-164
A21: Counter Cell II
4-133, 4-164, 4-221
A22: In/Out V
4-159, 4-180, 4-187, 4-190
A23: In/Out VI
4-120, 4-153C, 4-172, 4-175, 4-178, 4-186, 4-189, 4-190
A24: In/Out VII
4-120, 4-122, 4-124, 4-135, 4-153B, 4-159, 4-165, 4-166, 4-171, 4-175, 4-178, 4-190
B7: Oscillator
4-118
B8: Alarms
4-170

Supplemental Information for LM/Block II AGC p/n 2003993


Module Description
Related ND-1021042 Figures
A1: Scaler Module
4-120
A2: Timer
4-119, 4-120, 4-122, 4-159
A3: S Q Register and Decoding
4-122, 4-128, 4-129, 4-131, 4-132, 4-221
A4: Stage Branch Decoding
4-130, 4-131, 4-132, 4-134, 4-135, 4-136, 4-152, 4-153
A5: Cross Point Generator I
4-132, 4-134, 4-135, 4-147, 4-156
A6: Cross Point Generator II
4-134, 4-135, 4-153, 4-200, 4-207
A7: Service Gates
4-134, 4-143, 4-144, 4-145, 4-146, 4-148, 4-149, 4-152, 4-153, 4-153B, 4-155, 4-175
A8: 4 Bit Module
4-142, 4-153A, 4-208
A9: 4 Bit Module
4-142, 4-153A, 4-175
A10: 4 Bit Module
4-142, 4-153A, 4-175
A11: 4 Bit Module
4-142, 4-175
A12: Parity and S Register
4-122, 4-136, 4-142, 4-149, 4-150, 4-154, 4-155, 4-157
A13: Alarms
4-120, 4-124, 4-159, 4-166, 4-221
A14: Memory Timing and Addressing
4-141, 4-142, 4-155, 4-166, 4-200, 4-206, 4-207, 4-208, 4-218
A15: RUPT Service
4-133, 4-141, 4-142, 4-153C, 4-155A, 4-163, 4-209
A16: In/Out I
4-172, 4-176, 4-178, 4-179
A17: In/Out II
4-155, 4-172, 4-174, 4-177, 4-178, 4-185
A18: In/Out III
4-120, 4-124, 4-172, 4-173, 4-181, 4-186, 4-190, 4-218
A19: In/Out IV
4-120, 4-124, 4-178, 4-182, 4-183, 4-184, 4-187, 4-189
A20: Counter Cell I
4-164
A21: Counter Cell II
4-133, 4-164, 4-221
A22: In/Out V
4-159, 4-180, 4-187, 4-190
A23: In/Out VI
4-120, 4-153C, 4-172, 4-175, 4-178, 4-186, 4-189, 4-190
A24: In/Out VII
4-120, 4-122, 4-124, 4-135, 4-153B, 4-159, 4-165, 4-166, 4-171, 4-175, 4-178, 4-190
A25 - A26: Interface
4-191, 4-218, 4-225, 4-227
A27 - A29: Interface
4-192
A30 - A31: Power Supply
4-219B, 4-220B
B1 - B6: Rope Memory
4-210, 4-211, 4-212, 4-213, 4-214
B7: Oscillator
4-118
B8: Alarms
4-221
B9 - B10: Erasable Drivers
4-202
B11: Current Switch
4-202
B12: Erasable Memory
4-205
B13: Sense Amplifier
4-204, 4-205
B14: Sense Amplifier
4-215, 4-216
B15: Strand Select
4-210, 4-215
B16 - B17: Rope Driver
4-211, 4-212, 4-213, 4-214

Supplemental Information for Block II DSKY

Module Description
Related ND-1021042 Figures
D1 - D6: Indicator Driver
4-225, 4-226, 4-227, 4-229, 4-230, 4-231
D7: Power Supply Module
4-232
D8: Keyboard Module
4-224

Appendix: Evolution of Block II AGC Part Numbers

The way different part numbers of AGCs (or DSKYs) are related to one another is that you start with a given assembly with a certain part number (such as Block II AGC with p/n 2003100-011), then you apply an Engineering Change Proposal, or ECP for short, such as ECP 322 (described as "computer wiring changes"), with the result that you now have a different assembly p/n 2003100-021. 

The list below shows how all known Block II AGC part numbers are interrelated according to the principle just mentioned.  Many of these changes clearly are not electrical in nature, or else refer to intermediate or test versions of the AGC.  Sometimes there are multiple paths to get to the same part number, if the ECPs are applied in different orders.  For example, p/n 2003993-061 + ECP 815 = p/n 2003993-071 + ECP 719 = p/n 2003993-111.  I've only bothered to show one such path below in the few cases where that happens.

Note that there is also an ECP 483 for p/n 203993 listed in Table 8-II of document ND-1021042 (from which the information above came), but I haven't been able so far to find out what it is, nor at what dash number of 2003993 it became effective.

Electronics Component Part Numbers and their SCDs

We don't have an official document, in so far as I am aware, giving the Instrumentation Lab's part numbers for electronics components like resistors, capacitors, transistors, and so on.  Many of them are deducible from other documents, like the AGC Handbook drawings.  For example, from drawing 2005952-, we can find out that part number 1006750-32 is a 1/4W 1K resistor with a 2% tolerance, while part number 1010406-7 is an 8.2 μH 10% tolerance R.F. coil.  Mike Stewart (thanks, Mike!) has done a lot of that for us, but the task is still incomplete.


The list above may not be fully up-to-date with respect to the master list, which is actually in our GitHub repository.  If you have corrections or additions to this table, I believe you can edit the table directly in GitHub, though your changes won't go live unless we approve them.

In addition to the raw list of part numbers above, we have the Specification Control Drawings (SCDs) for most of them.  In modern terms you can think of the SCD as being like the data sheets for the components, except that instead of being written by the manufacturers, they are Instrumentation Lab drawings, and serve roughly the same purpose.  We have most of the SCDs in multiple revisions, so if you're interested in that kind of thing, you can see how the specifications evolved over time.  If you want to see them, look on our AGC engineering-drawing index page.

Appendix: Signal Wiring Diagrams for the Block II and the NOR-Gate Problem

This section describes an issue that affects only so-called "logic flow diagrams" (rather than analog-circuitry schematics), and only early Block II AGC models and CDUs.

First, an elementary introductory digression, for anyone who isn't an electronics expert but has persevered in reading to this point.

When designing electronic circuitry, it is customary to assign each electrical component in the circuit a unique "reference designator" (or "refd", pronounced REF-DEE, for short), and to refer to the components by those refd's.  The refd's can be anything, but customarily they consist of a letter to indicate the general type of component — R for resistors, C for capacitors, D (or perhaps CR) for diodes, and so on — followed by a number to indicate which specific component it is within the circuit.  For example, in the typical kind of circuit diagram shown to the right, you see resistors R1 through R7, capacitor C3, transistors Q1 through Q3, and so on.

Integrated circuits (IC's) typically have U as the alphabetical prefix, thus you might have integrated circuits U1, U2, U3, etc.

One thing that happens sometimes is that a given component might actually be a conveniently packaged-together collection of several essentially interchangeable simpler parts.  For example, a "dual NOR gate" integrated circuit would be a device that provides two separate NOR gates, which are independent of each other but are packaged together to save space or cost or for some other reason of convenience.  When that happens, the overall integrated circuit still has a U-based refd, perhaps U3, but the two NOR-gates comprising it each have refd's of their own, which would normally be U3A and U3B.

The example of a NOR-gate wasn't chosen arbitrarily. In fact, since integrated circuits were a pretty new development during the early Apollo Program, and were still suspiciously unreliable and quite expensive, the AGC circuitry originally didn't use any of them.  Eventually, though, the relentless pressure to miniaturize forced integrated circuits into the design.  As it happens, the AGC ended up using a single type of integrated circuit (the DSKY used none at all), though it used lots of them.  As you've probably guessed, that one type of IC was in fact a dual triple-input NOR gate.

(Actually, that's a bit of an over-simplification, though it's largely true for our purposes.  In fact, the Block II AGC used dual NOR gate integrated circuits, as stated, but the Block I AGC used integrated circuits containing a single NOR-gate each.  Besides that, the sense amplifier modules used comparatively small numbers of sense-amplifier integrated circuits, whose internal composition is depicted in the figure to the right.  The sense amplifier integrated circuit was exactly as complex as a dual triple-input NOR gate integrated IC, in that each of them contained 6 NPN transistors and 8 resistors ... which is just an interesting factoid and is neither here nor there.  For the purposes of our present discussion, neither the Block I NOR gates nor the sense-amplifier ICs are of any relevance whatever.)

I won't bore you by telling you about the general properties of NOR gates, but to understand the discussion in this section you do need to know a couple of different things about them.  Firstly, in the AGC schematics a NOR gate is symbolized either as



and secondly, all of the three inputs of a NOR gate are interchangeable, in the sense that if you swapped any two of them, the behavior of the device would remain the same. (I suppose it may also be worth noting that of the two NOR-gate representations above, you can have two of the left-hand kind as the A and B parts of a dual NOR gate, or two of the right-hand kind, but not one of each.)

What this is all leading up to is that some of the CDU and early AGC (p/n 2003100 only) electrical schematic drawings:
  1. Do not list any ref's for NOR-gates, so we have no way of knowing from the schematics which individual NOR gate is packaged with any other into a dual-NOR IC; and
  2. Do not list any pin numbers for the NOR-gate inputs, so we have know way of knowing which of the interchangeable inputs any given input signal is hooked up to.

To get a sense of this, to the right there are two versions of a sample (nonsense) circuit consisting of NOR gates, one with refd's and pin numbers, and one without.  In the right-hand version, we know, for example, that pin U1A-J is connected to pins U1B-F, U2A-F, and U2B-F.  In the left-hand version we know that the output from one NOR gate is connected to some input or other on each of the other NOR gates.  Imagine trying to repair or discuss the left-hand version!

As far as the operation of the circuit is concerned, of course, it makes no difference at all whether or not those refd's or pin numbers are there, because all of the NOR gates are interchangeable and all of the inputs to them are interchangeable, so the OUTPUT we get from any given INPUT is still exactly the same.

In the same way, you personally may not care one way or the other which specific NOR gate is used for any given purpose in the AGC circuitry, nor may you care which input pin is which on those NOR gates.  If that's so, you don't need to read any further ... just go back to looking at the schematics presented above on this page and enjoy!

But the truth is that the original AGC developers did care which NOR gate was which and what pin number was what ... it's just that for some reason they didn't find it convenient to put that information directly into some of the schematic diagrams for AGC p/n 2003100, and hence they chose to provide it through some other mechanism.  That mechanism is the so-called "signal wiring diagram", and each of the schematic drawings in the AGC 2003100 containing NOR gates had an associated signal wiring diagram.  Below, there's a "typical" (actually, slightly more legible than usual) portion of a signal wiring diagram:

You may be forgiven for thinking that this makes the situation even more confusing to deal with, particularly since you are quite correct about it, but it helps if you know how to read it!  When you know how to read it, it tells you which NOR-gates are paired into which in the dual NOR-gate IC's, which of the pair is the "A" member of the duet and which is the "B" member, and which pin numbers the signals are hooked up to.

It doesn't tell you exactly how to specify the refd's of the dual-NOR IC's, but we know from other versions of the AGC roughly how they did that, so we'll talk about that later.

The first thing to notice is that one side of the diagram is marked as LEFT and the other as RIGHT.  In this drawing, LEFT is at the bottom and RIGHT is at the top, but in other drawings that's reversed, so try to think only of LEFT and RIGHT instead of bottom and top.

Next, notice the little numbers written along the LEFT or bottom edge (39155, 39145, 39149, ...) and RIGHT or top edge (39156, 19151, 39152, ...).  Those numbers are actually written on the NOR gates in the schematics, in lieu of refd's, and each individual NOR gate is identified uniquely by these numbers.  These are called "gate numbers".  So, a pair of such gate numbers could uniquely specify a dual-NOR gate.  The RIGHT numbers are the "A" NOR gates, and the numbers opposite them on the LEFT are the associated "B" NOR gates within the same dual NOR IC. 

Before talking about the other stuff written on the diagram, let's talk a little more about the dual-NOR ICs.  The AGC's were 10-pin rectangular packages, with the pins on them variously labeled either numerically or alphabetically, depending on the purpose of the discussion.  We might draw it like so, with the "A" NOR gate on the left and the "B" NOR gate on the right:


Ignore the fact that the NOR gates now look like little rocket ships; that may or may not be significant.  Rather, the important things to note are that there are VCC and GND inputs to power the device, that the "A" gate has pins 1-4 (or J, A, B, C), and that the "B" gate has pins 6-9 (or D, E, F, K).

If you look along the bottom (LEFT) edge of the signal wiring diagram, you'll see a repeating pattern (from left to right) consisting of

  1. a small square
  2. an even smaller circle
  3. empty position
  4. empty position
  5. empty position
  6. an oval with a number inside
Similarly, along the top (RIGHT) edge of the signal wiring diagram, you'll see a similar but slightly less regular pattern of 6 positions:
  1. small circle
  2. empty position
  3. empty position
  4. empty position
  5. position with several possible markings
  6. position with several possible markings
What those represent in terms of the dual-NOR IC are:
    1. pin 10 (VCC)
    2. pin 9 (K), the output
    3. pin 8 (F), an input
    4. pin 7 (E), an input
    5. pin 6 (D), an input
    6. a position unrelated to the dual-NOR
  • RIGHT
    1. pin 1 (J), output
    2. pin 2 (A), an input
    3. pin 3 (B), an input
    4. pin 4 (C), an input
    5. a position unrelated to the dual-NOR
    6. a position unrelated to the dual-NOR
You'll note that for both LEFT and RIGHT, the sixth position has nothing to do with the NOR gates, in some signal-wiring diagrams you'll find that what we're calling position 6 here actually appears at position 1 and the other positions are simply displaced downward by 1.  That won't affect our discussion at all, and in fact you might not even notice it if it hadn't been pointed out to you, so we'll just ignore that nicety.  We'll get to what those non-NOR things are later, but the point to understand right now is that 9 of each dual-NOR's 10 pins appear in a regular manner along these edges, and are easily associated with their gate numbers.  (Pin 5, GND, isn't explicitly shown on the diagram, and we won't worry ourselves about it.)

What about those weird, snake-like horizontal lines running lengthwise along the middle of the signal wiring diagram?  Wires!  Where the wire points downward, there's a connection along the bottom edge of the diagram, whereas when it points upward there's a connection along the top edge of the diagram.  In the image below, I've added some false coloring to just one of those snakelike lines to focus the attention on it:

So according to the description I just gave, the wire makes a connection to the following:

Now, if you know anything about electronics, you may be worried that the outputs of two different NOR gates are tied together.  Don't worry, though, these NOR-gates have open-collector outputs (or more precisely, open-collector with a pullup resistor to VCC), and so they can be tied together to increase their drive capacity (or to effectively increase the number of NOR inputs for a single output) without any problem.

Perhaps I should finally say what some of these non-NOR markings along the edges are:

At any rate, the point is that this red wire represents two NOR-gates tied together to drive connector pin 111.  Now, I didn't mention it before, but this signal wiring diagram happens to be from sheet 1 of drawing 2005061D, and if we look at that drawing, we will indeed find that connector pin 111 is being driven by NOR gates 39107 and 39155.

What is this "inter-quadrant" thing of which I spoke, and for that matter, what is a "quadrant" anyway?

For these AGC modules, the connector from the module to the AGC backplane has 4 rows of 69 pins each (numbered 1 to 71, but with 21 and 51 missing).  Each one of those rows of pins essentially has its own circuit associated with it, and these separate circuits are called "quadrants".  The concept of the "quadrant" was used only for early dash numbers of the 2003100 AGC (such as the one we have schematics for!), and disappeared for later 2003100 versions, and for the 2003200 and 2003993 AGC's, though much of the numbering of components on the schematics remains tied to the quadrant concept even if the quadrants themselves disappeared.

By "separate circuits", I mean logically separate rather than physically separated onto different circuit boards, though apparently that was originally what was tried.  And usually, the circuitry on the quadrants isn't entirely logically independent of the circuitry on the other quadrants, and in that case there have to be one or more electrical connections between the quadrants of the module ... i.e., inter-quadrant connections.

In fact, the signal wiring diagram I've been showing you isn't the complete diagram for drawing 2005061D, but simply the signal wiring diagram for quadrant 1 of 2005061D.  There are three other quadrants, and therefore 3 other signal wiring diagrams for this module as well.  Most modules have a complete complement of 4 quadrants, and thus have 4 signal wiring diagrams associated with them.  But some modules have less quadrants and therefore less signal wiring diagrams.

So now all of the questions are answered except for refd's.  For that, I want to direct your attention just above the row of gate numbers at the bottom edge of the signal wiring diagram shown above, or just below the row of gate numbers along the top edge.  You'll see a row of tiny, tiny numbers going from 1 (at the left) to 180 (at the right) there.  Or more accurately, you'll see rows of tiny smudges that may or may not be numbers, but you can still see that there are 180 of them.  Let's call these things "smudge numbers", for lack of a better term.  The IC's are numbered sequentially, starting at the end with the larger smudge numbers, where we find U01, and moving toward the end with the smaller smudge numbers, where we find U30.

Actually, there's some subtlety involve here.  For example, what happens if there's an open space, as there is in our pictured signal wiring diagram at U23?  Should we just skip U23 in our numbering altogether, or should the next position become U23 rather than U24?  You could argue it either way, but I'd vote for skipping U23 altogether, because it helps preserve IC numbering across different hardware versions.  In other words, if a dual-NOR is removed or added, it won't necessarily cause all of the refd's for the other dual-NORs to change.  But truthfully, we don't actually know what the original designers did in this regard.

Another subtlety in the IC numbering is the quadrants:  The entire circuit module consists of 4 quadrants, and if we followed the scheme just described, there would be 4 IC's labeled U01, 4 labeled U02, and so on.  Not good!  So in our CAD work we actually prefix the quadrant numbers to the IC numbering.  In other words, in quadrant 1, the IC's run from U101 up to U130; in quadrant 2, the IC's run from U201 up to U230; etc.  Thus every IC ends up with a unique number within the module, and we can still use that number to precisely identify where it is located physically.

And finally, one last subtlety:  Some of the quadrants have signal wiring diagrams as shown, with LEFT on the bottom, RIGHT on the top, and smudge numbers increasing from left to right.  Other quadrants are reversed, with RIGHT on the bottom, LEFT on the top, and smudge numbers increasing from right to left.  My descriptions above are all still correct, as long as you keep thinking of LEFT and RIGHT and ordering of smudge numbers as I've urged, rather than thinking of the top, bottom, right, and left edges of the signal wiring diagram as you might otherwise be inclined to do.  The reason for this reversal seems to have to do with some of the quadrants being on the front side, and some being on the back side, with the numbering consequently mirror imaged.

Appendix: Signal Wiring Diagrams and the Block I AGC

For the Block I AGC, problems similar to those described in the preceding section exist, though the problems and solutions are different in detail.  In fact, read the preceding section before reading this one so that you can have some background for the discussion in this section!

One problem that can thankfully be ignored in the Block I AGC is that the NOR-gate integrated circuit contains a single triple-input NOR gate, packaged in a TO-47 can, rather than two independent NOR gates packaged together in a flatpack, as in the Block II AGC.  That simplifies a lot.  You can see both a photo of such a gate (to the left) and a diagram elucidating its pinout and internal circuit (to the right).

A problem the Block I "logic flow diagrams" (schematics containing NOR gates) have that the Block II doesn't have, is that there were apparently multiple hardware generations of the Block I AGC that were mechanically quite different.  In particular, both the backplane-connector pin numbers and the means for identifying the NOR-gate components differed from one hardware generation to the next.  The schematic diagrams, meanwhile, showed the connector pin numbers and gate identification for multiple hardware generations, thus making them a tad more confusing than they might have been otherwise.

We don't actually know much about these different hardware generations, but here's our current thinking on the subject.  We think there were three separate Block I AGC hardware generations, which may have differed as follows:

For example, in the tiny excerpt from one of the Block I electrical schematics to the left, consider the NOR gate with the markings "2G5" and "65129".  "2G5" was how the gate was identified in generation "AGC 4", while "65129" was how it was identified in generation "AGC 5", according to the notes (not shown) written in the schematic itself. 

Similarly, consider the connector pin for the backplane signal "MPO".  It is marked both as pin #94 and as pin #104. The former is for AGC 4, while the latter is for AGC 5.

However, the Block I AGC schematics have the same characteristics as the early Block II schematics, in the sense that they do not display pin numbers for the (interchangeable) inputs of the NOR gates, nor do they indicate what we would think of as reference designators for the NOR gates.  Of course, since there's was a single NOR gate per integrated circuit, the gate-number markings (like "2G5" or "65129) could basically serve double-duty as reference designators, and having a separate reference designator doesn't really serve much purpose, so perhaps there weren't any at all.  Plus, each of the NOR gates in the example to the left has a single input ... but from the figure above, we know that pins 1, 3, and 5 of the NOR gate were all interchangeable, so which input is the one being used?  They probably are not all the "middle" pin, pin #3, since that wouldn't always have been the pin it was most convenient to physically route a wire to. 

At any rate, since the schematic doesn't have this kind of info in it, the information has to come from somewhere else.  It must instead be deduced instead from the so-called "wiring diagrams".  These Block I wiring diagrams, however, though quite similar in concept were quite different in detail from the Block II signal wiring diagrams described in the preceding section.  The image below is a wiring diagram for the Block I "scaler" module, otherwise known as AGC modules A33 and A34.  (Identical modules were plugged into slots A33 and A34.)  The wiring diagram itself is drawing 1006127A, while the corresponding electrical schematic drawing is 1006547G.  The original drawing was in black&white (at least, by the time we got it), but I've added various color notations to it for the purpose of this discussion.


(Click to enlarge)

Perhaps the first thing to note is that there are two separate circuits in this wiring diagram.  There's the "even" half, depicted on the left-hand side of this diagram, consisting of the columns labeled
     
and the "odd" half (the right-hand side of the diagram), with columns labeled
     
Of those, 2 and 3 are intended to represent the front sides of the circuits, while 4, 6, 5, and 7 (being mirror imaged) represent the back side of the circuits.

These two halves are independent of each other, in the sense that the only electrical connections between the two are via the backplane.  In other words, if you wanted to connect a signal in the left half of the circuit to one in the right half, the signal would have to go out through the module's connector, onto the AGC backplane, then back up into a different pin on the module's backplane connector.  There is a 142-pin connector (two rows of 71 pins each) to the backplane, with the the even half of the circuit using the even-numbered pins and the odd half using the odd-numbered pins, and in the diagram the connector pins are also depicted as circled numbers like


Each the two halves has 60 NOR gates, labeled in the diagram both by a "CIRCUIT NUMBER" and a "POSITION NUMBER", and are depicted in the diagram as objects like
   or  

The former are the normal NOR gates, while the latter are the so-called "expander" or "fan-in" NOR gates, represented in the electrical schematics by the following two symbols, respectively:

As you can see, each of these NOR gates has 4 signals, as it is supposed to, with the open circle being the output and the solid circles being the three inputs.  As as far as which of the filled-in black circles represent which inputs to the NOR gates, we don't actually have enough information about how the wiring diagrams are interpreted to be able to tell.  On the basis of the fact that these circular objects visually represent the bottom side of the NOR-gate TO-47 cans (see the figure at the top right of this section), my interpretation would be:

Of course, a mirror image of this arrangement, or indeed any other permutation of pins 1, 2, and 3 would logically be equally possible.

Note too that some or all of the NOR-gate pins have solid black lines going to them, and of course these represent the wires.  All of the fat, solid, black lines in the wiring diagram are wires.

The final factoid needed to interpret the diagram is to note that each of the circuit halves seems to have wires that exit to the left or to the right, and then just stop in mid-air, so to speak, without actually connecting to anything. Notice, however, that the wires exiting to the left and the right are exactly paired with each other: for each wire exiting to the left, there's one at the exact same position vertically exiting to the right.  This is intended to mean that those two dangling wires are connected together as the same signal.  I've added a couple of blue lines to the diagram to make this point graphically.

Actually, to avoid being misleading, I should admit that it's a little trickier than this sometimes.  The true is that there's not necessarily a unique match between the dangling wires exiting to the left and those to the right, so sometimes you have to work it out using the schematic as a reference.  The figure below is an excerpt from a different signal-wiring diagram that shows this ambiguity.  I can't really give you any advice on resolving such ambiguities, other than to say that if you trace through the wires, you'll (hopefully always) find that one of the possible connections makes no sense with respect to the associated schematic, and that the other one does.

Ignoring complications like that, which are fortunately in the minority, let's work out an example in detail.  Consider the NOR-gate with CIRCUIT NUMBER "--039" at POSITION NUMBER "02" at the upper left of the wiring diagram.  (You'll have to click on the wiring diagram image shown earlier to expand it, in order to understand the description below.)  In the wiring diagram, we see that:

So ... how well does this correspond to what the corresponding electrical schematic drawing, 1006547G, says is supposed to be happening?  Well, wonder no more!  Here's the relevant excerpt from the schematic, and as you can see, it is exactly as our interpretation of the wiring diagram says it ought to be:



But finally, a word of caution:  The match between electrical schematics and their associated signal wiring diagrams is not always as perfect as the explanation above implies.  Of course, the Apollo Program preceded the availability of computerized CAD systems which could have automatically generated error-free signal wiring diagrams (if they were even needed at all!) directly from the schematics.  In other words, both the schematics and the wiring diagrams had to be separately, manually drawn ... naturally, we'd expect occasional errors just on that account.  But it's somewhat worse than that.  Consider the example we've been using, namely schematic 1006547 and associated wiring diagram 1006127.  This block of circuitry has NOR-gates labeled "--000" through "--079", plus additional NOR gates in the range "--301" and above.  The schematic and wiring diagram match perfectly for the range 000-079, but completely differ for the range 301+, as if completely different circuits were being described by the schematic and the wiring diagram.  And that may indeed be what happened, since the wiring diagram was drawn in February 1963, some three months prior to the schematic in May 1963. Possibly there had been second thoughts about the partitioning of the circuitry into modules in the interim. Thus where the schematics and wiring diagrams match, we should feel confident in using the information we find in the wiring diagrams to supplement what we find in the schematics, but we need to be aware that they may not match, and that we must be prepared to work from whichever one of those two is "correct".

All very well and good!  But how do we know which, if either, is correct?  I suppose I'd generally vote for the schematic, if only because the wiring diagram is a much less satisfactory way of visualizing how the circuit works.  This is particular example of drawings 1006547 and 1006127, though, there are lots of circumstantial factors that would make us choose the schematic over the wiring diagram:
  • The schematic was drawn 3 months later than the wiring diagram, and is therefore more current.
  • We have 2 revisions of the wiring diagram vs 8 of the schematic, so gross errors seem less likely to have survived in the schematic than in the wiring diagram.
  • The documentation in AC Electronics ND-1021041 matches the schematic rather than the wiring diagram.

Appendix: Auxiliary Software

Introduction

Along with the various scanned engineering drawings, CAD transcriptions, drawing indexes, assembly drilldowns, and engineering-drawing search engine we provide, there's also a certain amount of software available to help create and maintain all of that data.  Most of it is undoubtedly of little use to anybody not intimately involved in such maintenance.  But there are a few programs, such as the drilldown.py and drilldownCompare.py programs already described above, that can be of slightly wider (though still very specialized) utility. 

On that chance, this Appendix provides a very-brief rundown of some of that additional software.  Except where otherwise stated, such software is generally found in the software repository's "schematics" branch, in the Scripts/ folder, so you can likely find programs there that  I choose not to mention here.

Program
Brief Description
More Information
Context:  Transcription to KiCad of G&N electrical schematics
MakeConnector.py Creation of custom KiCad schematic symbols for connectors. As far as how to specify the characteristics of a particular connector configuration, see the comments in the code itself.  What the program actually creates is a KiCad .lib file that contains the definition of the connector.  In current practice I treat that .lib file as being temporary, because I then use KiCad's symbol-library editor to "import" that symbol from that .lib file into the "AGC_DSKY" symbol library, and then delete the .lib file itself.  See also the explanation of connectors in the README.
MakeDualNorLib.py Creation of custom KiCad schematic-symbol libraries for NOR gates. As far as how to specify the NOR gate library to be created, see the comments within the code itself.  Most variations relate to the (hardcoded) power-supply and return signal names, though there are additional configurable items such as expander vs non-expander, display of pin numbers vs no display of pin numbers, numerical pin numbers vs alphabetical pin numbers, and Block II vs Block I vs ND-1021041.  What the program actually creates is a KiCad library containing all parts of the multipart symbol, in all variations of ordering of input pins (including missing pins, which are tied to the power-supply return).  The only configuration omitted is that of no input pins — i.e., of all input pins being tied to ground.  (An oversight on my part.)  The library itself should simply be retained permanently along with the other libraries, and is typically named according to the pattern D3NOR-VCC-GND[-OPTIONS].lib.  See also the explanation about libraries in the README, and the discussion of NOR gates as well.
autoplaceKiCad.py Semi-automated placement of connector-pad and NOR-gate symbols into KiCad schematics.
See the extended discussion below
printKiCad.sh Creation of PNG images of KiCad schematic sheets. Requires bash (or similar), sed, and ImageMagick.  The schematic sheet is first "plotted" to Postscript format in the KiCad schematic editor, and then the script is run to convert Postscript to PNG.  Any number of Postscript plots can be specified at the script's command line.  The functioning of the script is quite simple:  It uses sed to stylistically correct dashed lines (whose unalterable pitch in KiCad is not consistent with the large physical dimensions of G&N sheets), and then uses ImageMagick to convert the corrected Postscript to PNG.  See also the explanation of printing in the README.
blockAnnotater.py Semi-automated correction of reference designators in KiCad hierarchical schematics to agree with G&N engineering drawings.
See the extended discussion below
eelint.awk Semi-automated correction of artifacts in KiCad schematics, such as wires that are not quite horizontal/vertical or which have short jogs in them. See the extended discussion below
listConnectors.awk Generation of list of captioned connector pads from a KiCad schematic.
See comments in listConnectors.awk, listConnectors.sh, and listConnectorsAllModules.sh
Context:  Verilog-based simulation of Block II AGC electrical schematics.
pins.txt Database of Block II AGC backplane signals
This is created by opening Mike Stewart's pin database in sqlite, and dumping it in CSV format. The options required are:  Space as field delimiter, no quotes around fields, no header line for field names.
bin_to_verilog.py
TBD TBD
dumbInitialization.py Creation of a set of flip-flop initializations.
See the Appendix of the digital-simulation page
dumbTestbench.py Creation of a Verilog test-bench file.
See the Appendix of the digial-simulation-page
dumbVerilog.py Conversion of a logic-flow diagram's netlist to Verilog.
See the Appendix of the digital-simulation page
extractInstructionsFromTIM.awk TBD TBD
extractMikeGates.awk TBD TBD
instruction_trans_decoder.py TBD TBD
makeGateTranslate.sh TBD TBD
netlisterOP2.py TBD TBD
pooh.py (plus normalizedMikeNets.py) TBD TBD
Context:  Verilog-based simulation of Block I AGC electrical schematics
pinsBlockI.txt TBD TBD
pinsDbBlockI.awk TBD TBD
Context:  Customization of engineering-drawing search engine:
tipuesearch.js The principal code for the engineering-drawing search engine.
This code came from Tipue Search, but has been modified to provide customized formatting for search results, and could be additionally or alternately customized for offline usage.  The code itself is here.
tipuesearch_content.js The master engineering-drawing database in JSON format.
Probably the only non-obvious thing thing is that in URLs, the substrings of the form @N@ need to be replaced by prefixes[N].  The code itself is here.
AgcDrawingIndex.py
MakeTipueSearch.py
Creates the engineering-drawing database from index pages (HTML) on the website.
Creation of the master engineering-drawing database is a two-step process, in which the AgcDrawingIndexXXXX.html pages from the Virtual AGC website are processed first by AgcDrawingIndex.py and then by MakeTipueSearch.py.  For more information, refer to the comments in the AgcDrawingIndex.py source code.
unpunch.py Extracts metadata and renames scanned G&N engineering drawings scanned from aperture cards at NARA SW.
This would be useful only to someone who had access to raw scans of boxes of aperture cards.  The code is specific to aperture cards in which the punched metadata conforms to the marking-format printed on the cards themselves (or at least the ones I've seen).  G&N drawings in box range 430-470 (MIT, AC Electronics, Kollsman, ...); I cannot speak for other ranges, but North American Aviation boxes do not conform.  Nevertheless, the idea behind unpunch.py is sound, so if it were altered to a different formatting pattern it could be useful for it as well.  See the extensive comments in the code itself.

Program:  autoplaceKiCad.py

This program assists in semi-automatically placing connector pads and NOR-gate symbols into a KiCad schematic.  It is used if you are transcribing a G&N "logic-flow diagram" into KiCad.  The code itself is here.

In creating a CAD transcription of a G&N "logic-flow" diagram, manual choice of the appropriate connector and NOR-gate library symbols within the KiCad schematic editor (which is called "eeschema") can be quite cumbersome and time-consuming.  The autoplaceKiCad.py program greatly eases and speeds up this process, in my opinion.  As input, the user provides a text file that:

  • Roughly divides the physical area of the schematic diagram into rectangular blocks.
  • For each block, provides a textual description of the connector pads and NOR gates in that block.

The program then does a sanity check to expose duplicated pins or gates, or to find various inconsistencies in pin numbering, inconsistencies in the way individual NOR gates must be combined into dual-NOR gates, etc.  If those checks pass, it outputs a KiCad schematic containing nothing except the specified components.  That operation looks something like this:

autoplaceKiCad.py <INPUT.autoplace >OUTPUT.sch

The user can then:

  1. Add the component data from OUTPUT.sch to his own schematic using a single cut-and-pasted operation with a text editor program.  (Don't cut-and-paste within KiCad itself, or else it will "helpfully" reset all of the reference designators in the pasted block.)   OUTPUT.sch is a complete, valid schematic, so you just cut from the first "$Comp" to the last "$EndComp".  I usually paste just prior to the "$EndSCHEMATC" that appears at the very end the file.
  2. Edit the now-combined schematic with the KiCad schematic editor, into the background of which the original scanned logic-flow diagram has been placed.
  3. Within the schematic editor, manually move each component where it belongs (relative to the background image).

This may sound like a cumbersome operation (and it is!), but experience shows pretty conclusively that it is actually quite a bit faster and far less error-prone than directly manually adding components within the KiCad editor.  At least for me!

IMPORTANT NOTE:  The workflow described above allows autoplacing a bit of the schematic at a time, rather than autoplacing all components in one pass.  That temptation should be resisted.  Sometimes that piecemeal approach is appropriate, but you have to be very careful.  The thing you have to be sure of is that both parts of each dual-NOR are handled in the same autoplacement pass, because otherwise the program will not be able to be able to assign the same library symbol to the two parts.  Piecemeal work also bypasses a lot of consistency checking as well, for things like duplicated parts.  These problems will all be discovered later, of course, if KiCad's design-rule checker is run, but the inconsistencies will be a lot harder to fix manually in KiCad than they would have been in INPUT.autoplace.  So it's safest to just have one big INPUT.autoplace file and to autoplace all of the components in one pass.  You have been warned!

Before continuing, I should probably point out that the scanned image used for the background image in the schematic editor has to be prepared pretty carefully if you want it to be maximally useful.  For one thing, if a sheet of the drawing was scanned in several frames, those frames must be recombined to produce a single unified image. The image must be scaled correctly; for example, if the original drawing is "E" size, then the scanned image must be scaled to be exactly 44"×34".  Moreover, it should be rotated/stretched in such a way that vertical lines are vertical and horizontal lines are horizontal, and that the inner boundary of the drawing's border is 0.5" from the edges of the image.  If the full-resolution scanned image is loaded into the schematic editor, it's probably going to be quite logy, or perhaps even unusable.  So the PPI of the background image should probably be changed (whilst preserving the correct physical dimensions!) as low as you can stand.  Typically, I use 50 PPI, but on some occasions have gone as low as 20 PPI.  I won't trouble you with exact details how to perform each of these steps.   Rather than loading the background image scan into the schematic file, it is actually loaded into the KiCad "template" (*.wks) file for the design, using KiCad's worksheet editor program.  (And removed from it prior to committing anything to GitHub, please since the template file will now be enormous!)

In its simplest form, INPUT.autoplace looks something like this:

W= width
L x y
J pin1
J pin2
J pin3
...
N gate1 loc1 a1 b1 c1
N gate2 loc2 a2 b2 c2
...

This defines a single rectangular block on the schematic, width inches wide, with an upper left-hand corner located x,y inches from the upper-left corner of the schematic.  In OUTPUT.sch, the placed component will appear in rows starting at the top of this block and working downward as each row is filled up.  In other words, it doesn't place the components exactly where they need to go, but just in the general vicinity.  The J and N lines represent symbols to be placed on the schematic, and don't have to appear in the order shown.  Plus, there are other kinds of symbols the program can add that I haven't put into the example.  These symbol lines can be in any convenient order, though the most convenient order in terms of moving the symbols to their proper locations later are going to involved sweeping through the block row-wise, from left to right.

Each J line represents a connector pin (an oval pad) with the associated pin number (pin1, pin2, or pin3 in the example shown). 

Similarly, each N line represents half of a dual 3-input NOR gate.  The associated gate number (gate1 or gate2 in the example) is a 5-digit number written directly on the gate in G&N logic-flow diagrams.  Similarly, the location number (loc1 or loc2) is a 2-digit number written directly on the gate in the diagram.  The gate numbers are all unique, and no specific gate number can recur.  However, the location numbers relate to the chip rather than the gate, and since the chips are dual-NORs, each location number actually appears twice, with two different associated gate number. 

Because these are triple-input NOR-gates, each has 3 inputs.  For the "A" half of the dual-NOR, the pins are labeled A, B, or C, while for the "B" half they are labeled D, E, or F. Thus the pin numbers ("a1 b1 c1" or "a2 b2 c2" in the example) are "A B C" or "D E F" ... but not really!  The original schematics were drawn very flexibly, so that the pins might actually be in other orders, such as "B A C" or "C B A".  But more than that, the pins might be omitted completely in the drawing, with any missing pin implicitly being grounded.  We represent missing pins as ";" or "_", so "a1 b1 c1" could actually be "_ A _" or "C B _".  (When I created the symbol libraries and autoplaceKiCad.py, I neglected to consider that all the input pins might be grounded, "_ _ _", so I don't provide for that case.)

In terms of actual numbers, therefore, our example INPUT.autoplace could perhaps be:
W= 10
L 13.5 1.2
J 153
J 154
J 155
...
N 38125 40 F E D
N 38126 41 F _ E
...
But this just scratches the surface.  In no particular order, here are some of the other variants that can be briefly described:
  • Blank lines or comments (prefixed with "#") are ignored.
  • Multiple "W="/"L x y" blocks can appear in the file, thus tiling the sheet into rectangular blocks, of possibly differing sizes/shapes.
  • J lines represent connector pads (visually, ovals wider than their height) with the wires exiting to the right.  There are also j lines, also connector pads, in which the wires exit to the left.  Similarly, the wires on K pads exit to the bottom and those of k pads to the top.
  • J, j, K, k lines can also have from 1 to 4 optional symbolic labels representing associated backplane signal names.  For example, "j 153 F12B".
  • Rather than an N line, you could use an X line ... which acts the same but specifies an "expander" NOR gate rather than a normal NOR gate.
  • There are also O lines ("oh", not "zero"), not shown in the example, of the form "O netname", such as "O DAS0/".  These place a symbol having just one pin (exiting to the right) that looks like a small open circle with a label next to it.  This is a common way to represent intrasheet connections in G&N schematics.
  • There are also A lines, not shown, of the form "A digits", such as "A 1".  These place a symbol that looks like an up-arrow with a number (digits) in parenthesis above it.  It has no electrical function, but is used in some G&N schematics to indicate how many other points in the schematic sheet are implicitly electrically connected to it, as opposed to being directly connected by a visual wire.  Those other connections are the O lines mentioned above.  Since the associated schematic symbols do not actually enforce any electrical connectivity between the two points, it is necessary to manually add matching KiCad netnames to the wires associated with the symbols for the O and A lines.  That is done in the KiCad editor rather than in the INPUT.autoplace file.
  • If the 2nd field in a J or N line is ".", then the pad number, gate number, or location number simply autoincrements.  Note that autoincrementing connector-pad numbers remain in the ranges Nnn where nn is 01-20, 22-50, or 52-71 (as would be required for Block II AGC logic modules).  Incidentally, for Block II, the format of such an N line changes to "N . n", where n is 1, 2, or 3, and is simply the number of input pins.
  • In addition to N and X lines, it is also possible though rare to have otherwise-similar lines that instead begin with N1, N2, N3, N4, X1, X2, X3, or X4.  This is discussed along with the general "N=" directive below.
Various options can be added to the autoplace file to modify this basic behavior.  Each option appears on a line by itself, and they are typically grouped at the top of the file, prior to any of the "L x y" lines.  Not all of these options have been designed to work in cooperation with each other.  Here are the currently-available ones; they're shown in quotes for clarity, but the quotes aren't used in the actual input files:
  • General:
    • "G= start".  Changes the default starting point (0) for autoincrementing NOR-gate numbers in N lines to start.
    • "P= start".  Sets the starting number for autoincrementing connector pads (defaults to 1).
    • "N= symbol refd" (and N1=, N2=, N3=, N4=).  Sets the schematic-symbol library name (symbol) and the reference designator prefix (refd) used when placing NOR-gates onto the schematic.  The available NOR-gate symbol libraries are named D3NOR-*.lib, and any path or filename extension is omitted in symbol.  The reference designator for any individual NOR-gate is automatically formed by prefixing refd to the gate's 2-digit location code, and refd will be something like "U1", "U2", "U3", or "U4"; thus, the resulting reference designators will typically be of the form U + 3 digits.  This scheme is based on the way the sheets of a typical G&N logic-flow diagram are structured, in that each of the sheets will have 2-digit location codes in the range 01-30, so that it is necessary to have unique prefixes for each sheet to make sure that reference designators are unique as well.  Note, by the way, that an "N=" directive applies to the entire set of N lines in INPUT.autoplace, and not just to the ones that ones that follow it.  Sometimes, though rarely, not all NOR-gates on a given sheet come from the same symbol library.  Sometimes also, though even more rarely, a schematic will have a single sheet in which a combination of U1nn, U2nn, U3nn, and U4nn reference designators appear on the same schematic sheet.  Neither of these latter two rare cases can be implemented using N and N= lines as just described.  For those cases, N1, N2, N3, and N4 lines are provided.  They work exactly like N lines, but essentially provided non-overlapping "namespaces" — i.e., they allow the use of independent library symbols and reference-designator prefixes by means of their own directives "N1= symbol refd", "N2= symbol refd", "N3= symbol refd", and "N4= symbol refd".
    • "X= symbol refd" (and X1=, X2=, X3=, X4=).  Same as above, but for expander NOR-gates.
  • Specific to Block II:
    • "module= moduletype".  This option is primarily used to modify how reference designators are chosen for connector pads, based on the pin numbers.  The choices for moduletype are A52, B1, and B, and the interpretations are: 
      • By default, if this option isn't used at all, connector-pad numbers 101-171 select reference designator J1 (symbol "ConnectorA1-100" in symbol library AGC_DSKY), 201-271 select J2 ("ConnectorA1-200"), 301-371 select J3 ("ConnectorA1-300"), and 401-471 select J4 ("ConnectorA1-400"), which is suitable for all Block II AGC logic modules.
      • B1:  Suitable for modules with pinouts like module B1, namely pads 101-124 select J1 ("ConnectorB1-100"), 201-224 select J2 ("ConnectorB1-200"), 301-324 select J3 ("ConnectorB1-300"), and 401-424 select J4 ("ConnectorB1-400").
      • B: Connector pads 101-169 select J1 ("ConnectorB8-100") and 201-269 select J2 ("ConnectorB8-200").
      • A52:  J1 ("ConnectorA52").  This also has the side effect of changing the NOR-gate pin-numbers to "2", "3", "4", "6", "7", "8" (and "_" or ";").
    • "full71".  As mentioned above,  the default connector type used in the absence of a "module=" directive, is appropriate for a Block II AGC logic module:  4 rows of 71 pins each, with the 21st and 51st pins of each row removed.  If full71 is used, the missing 21st and 51st pins are restored to the default (by instead using library symbols "Connector-100", "Connector-200", "Connector-300", and "Connector-400").
    • "GP= prefix".  As explained above, in each N or X line, the NOR-gate has a 5-digit "gate number" associated with it.  If the leading digits are always the same  — or indeed, if they are not all digits — then this directive can be used to specify what the leading characters are.  It is then only necessary to enter the remaining digits within the N or X line, and the prefixed characters bypass the sanity check.  For example, a gate number of "6_123" would be illegal if appearing directly in an N or X line, because it doesn't consist entirely of digits.  However if "GP= 6_" were used, then just "123" would used as the gate number in the N or X line.  The resulting gate number would still be "6_123", but the result would now be legal.  To use this approach, however, all of the gate numbers would begin with "6_".
    • "noloc".  If this directive used, then the 2-digit location numbers are not visible on the NOR gates.  They are still present, but simply marked internally as being invisible, and can be accessed or visually restored by editing the NOR gate within KiCad.
  • Specific to Block I:
    • "block1".  Indicates an official Block I drawing.  In such circuits, the chips have one NOR-gate each (rather than two), and the input pins are "1", "3", "5" (and "_" or ";" if missing) rather than "A", "B", "C", "D", "E", "F".  Moreover, there were two separate implementations of the circuits, referred to as AGC4 and AGC5, resulting in two separate NOR-gate gate codes and two separate pin numbers for each backplane-connector pad.  The formats in INPUT.autoplace were altered accordingly:  "N loc gateAGC4 gateAGC5 pin1 pin2 pin3" and "J pinAGC4 pinAGC5 signal".  The AGC5 gate codes are the usual 5-digit numbers, but the AGC4 gate codes are like "1F4" or "2D3".
    • "shadow1".  Implies and depends on "block1".  If present, connector pads (J lines) are automatically supplemented by an additional connector pad of identical appearance (but no electrical function) but having a dotted outline.  Such pads are used in some Block I logic flow diagrams to indicate alternate backplane signals.
    • "mirror1".  Implies and depends on "shadow1" and "block1".  Reverses the pin numbering (assuming a 142-pin connector) between a J connector pad and its shadow.
    • "nd1021041".  Overrides "block1".  This is used for schematics recovered from Block I descriptive document ND-1021041, which have various differences stylistically from the official drawings.  Moreover, there are no 2-digit location numbers for NOR-gates in ND-1021041, so N lines become just "N gate a b c".
    • "bit".  Uses 3-digit gate numbers rather than 5-digit ones, and automatically prefixes them with "xx".  This is for schematics of a module that can be plugged into 16 different backplane slots, and in practice applies only to Block I logic modules A1-A16.  If used, then J lines have 16 backplane-signal labels rather than the limit of 4 mentioned earlier.  However, these labels are internal to the CAD and not displayed on the schematic.
    • "dupej".  Some Block I drawings have duplicate connector pads with identical pin numbers.  This not allowed in KiCad, so normally it would be flagged as a fatal error by autoplaceKiCad.py.  There are various non-fatal ways to handle such cases.  One way is the "dupej" option.  If used, whenever a duplicated J line is found, the 2nd instance an onward are replaced electrically by O lines.

Program:  blockAnnotater.py

Also see the explanation of reusable circuit blocks in the README file.

In transcribing Apollo G&N electrical schematics to CAD, we want all component reference designators to match those used in the G&N engineering drawings, and we particularly want reference designators appearing in netlists and electrical simulations to be accurate with respect to the original drawings.  This is not a problem for most transcribed drawings but becomes a problem for some schematics of analog circuitry in which the circuit comprises hierarchical blocks which appear in multiple instances.  For example, suppose the main circuit had a block (let's call it block "P") which is used 5 times.  In KiCad, the natural way to deal with this is a process called "annotation", in which KiCad assigns distinct reference designators to each component appearing in each instance of block "P".  Natural or not, the rules applied by KiCad do not correspond to the reference designators in the G&N engineering drawings themselves.  For example, if there were a resistor that we had called R3 in block "P", KiCad might annotate those 5 instances of the resistor as R3, R101, R201, R301, and R401, whereas the G&N drawings might refer to them as 1R3, 2R3, 3R3, 4R3, and 5R3.  The latter, of course, is what we want.

Working around this problem involves a semi-automated process with several steps:

  1. In the top-level drawing, the hierarchical blocks with multiple instances have to be given sheet names corresponding to the prefixes attached to the reference designators in them.  Usually, these will be sheet names "1", "2", "3", and so on.  In fact, blockAnnotater.py will strip any suffixed non-digit characters from the sheet names, as well as certain prefixes ("--", "xx", "XX") so sheet names like "1P" or "xx5Q" can be used just as easily as "1" or "5", if necessary to more-closely match the appearance of the original drawings.  As for where these numerical prefixes come from, they cannot be deduced from the schematics, but instead have to be pulled from associated engineering drawings for the assembly containing the circuit, such as from photographic masters of insulators, wiring boards, etc.
  2. In the reusable circuit blocks, using the KiCad schematic editor, edit each component, as follows:
    • Add a new field called "baseRefd".  Mark it as visible, and assing its value as the reference designator as shown in the original engineering drawing.
    • Mark its actual reference-designator field as invisible.  Or alternately, perhaps preferably in some ways, leave it visible but assign it a smaller font size and move it close to the visible location of the baseRefd field so that it is clearly subordinate to it.  The image to the right illustrates the latter alternative; in it, markings like Q5 and R13 are the baseRefd field, whereas those like 1Q5 and 1R13 are the true reference designators.
  3. Use KiCad's annotator tool to assign reference designators to the reusable circuit blocks.
  4. Exit KiCad and use blockAnnotater.py to reassign the reference designators which KiCad just assigned.

The actual reference designators assigned in the reusable blocks by blockAnnotator.py are

(prefix derived from parent sheet name) concatenated to (child component baseRefd)

This is the appropriate formula in most cases, but there are a few cases in which the prefixes derived from the parent sheet name simply don't correspond to the chile-component prefixes in the engineering drawings.  A numerical offset can be defined that changes the formula instead to

(prefix derived from parent sheet name + numerical offset) concatenated to (child component baseRefd)

(Notice that the "+" is meant to be a numerical addition.)  The way this is done is by tweaking one of the 4 comment fields of the child schematic.  If any of these comments is changed to

NumberFrom=N

then N is used as a numerical offset to the component prefixes within that child block.

At present, only two levels of drawings (parent + child) are supported, and this has proven sufficient for all G&N schematics encountered so far.  If any three-level drawings (parent + child + grandchild) are ever discovered, the software will need to be reworked.

Regarding the two different options listed above as to how to treat components' true reference-designator fields, both options have arguments in their favor.  If the true reference designators are made invisible, the schematics (and in particular their PNG renderings) will look just like the original drawings.  On the other hand, particularly in editing the CAD files, it obscures the fact that the markings shown are not the true reference designators, as well as obscuring the fact that the different instances of the block have different reference designators.  The choice as to whether or not to display the true reference designators is therefore partially a question of personal aesthetics.

Actual details of usage and additional documentation can be found in the blockAnnotater.py source code.

Program:  eelint.awk

In manually editing G&N schematics in KiCad's schematic editor — and in particular, in adapting an existing CAD file for a different but similar version of the circuit — it's extremely easy to leave it littered with junky-looking constructs such as:

  • Items not aligned to the 25-mil grid we use for G&N drawings.
  • Wires with a tiny inclination to exact horizontal or vertical.
  • Wires with tiny jogs in them.
  • Stray, short wires attached electrically at one end but dangling from the other, sometimes causing spurious junctions (fat dots) to appear.

The program eelint.awk analyzes a schematic to find such problems.  In its simplest form, the program is run as follows:

awk -f eelink.awk INPUT.sch INPUT.sch >OUTPUT.sch

Yes, the input schematic does appear twice on the command line, and it is not a typo.  The script outputs error messages about the problems it has found to stderr, and outputs a completely new schematic file to OUTPUT.sch to stdout.  The input file is not changed at all.  If there are no error messages, then the output file should be the same as the original and can simply be ignored. 

However, if errors are found, then the output file will be like the original but with the addition of markers that have been inserted where the errors are thought to be.  If OUTPUT.sch is edited in KiCad, you can simply do a text search for "eelint" (which is the name of the marker symbol that has been inserted).  The idea is that you find all of these markers, manually edit away the problems, then remove the markers.  Once you're satisfied, OUTPUT.sch can simply be "saved as" with the original file's name.  Obviously, there's a danger here of overwriting the wrong thing, so care is required.

Consult the source code for additional instructions and info.



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

Virtual AGC is hosted
              by ibiblio.org