Contents

This page is devoted to physical implementations of the Block I
and Block II AGCs, and their peripherals such as DSKYs. In
other words, to physical devices that you could build and keep in
your living room to impress friends and neighbors. Be the
first on your block to have one!

John Pultorak's Block I
AGC Project

The Pultorak PDFs

John Pultorak has
constructed a physical (not virtual), working model of a Block I AGC
out of 74LS-series low-power Schottky TTL devices. The model
works, and runs software which John has adapted from Colossus 249
software. John's unit even has the same general appearance as
the original Block I AGC prototype! Of course, Colossus 249
software is targeted for the Block II AGC rather than the Block I
AGC, but John did not then know of any existing Block I source code,
and indeed, even the Colossus 249 software listing he had at the
time was only a partial one rather than a complete program.

I think I've harped on this point endlessly in the past, but at the
risk of beating a dead horse, please don't expect John's schematics
to be the actual Block I AGC schematics. Those simply
weren't publicly available when John did his work. John's
work, rather, is a fantastic creation of a workalike, based on his
reading of available documentation. The Block I AGC and DSKY
schematics have since become available, though, and if you want
those the place to look is on our
electro-mechanical page rather than here. Okay, you've
been warned now, whether you wanted a warning about it or not, so
feel free to continue reading about John's accomplishment!

No manned mission ever flew with a Block I AGC. It was
originally intended that Apollo 1 and Apollo 2 would be Block I
missions; but I'm sure you know what happened to Apollo 1, and
Apollo 2 never took place. The unmanned missions AS-202
(sometimes referred to as Apollo 3, though it took place before
Apollo 1 would have), Apollo 4, and Apollo 6 did use Block I AGCs.

John has thoughtfully provided us at Virtual AGC with his schematic
diagrams, with adapted Block II software, and with his
cross-assembler, all of which are a bit tricky otherwise to get in
machine-readable form. He has also documented his project in
what I'll refer to as the Pultorak PDFs, which you may find a lot
of other places on the web, but which I provide here as well, since
why not? The following block quote is simply a duplicate of
what was on the sort-of-but-not-quite-discontinued klabs website:

Block I Apollo
Guidance Computer (AGC):
How to build one in your basement

Material developed and provided by John Pultorak, who is kind enough to put these
files into the public domain with no restrictions on their
use.

Abstract

This report describes my successful project to build a
working reproduction of the 1964 prototype for the Block I
Apollo Guidance Computer. The AGC is the flight computer for
the Apollo moon landings, with one unit in the command
module and one in the LEM.

I built it in my basement. It took me 4 years.

If you like, you can build one too. It will take you
less time, and yours will be better than mine.

Early computers are interesting. Because they're
simple, you can (if you like) actually understand the entire
computer, from hardware to software.

The AGC is the most interesting early computer
because: it flew the first men to the moon and has
interesting architectural features.

How is this Related to Virtual AGC?

It's not. John's project is not an offshoot of the Virtual AGC
project, or vice-versa, and neither project uses materials created
by the other. But John's project is at an end, and he doesn't
want the hassle of maintaining a web presence for it, whereas
Virtual AGC is an ongoing project. (But see
our Block 1 page.) So as a courtesy, the Virtual AGC
website is going to host supplemental materials for the Pultorak
project that haven't worked their way into the other websites
mentioned above.

I should mention, though, that it was John who acquired for us all
of the documentation and source code that we presently have for the LM's abort computer. (Of course, I
had to write the assembler and simulator myself, so he didn't do everything
for us!) And, the existence of his software Block I
simulation (see below), which he wrote in preparation for his
hardware simulation, has been extremely helpful in the creation of
our own Block I simulator. So it would be hard to overestimate
the value John has had for us a Virtual AGC. Thanks, John!

AGC Source Code

AGC source code (flight software adapted for Block I and for John's
cross-assembler, test & checkout software, and so forth) is
provided in the Pultorak PDFs, but you have to have some means of
extracting them to use them for anything. Moreover, the PDFs
often provide assembly listings—i.e., reports generated by the
assembler—rather than pure source code. An assembly listing
isn't a legal assembly-language source-code file, so you can't
conveniently change and reassemble it. You can get a zipfile
containing the source code and some supplemental files (such as hex
files) by
clicking here (1 MB).

Unfortunately, the format accepted by John's cross-assembler isn't
compatible with yaYUL (or
vice-versa), so these source files cannot be assembled by yaYUL. They must be
assembled using John's cross-assembler.

Circuit Design

The Pultorak PDFs do provide schematic diagrams, but some readers
have commented that it is difficult to make out some of the details
in them. You can download a zipfile containing the complete
CAD files for the design by clicking here
(1.7 MB). The CAD files are in Circuitmaker format (*.ckt), but even if you don't
have a copy of Circuitmaker,
the zipfile may be worth downloading because it also contains:

WMF (Windows Metafile) versions of the schematics that are
more legible than those in the Pultorak PDFs; and

An Excel spreadsheet with a partlist for the design.

At the time John created these materials and first sent them to me,
Circuitmaker was available
commercially, and if you couldn't afford the full version of the
program you could either have downloaded the free but limited
"student" version of the software, or else you could download a full
but time-limited demo version of the program. Since that time,
however, the company which was selling Circuitmaker has apparently been acquired by Altium,
and theCircuitmakerprogram has beendiscontinued.
According to Altium's website,
the substantially more expensive Altium
Designer product is supposed to be able to import existing
Circuitmaker
schematics. I have no idea whether this is true or not, though
my past experiences in such situations leads me to be suspicious
about it. If anybody else has tried it (and cares to convert
John's schematics for me), please let me know.

In order to run Circuitmaker,
you have to use Options/LibraryLocation (full or demo version) or
File/Preferences/DirectoriesAndFiles (student version) on the menu
to set the location of the "user library" (USER.LIB) that comes in
our zipfile. (After doing so, you will probably also have to
exit from Circuitmaker and
then re-run it, because Circuitmaker
will already have loaded the default USER.LIB into its internal
cache, and it won't reload it until being restarted.)
Otherwise, when you load the schematics they will have wires but no
electrical components on them. Incidentally, although Circuitmaker2000 is a Windows
program, both the student and demo versions run just fine under
Linux with CrossOver Office.
They
may run fine too under normal Wine,
but I haven't tried it.

One thing you will likely want to do with Circuitmaker is to create a netlist. Neither
the student nor demo versions of Circuitmaker
seem to want to admit the notion that a single IC can contain
multiple gates, and will therefore likely display an error prompt
asking if you want to "correct" this condition. If you say
"yes", Circuitmaker will
arbitrarily relabel the components within the schematic, so that
only one gate appears in each package. My advice would be to
say "no" (not to correct), as the only negative side-effect of doing
so appears to be that the netlist file will have duplicate entries
for the packages with multiple gates, but the wire-list will be
correct.

Integrated Development Environment (IDE)

Donna Polehn has created an GUI IDE (I think, Windows only)
based on the Pultorak Simulator and assembler, which you can find
at https://github.com/donnaware/AGC.
In
order to build it, you need C++Builder 6. I've not tried
it, since I don't personally have C++Builder 6 and don't normally
run Windows, but I expect it's interesting.

Donna tells us also that she has made a functional Block I using
the Terasic DE0 FPGA development board, as well as a custom FPGA
board. Those are available at the link listed above.

Mike
Stewart's Block II AGC Project

You can find all the data on Mike's project at these two GitHub
sites:

You have to take what I say about Mike's project with a bit of a
grain of salt, because Mike has used his Block II simulator as a
weapon for justice, rather than treating it as a work of art, and
so I have to give him very high marks just on that basis
alone.

No, wait, is that what I wanted to say?

I jest, of course, but it may not be so far off. What Mike
has done, in his quest to perfect his simulation, has been
unique. He has used his hardware simulator to do detailed
comparisons against our own software AGC simulator, yaAGC,
and to repair yaAGC when he has found it to be broken in
some way, along the way becoming a top contributor to the Virtual
AGC project. The problems he has found have certainly been
subtle, but real. One benefit to Virtual AGC is that bugs
preventing yaAGC's use for landing the NASSP/Orbiter LM on the
Moon have been fixed, and I got a nice note a few weeks ago (say,
in late August of 2016) saying that they had finally landed on the
Moon with any program alarms or other problems! But there
has apparently been some help flowing in the opposite direction as
well, since Mike tells me that Jim Lawton's AGC wire-lister from
our own GitHub repository was essential to his work.
Go figure! I didn't even know it was there. Good job,
Jim!

As part of this, Mike has also been instrumental in acquiring
AURORA, a very early AGC LM program, because it was the last
AGC program to contain a full suite of test-suite software, which
should help him (and us!) to locate yet other subtle bugs in the
simulations, if bugs there be.

Mike's project also stands out because he has used open-source
tools, so if you have the time, the expertise, and the will, you
can reuse the material from his project without having to acquire
proprietary tools to do so.

So while I haven't any fancy exclusive-to-VirtualAGC graphics of
Mike's work to present to you here, I can't help but recommend it
highly to you!

Steven Hauer's
Implementation

Although (see preceding section) I don't have fancy graphics from
Mike Stewart's project to show you, Steven Hauer has been busy
working on implementing Mike's work, and has sent graphics
galore. Because I am lazy, I'll let Steven describe it for
you himself without any of my normal, pesky reinterpretations or
editing.

OVERVIEW

Here is a physical implementation currently in
progress of Mike Stewart's Block II AGC design. I
started the process of creating this AGC about 20 months ago
by researching available AGC design information and
implementation examples. I wanted to create a Block II
version of the AGC capable of running the full software.
The idea of creating an AGC that mimics the original Block II
circuits also appealed to me greatly, so Mike's design based
exclusively on NOR gates, inverters, and open collector
drivers was exactly what I was looking for.

I have implemented Mike's design of A01 - A24 plus his version
of the fixed/erasable memory board B01 exactly as defined in
his KiCad schematics available online. The only
exception is a change in memory devices used on B01 to options
available for 5V logic and through-hole design.

I intend this AGC to demonstrate full functionality so I have
brought out the full set of I/O signals and the monitor
connector signals. I use the monitor connector signals
for basic integration testing via a monitor breakout board of
my own design that also provides interfaces to a logic
analyzer.

Instead of the transformer coupled I/O of the original AGC, I
applied open collector digital drivers for all outputs added
directly to the I/O boards. For the inputs I used a
simple emitter follower for the high speed inputs and the
original 'D' circuits for handling the switch inputs.
The simplification of the signal conditioning allowed me to
use only 2 interface circuit boards.

My intention is to eventually create a full complement of
hardware based simulations of all peripheral devices,
uplink/downlink, and a working hardware implementation of the
monitor console (also called the core rope simulator) to
demonstrate historically accurate monitor functionality.

DSKY

The DSKY design is my own. Instead of
multiplexing the display drivers like in John Pultorak's DSKY,
I have decided to drive the led segments primarily from open
collector driver ICs and each 7-segment display will have its
own latching BCD decoder/driver instead of latching
relays. The translation of the AGC digit values to BCD
will be accomplished with some old 32x8 bit fused link bipolar
PROMS. Decoding of the AGC OUT1 channel (channel 10 oct)
will use a combination of a 4 to 16 decoder and a series of
nor-gate based flip flops and gating logic similar to the AGC
implementation.

The DSKY push buttons are as close to the orginals as I could
find comercially available. They will be wired identical
to the original DSKY and make use of the same diode array for
encoding.

AGC CONSTRUCTION

Each AGC module is fabricated on a 4 layer PCB
using 14-pin DIP packages. I initially thought I would
wire-wrap each module but after completing A01 and A02 I
quickly determined that wire-wrapping the modules was not a
viable option so I went with PCBs. I used KiCad for all
PCB layout to ensure they matched Mike's schematics.

The chassis is made of aluminum plate and angle stock.
The plates for the module connectors and the card guides were
ordered online and laser cut.

The backplane is wire-wrapped by hand. I generated a
backplane netlist within KiCad and printed out a hard
copy. Careful use of highlighter markers and triple
counting each pin has so far yielded an error free
backplane. The backplane took about 10 months of part
time effort (several hundred hours) to complete and I ended up
using about 2200 feet of wire.

CURRENT FUNCTIONALITY

Pictures show completed AGC with modules A01 -
A24 plus two input conditioning boards. I've included
some logic analyzer screen shots showing the first time I got
GOJAM working and also a couple screen shots showing the 4
instructions of the startup entry vector executing from the
validate code. The screen shots showing instruction
names are driven from signals via the monitor connector
breakout board.

Current computer runs validation program successfully through
to completion. I don't have a DSKY yet so I confirmed
successful completion by watching '77' be written to CH10
(oct) for the DSKY signaling the sucessful completion of the
program.

I have also loaded Luminary 210 and the program runs without
any alarms other than 'NO ATT' which makes sense since there
is no IMU (yet). I can watch PINBALL (the DSKY control
routine) clear the DSKY via my logic analyzer and observe some
of the interrupt driven idle behavior of Luminary at this
point.

FUTURE PLANS

After the DSKY is complete, I plan on creating
an interface to allow my physical AGC / DSKY to connect to the
Orbiter spaceflight simulator, with the NASSP 8.0
Apollo-mission add-on. Instead of interfacing this
package to yaAGC, I will instead connect it to an adaptor that
will take the data stream created for the 'ya' packages and
translate the packet data to/from the correct hardware signals
to interface with my AGC.

— Steven Hauer, 11/2018

Of course, I know that what you really want to see are the
pictures, so here they are. Click any of them to see an
enlarged view:

A01 - A07 + A13

A01 - A15 + B01

A05

Backplane 1

Backplane 2

Backplane 3

Chassis 1

Chassis 2

Monitor Board 1

Monitor Board 2

Running with Monitor Board

GOJAM Control Signals

Start Vector 1

Start Vector 2

DSKY Button Wiring

DSKY Display 1

DSKY Display 2

DSKY Display Test

Dario Kubler's
Apollo 16 AGC/DSKY Simulation Project

Dario was part of a team (largely people
from the Fondazione Osservatorio
Astronomico M13) that created a 1:1 scale
mockup of the Apollo 16 Command Module ("Casper") for 2012
exhibition called Esplorando, in Varese, Italy, near Milan.
Dario's part of the task was to create a working DSKY, which would
be interfaced via bluetooth to a PC running the Artemis AGC
program in our yaAGC AGC simulator software. Of course,
yaAGC has no direct bluetooth support, but Dario wrote a C++
program that interfaced between yaAGC and bluetooth.

Apparently, the exhibition went very well. Charlie Duke, the
LMP for Apollo 16, was one of the visitors. I'm told that he
entered the capsule, played with the AGC/DSKY combo, said that it
was very realistic, and passed his compliments to us. So ...
thanks, Dario!

Since then, Dario has managed to port yaAGC into an embedded
system, based on the PIC32-MZ (a 32-bit MIPS-based MCU), with 2MB
of flash memory and 512KB of RAM, using the XC32 gcc-based
compiler. Dario himself works at Microchip (the
manufacturer) himself, so that seems like a natural progression.

Dimitris
Vitoris's Block I and Block II AGC Project

The project of Dimitris ("Jim") Vitoris takes over where John
Pultorak's project stops. The project is still in its very
first stages, so please don't take any statements made here as
commitments! But the basic idea of the project is to be able
to create a physical implementation of a Block II AGC and DSKY,
which (unlike John Pultorak's Block I AGC above) can be constructed
by hobbyists, without requiring the immense skill needed to
construct a Pultorak AGC.

Here is a very uncertain
roadmap of the project. It may be that all of these phases
will be completed, or it may be that the project will stop where it
is now. Or perhaps some phases might be skipped. There
is no timetable. But however it goes, thanks Dimitris!

Project
Phase

Description

Status

A0

Conversion of John Pultorak's
Block I AGC design (schematics only!) to Eagle CAD, with
corrections and small improvements.

Ready now!

A1

A clean restructuring of the
Block I design -- for example, with AGC, DSKY, and
monitoring busses separated into independent assemblies
rather than being a part of one large assembly.

Further, final size reduction
of the Block II design, with added Virtual AGC
compatibility. (This would mean, for example, that one
of Dimitris's physical DSKY could be used with a PC running
Virtual AGC.)

The download is a zipfile containing the complete set of
materials that have been created by Dimitris so far.

Dimitris uses Eagle CAD for
this project (www.cadsoft.de).
Eagle is a cross-platform
program that is available for Linux, Windows, and Mac OS X.
While Eagle is a
proprietary program that costs money to purchase, there is a free
version that can be used with small designs. I have verified
that the free version does allow viewing of the phase A0 schematics
on Linux. Unfortunately, although the purely open-source KiCad CAD software
purports to (and probably does, for all I know) import Eagle CAD
projects and schematics, I have found that KiCad 6 will not import
these files.

Once phase B0 and beyond are reached, it would be valuable to have
mechanical design and drawings of things such as DSKYs, enclosures,
front panels, and so forth, so that complete physical units can be
constructed. Any mechanical engineers who are interested
should contact me at the email address at the bottom of this
page. Mechanical design of a Block II DSKY in particular would
be useful, regardless of the how far Dimitris cares to advance his
project.

Dimitris has also sent some photos of the physical device he is
constructing:

The physical faceplate,
work in progress!

Cleaned-up stylized
drawing
from which measurements can
be taken. A CorelDraw
file is also
available.

Dimitris mentions that his best estimate of the faceplate dimensions
is 18.9 cm (7.44 in.) wide and 21.8 cm. (8.58 in.) high, and points
out that additional dimensions can be extract from the right-hand
drawing above.

Incidentally, Dimitris owns various bits and pieces of Block I
equipment, and here are some photos he was kind enough to send
us. (

Block I AGC Logic Module

Block I AGC Rope Memory
Module

Block I DSKY Power Supply

Philip Schmidt's Block
I AGC Project

Philip Schmidt has also been kind enough to let us know about his Block I physical
implementation. You can see his write-up of what he's been
doing at his
own
web-page. Phil tells me that he will eventually
provide all of the CAD files for his design (in Altium Designer format), but for
right now it's all PDFs while it's a work in progress.

Juan Jose's Block I AGC Project, Running
SOLARIUM

Juan Jose has built a Block I AGC-plus-DSKY simulator using a
Spartan3 (a Xilinx FPGA) board. I don't have too many details
about how he did it, though he was kind enough to send our mailing
list some nice photos of some of the proto-boards he had added to
the basic Spartan3 board.

There are also some cute YouTube videos of it in action. Here
is his "Block I Flyby" video — the "flyby" being of his contraption,
and not of anything in space:

You can find more by looking at his YouTube user, which is
"agcfanatic", but here are a few direct links:

Unfortunately, Dave was having some problems with his hardware Block
II simulator at the time of the last commit (in 2012) of his source
code as listed above, particularly in regard to the DV instruction.
He apparently later fixed this DV problem, but the fix never
migrated online. In point of fact, at that time yaAGC (which
of course, Dave does not use) also had a number of problems with the
implementation of the DV instruction, later fixed by Mike Stewart,
and some of Dave's problem may have related to the Validation Suite
of AGC code we provide having been in error due to this.

Who's Building Them?

Alessandro Cinquemani

Of course, the great thing about these projects is that you can
start from them and build your own AGC or DSKY. If you have
done so, feel free to send me some photos and/or descriptions of
what you've built. Where is Heathkit when you
need it?

Alessandro Cinquemani of Aviano, Italy, has sent in the very nifty
photo (click to enlarge) seen below.

As I understand it, here we're seeing the DSKY and CTL modules,
which Alessandro built by following through on John Pultorak's
documentation. Alessandro is still working on the MEM and
PROC modules, but when the AGC is fully operational is
considering making actual circuit boards. Great job,
Alessandro!

Alessandro has sent us a whole gallery of photo updates,
reluctantly down-sampled by me to save some space. He
tells us (2009-06-17) that he thinks he may be able to finish it
up in 3-4 months. Click'n'enjoy:

Bruno Muller

Bruno Muller has created a physical DSKY that interacts with
yaAGC via the NASSP plug-in for the Orbiter spacecraft
simulator. He has made a video and sent me the following
charming YouTube link:

Other?

My personal bias is that I'd prefer it if these materials were
available for use with a free and open-source CAD system rather than
proprietary systems such as Circuitmaker
and Eagle. The
subsequent discontinuation of the Circuitmaker
program (mentioned above) puts the problem in stark relief:
John Pultorak spent a lot of time creating these materials, and yet
within just a few years nobody will be able even to open the CAD
files he created. This website deals with things that happened
(as of this writing) 40 years ago, and I'd like the
information presented here to still be useful 40 years from now ...
or 400. But the CAD files have proven to have a shelf-life of
less than 5!

Such absurd situations should come as no surprise to anybody with
substantial experience in using electrical CAD systems.
Speaking from experience, every
proprietary electrical CAD program is eventually discontinued either
by virtue of acquisition of the manufacturer or else a strategic
decision by the manufacturer, and the schematic format is then
orphaned, usually even without any documentation. Yet I've
never encountered an electrical designer who had noticed this fact
or believed it was a problem; instead, CAD software is invariably
chosen on the basis of whatever features are most convenient to the
designer at that moment in time. Indeed, I've made such
selections myself, based on whatever software has the fastest or
best autorouter. But the autorouter relates only to PCB
layout, and has essentially no relation to schematic capture, which
could be done by a separate program from the PCB layout program
entirely. Schematic capture and PCB layout are interrelated only by
exchange of netlists and back-annotation info, and the notion that
the two must be integrated into one program is a fantasy promoted by
CAD manufacturers and swallowed en
masse by circuit designers. I'd venture the advice
that if you're going to use a proprietary CAD program, it's best to
use one that supports the Orcad
file format, and to archive your work in that format, since it's the
closest thing to a de facto
standard that exists at the present time.

It would be nice if an open-source CAD tools were used instead, so
that the schematics, PCB layouts, etc., would be freely editable by
everybody without purchasing a proprietary tool. If anybody
wants to convert the CAD files into a more open format, your help
would be welcomed. Among those who think the way I do, the open-source KiCad tool seems to
have currently captured the most mind-share, and if all the cool
kids are using it, you may as well too! Of course, if you
absolutely insisted, we'd be happy to have Orcad, or any other format as
well! I've so far not found an automated tool to perform the
conversion of Circuitmaker
or Eagle to any other
format. (If you wanted to write a program that converted Circuitmaker or Eagle files to some open
format, I'm sure that would be even more valuable than the
conversion itself.)