The AGC and its DSKY user interface were developed in the early 1960s for the Apollo program by the MIT Instrumentation Laboratory and first flew in 1966.

The AGC in the lunar module ran its Apollo PGNCS (primary guidance, navigation and control system), with the acronym pronounced as pings.

[2] Early architectural work came from J. H. Laning Jr., Albert Hopkins, Richard Battin, Ramon Alonso,[7][8] and Hugh Blair-Smith.

A flight director attitude indicator (FDAI), controlled by the AGC, was located above the DSKY on the commander's console and on the LM.

The F10 stage (100 Hz) was fed back into the AGC to increment the real-time clock and other involuntary counters using Pinc (discussed below).

The AGC had four 16-bit registers for general computational use, called the central registers: There were also four locations in core memory, at addresses 20–23, dubbed editing locations because whatever was stored there would emerge shifted or rotated by one bit position, except for one that shifted right seven bit positions, to extract one of the seven-bit interpretive op.

Block I had 11 instructions: TC, CCS, INDEX, XCH, CS, TS, AD, and MASK (basic), and SU, MP, and DV (extra).

The cycle began at timing pulse 1 (TP1) when the AGC loaded the memory address to be fetched into the S register.

This bit was set to 1 or 0 by a parity generator circuit so a count of the 1s in each memory word would always produce an odd number.

The increment (Pinc), decrement (Minc), or shift (Shinc) was handled by one subsequence of microinstructions inserted between any two regular instructions.

The T3rupt and Dsrupt interrupts were produced when their counters, driven by a 100 Hz hardware clock, overflowed after executing many Pinc subsequences.

The Uprupt interrupt was triggered after its counter, executing the Shinc subsequence, had shifted 16 bits of uplink data into the AGC.

In this mode, the AGC performed essential functions, checked the standby allowed switch, and, if still enabled, turned off the power and went back to sleep until the next F17 signal.

The standby mode was designed to reduce power by 5 to 10 W (from 70 W) during midcourse flight when the AGC was not needed.

Tasks were short threads of execution which could reschedule themselves for re-execution on the Waitlist, or could kick off a longer operation by starting a 'job' with the Exec.

The assembler, named YUL for an early prototype Christmas Computer,[24] enforced proper transitions between native and interpreted code.

A set of interrupt-driven user interface routines called 'Pinball' provided keyboard and display services for the jobs and tasks running on the AGC.

A set of user-accessible routines were provided to let the astronauts display the contents of various memory locations in octal or decimal in groups of 1, 2, or 3 registers at a time.

'Monitor' routines were provided so the operator could initiate a task to periodically redisplay the contents of certain memory locations.

The design principles developed for the AGC by MIT Instrumentation Laboratory, directed in late 1960s by Charles Draper, became foundational to software engineering—particularly for the design of more reliable systems that relied on asynchronous software, priority scheduling, testing, and human-in-the-loop decision capability.

[21] The first command module flight was controlled by a software package called CORONA whose development was led by Alex Kosmala.

[22][27] In total, software development on the project comprised 1400 person-years of effort, with a peak workforce of 350 people.

The Apollo Guidance Computer software influenced the design of Skylab, Space Shuttle and early fly-by-wire fighter aircraft systems.

Various tricks were employed to squeeze in additional instructions, such as having special memory addresses which, when referenced, would implement a certain function.

All across-bank subroutine calls had to be initiated from fixed-fixed memory through special functions to restore the original bank during the return: essentially a system of far pointers.

It was only used once in the Apollo software, for setting up the DAP cycle termination sequence in the Digital Autopilot of the lunar module.

The cause was a rapid, steady stream of spurious cycle steals from the rendezvous radar (tracking the orbiting command module), intentionally left on standby during the descent in case it was needed for an abort.

The extra 6,400 cycle steals per second added the equivalent of 13% load, leaving just enough time for all scheduled tasks to run to completion.

Guidance controller Steve Bales and his support team that included Jack Garman issued several "GO" calls and the landing was successful.

In the actual hardware, the position of the rendezvous radar was encoded with synchros excited by a different source of 800 Hz AC than the one used by the computer as a timing reference.