The Bendix G-15 was a mid-1950s, binary, vacuum-tube, drum-memory computer system. The system was designed by Harry Huskey for Bendix during 1952-1953, while he was at Wayne State University in Detroit, Michigan. It was first available to customers as the G-15A in 1956.

Huskey had worked on the ENIAC during World War II. After the war he spent a year in England at the National Physical Laboratory, participating in the design of Alan Turing's ACE computer and the development of its prototype, the Pilot ACE. After returning to the United States at the end of 1947, he worked for the National Bureau of Standards where he was responsible for the design of the SWAC (Standards Western Automatic Computer) at the University of California at Los Angeles.

The design of the G-15 was heavily influenced by the Pilot ACE, especially in its bit-serial operation, source-to-destination command structure, and implementation of memory and registers as recirculating delay lines. There is a video of an interesting lecture by Huskey in 1982, in which he describes the designs of the Pilot ACE and G-15, and how the one led to the other.

Over 400 G-15 systems were built, with about 300 of them installed in the United States, making it a popular and successful computer system during the late 1950s and early 1960s. It was particularly popular with engineering departments and consulting firms for road and structural design calculations.

Bendix corporate headquarters were in Detroit, but the G-15 was manufactured and supported by the Bendix Computer Division in Los Angeles, California. In 1963 Bendix sold its Computer Division to Control Data Corporation, but CDC did not support the G-15 for many years after that. Some systems may still have been running as late as the early 1970s, however.

Physical Characteristics

The G-15 was an unusually small and inexpensive computer for its day. A basic system consisted of one cabinet and a modified IBM Model B electric typewriter. The cabinet was 61 inches high by 27 inches wide by 32 inches deep (155 x 69 x 81cm), weighing 950 pounds (430kg) -- about the size of a home refrigerator. It ran on standard U.S. 110-volt power, drew 38 amps (about 3KW RMS), and dissipated 14,300 BTU/hour of heat. It used approximately 450 vacuum tubes (mostly dual triodes) and 3000 germanium diodes.

Bendix-G15 with Typewriter and Optional Magnetic Tape Drive

Two variants of the system were produced by Bendix. The initial one, the G-15A, and its better-known successor, the G-15D, released in 1957. Technical Applications Memo 29 (starting on PDF page 120) describes the programming and operational differences between the two systems.

An August 1957 price list indicates a basic G-15D system could be purchased for $49,500 USD or leased for $1,485 USD per month. In 2021 dollars, those prices would be approximately $477,000 and $14,300, respectively [source].

The basic G-15 system supported only paper-tape and typewriter input/output, and only hexadecimal data formatting. It had no facilities for reading or writing general text. Decimal input and output was done by way of software conversion routines. Optional peripherals included higher-speed paper-tape devices, magnetic tape, an adapter for alphanumeric input/output (using a Flexowriter electric typewriter), adapters for IBM punched-card devices, and an adapter for custom data interfaces. A digital differential analyzer was also available. These are briefly discussed in the "Input/Output (I/O) Subsystem" section below.

Architecture

The design of the G-15 was unorthodox, clever, and extremely minimalist. All processing in the system was bit-sequential and took place as the bits were read from one of the drum lines. The bit-serial design was a major contributor to the system's small size and low cost, as it eliminated almost all need for parallel data paths and significantly reduced the number of components required. For example, words were read from the drum from the low- to high-order bits, which allowed for bit-sequential addition, so the adders only had to be one bit wide.

Word Formats and the Drum Memory

The G-15 had a 29-bit word. The drum held 2160 words in 20 108-word "long" lines (or tracks), plus 16 words in four 4-word "fast" lines. The system had a single one-word accumulator register and three special-purpose two-word registers to perform double-precision arithmetic. All of these registers were implemented as lines on the drum and operated as recirculating delays lines.

Each of the lines on the drum was implemented as a recirculating delay line with separate read and write heads. In the normal course of operation, bits on the drum surface passed a read head, where they were sensed and gated to the corresponding write head, which wrote the bits further ahead on the surface in the direction of drum rotation. The circumferential distance from the write head to the read head determined the line's recirculation delay. To change the data on a line, this recirculation path was interrupted and the new data gated to the write head.

The drum was physically about 12 inches (30.5cm) in diameter and four inches (10cm) wide. For the 108-word long lines, the angle between read and write heads was about 45 degrees, making the circumferential length of those lines about 315 degrees. The heads for the shorter lines were nestled within the 45-degree angle so that some of the short lines overlapped the same tracks as some of the long lines, although the drum surface between the read and write heads for the long lines was not being used by the long lines while it was within the angle between those heads.

Data was recorded on the drum at about 95 bits/inch. The drum rotated at 1800 RPM. Average access time was approximately 15ms for the long lines and 0.5ms for the fast lines. The clock rate was 108KHz, derived from a timing track on the drum. All data on the drum except for the timing track was lost when the system was powered off.

The word format was 28 data bits (seven hexadecimal digits) plus a sign in the low-order bit position. The representation in memory was usually signed-magnitude, but when doing arithmetic in the registers, that was converted to twos-complement. When transferring words to and from the registers the programmer needed to specify whether that conversion should take place. The one-word accumulator could only add and subtract, although left shifts were possible by repeatedly adding the register to itself, something that could be done in a single command. The double-precision registers were used for addition, subtraction, multiplication, division, and shifting.

With a signed-magnitude number representation, it is possible to have the value -0. The single- and double-precision accumulators avoided generating a -0 result, but software could store -0 in memory and in the registers. Attempting to do addition or subtraction with a -0 operand could produce incorrect results.

The hardware supported only integer arithmetic. Floating-point calculations had to be done using software routines.

An important measure in the system was the "word-time" -- the amount of time it took one word to pass a read or write head on the drum, 0.269ms. Most timing calculations were done in terms of word-times.

On the drum, the 20 108-word long lines where numbered 0-19. A complete recirculation of the line (termed a drum cycle) took 29ms. The four, 4-word fast lines were numbered 20-23 and cycled every four word-times, or 1.08ms. The double-precision register lines were numbered 24-26 and referred to as MQ, ID, and PN, respectively, and cycled every two word-times, or 0.54ms. The single-precision accumulator (AR) was line 28 and cycled every word-time. Average access time was half of these cycle times, but that could be improved upon significantly by using minimum-delay coding techniques.

Commands for the G-15 processor were specified in terms of a source and a destination. These were encoded as five-bit numbers in the instruction word and usually referred to physical lines on the drum. The basic idea was that the word under the read head of the source line was transferred sequentially, bit by bit, to the corresponding word under the write head of the destination line. Thus, if a command was executing at word-time 27, the source was 3, and the destination was 15, then the contents of word 27 on line 3 were copied to word 27 on line 15. If the destination was 22, then the word would have been transferred to word 3 of line 22, as word-times for the shorter lines were interpreted modulo their line size.

During the source-to-destination transfer, certain transformations could be applied to a word, e.g., that for complementing negative numbers mentioned above. See the discussion on the CH (characteristic) field in a command word below.

Data could be read from and stored to any of the lines on the drum, but commands could be executed only from lines 0-5, 19, and 23. Lines 19 and 23 were also used as source and destination buffers by the input/output system, so execution from them was necessary in order to bootstrap a program after it was loaded from an external medium.

Command Structure

Like most computer systems of its day, the G-15 operated in two phases, fetch (when the next instruction to be executed was loaded into the processor and decoded) and execute (when the instruction performed its function). In the G-15, these two phases were referred to as "read command" and "transfer," respectively. Since a word could be read or written only when it was under the head of its line on the drum, the amount of time the processor had to wait for drum rotation between these phases had a major effect on the amount of time instructions took to to execute, and therefore the speed at which programs would run.

Understanding those delays was the programmer's job, and it was often a significant intellectual challenge to minimize them. The way the programmer did that was by carefully arranging the locations of command words and specifying the values of the T and N fields in the command word.

A command word in the G-15 looks like this (image from Drawing 6 in the G-15 Theory of Operations Manual):

G-15 Command Word

The following describes each of these fields from right to left and how they affected the computer's operation. Note that one command could operate on multiple data words depending on the values of the S/D, T, and I/D fields as described below.

This section gives only a brief overview of the G-15 commands. For a complete treatment, see the Programmer's Reference Manual and the Theory of Operation Manual.

S/D (Single/Double) Bit

The function of this field varied somewhat with the command, but generally for deferred commands (see the I/D bit below) it indicated whether the command acted upon one word or two. For most immediate commands, this bit was ignored.

D (Destination) Field

For values 0-26 and 28, this field indicated the destination line on the drum to which transfer would take place. The other values specified special actions that were performed during the transfer phase:

27 - sending a source word (or a sequence of source words) to this destination tested the word for zero. If the source bit stream contained any 1 bits, then the next command would be read from a word-time one later than it would if the bit stream was all zero (see the N field below). This was a form of conditional branch, similar to "skip on non-zero" in other architectures.
29 - the single-precision accumulator (AR) had two destinations, 28 and 29. When loading the register with a value, such as the augend before an addition was to be done, you specified destination 28. To actually do an addition or subtraction, you specified destination 29, which added the source word (or words) to the contents of AR.
30 - similarly the double-precision accumulator (PN) had two destinations, 26 and 30. When loading the register, you used destination 26, when doing addition, you used destination 30.
31 - instead of specifying a line on the drum, this destination specified that a special function was to be performed. The S (source) field in the command specified which function. In come cases the function performed varied depending on the CH (characteristic) field in the word.
- 0 - terminate any input/output operation that is currently in progress.
- 1-15 - initiate an input/output operation, e.g., 15 means read the next block from the paper-tape reader.
- 16 - halt the processor.
- 17 - ring the system's bell, plus variant functions depending on the CH field
- 18 - transfer a value to the optional Output Register interface.
- 19 - start or stop the optional DA-1 differential analyzer accessory.
- 20 - return from a subroutine; optionally change the current command line.
- 21 - mark the return location and enter a subroutine; optionally change the current command line.
- 22 - test the sign of the source word(s) and skip if any are negative, similar to destination 27.
- 23 - clear the double-precision registers or perform a special extract on PN (line 26), depending on the CH field.
- 24 - multiply register MQ (24) by register ID (25), leaving the result in PN (26).
- 25 - divide register PN (26) by register ID (25), leaving the result in MQ (24).
- 26 - shift register MQ (24) left and register ID (25) right by a number of bits equal to half the value of the T field (discussed below), optionally adding the number of shifts done to AR.
- 27 - normalize register MQ (24) by shifting it left until the high-order bit is a 1, optionally adding the number of shifts done to AR.
- 28 - test whether an input/output operation is currently in progress and skip if not, plus some variant tests depending on the CH field.
- 29 - test whether arithmetic overflow has occurred, then reset the overflow indicator; skip if overflow has occurred.
- 30 - write a file code (similar to a tape mark or end-of-file) on a magnetic tape unit.
- 31 - execute the next command from the AR register or copy certain data to line 18, depending on the CH field.

S (Source) Field

For values 0-26 and 28, this field indicated the source line on the drum from which transfer would take place. The other values specified special sources of data. For each word-time of the transfer phase, these source values operated as follows:

27 - generate a source value by computing the logical AND of the words from lines 20 and 21, then computing the logical AND of the ones-complement of line 20 with the value in AR, finally computing the logical OR of those two ANDs, i.e., (L20 & L21) | ((~L20) & AR).
29 - compute a source value from the word in line 20 and the logical AND of the contents of the Input Register. The Input Register was a data interface to optional, external custom devices, and unless enabled by a variant of the D=31, S=17 command, the value was zero. So this was often used as a source of constant zeroes.
30 - compute a source value from the logical AND of the the ones-complement of the word in line 20 with the word from line 21, i.e., ((~L20) & L21).
31 - compute a source value from the logical AND of the word in line 20 with the word from line 21, i.e., (L20 & L21).

CH (Characteristic) Field

The primary use of this two-bit field was to specify the transformation the hardware applied to words as they moved from source to destination during the transfer phase. For some commands, particularly those with D=31, this field specified an optional or variant behavior of the command.

When used in ordinary transfer commands, the value of this field specified the following transformations:

0 - No transformation -- the word was simply transferred from source to destination.
1 - Complement -- if the sign bit of the word was zero, the word was transferred without change. If the sign bit was a 1, the sign was transferred without change, but the other 28 bits were converted to their twos-complement value. The G-15 adders could only add, not subtract, so in order to add negative numbers or perform subtraction, the operands had to be converted to their complement form first.
2 - This transformation depended upon the values of the S and D fields:
- If S or D was greater than or equal to 28, the absolute value of the source word was transferred by simply setting its sign bit to zero. No de-complementation took place.
- If S and D were both less than 28, the operation was termed "Transfer via AR" or TVA. During each word-time of transfer, the value of AR was copied to the destination word. Simultaneously, the value of the source word was copied into AR. If S=D and transfer lasted for one word-time, the effect was to swap the operand word with AR. If S=D and transfer lasted multiple word-times, the effect was to shift words on the line to higher addresses by one word. This type of shift is known as precession and had many useful applications.
3 - This transformation also depended upon the values of the S and D fields:

If S or D was greater than or equal to 28, the sign bit of the source word was reversed. If the sign bit was now 1, the word was complemented during transfer as for CH=1 above. If the destination was one of the accumulators (29 or 30), the effect of this was to subtract the source value from the register. Otherwise it simply negated the value being transferred.
If S and D were both less than 28, the operation was termed "Add via AR" or AVA. It is similar to TVA and also does precession. During each word-time of transfer, the value of AR was copied to the destination word and the value of the source word was copied to AR, except that is was complemented as described above for CH=1. No addition actually took place -- perhaps "Complement via AR" would have been a better term.

These characteristic transformations, plus their dependencies on the values of S and D, added quirky complexity and not a little subtlety to the behavior of the transfer phase. When transferring to or from the double-precision registers MQ, ID, and PD (lines 24-26), there were even more complexities, too numerous to mention here. See the pages 38-50 in the Programmer's Reference Manual for the gory details.

N (Next Command Time) Field

This field specified the word-time of the next command to be executed. As with many drum-based architectures, each instruction specified the location of its successor. This allowed the programmer, with not a little effort, to choose the location of command words such that they would minimize the drum's rotational delay between processing phases and thereby decrease the running time of a program.

As mentioned above, commands could be executed in the G-15 only from drum lines 0-5, 19, and 23. The processor initially executed commands from line 23, after loading code from a peripheral device such as paper tape or the typewriter keyboard. Two D=31 commands, S=20 and S=21, could be used to specify a change in command the line in addition to their role in subroutine entry and exit. Once a command line was set, however, the G-15 executed commands only from that line until it was instructed to switch to a different one.

Since each command specified the location of its successor, there were no branch instructions in the G-15. Conditional paths were taken as a result of test commands. If the test was false, the N location in the test command word specified the location of the next command. If the test was true, the next command was taken from the word-time following N.

If an unconditional transfer of control was needed, the usual approach was to execute a "dummy" command that effectively was a no-op. Transferring AR to itself using CH=0 was a common method of doing this.

BP (Breakpoint) Bit

This bit could be used to set breakpoints in a program. The G-15 had a three-position switch labeled "COMPUTE" that controlled the processor's running state. See the image of the typewriter below. In the switch's center position (off), the processor was halted. Moving the switch to the right-hand position, labeled "GO" caused the processor to start executing commands continuously until the switch was moved back to the off position or it executed a halt command (D=31, S=8).

The left-hand position of the switch was labeled "BP." Moving the switch to this position acted like GO, except that if the processor encountered a command with the BP bit set to 1, it halted. The halt occurred after the read-command phase completed but before the transfer phase began. The operator could resume execution by moving the switch to the off position and then either to GO or BP.

This feature was typically used for debugging, but sometimes as a conditional halt to allow the operator to change something. One extraordinary quirk of the design allowed the BP setting of the COMPUTE switch to be used as a sense switch. See Tech Memo 41 (starting on PDF page 167).

T (Timing Number) Field

The interpretation of this 7-bit field depended upon the I/D bit, below.

When the I/D bit had the value 1 (deferred), then after reading the command word into the processor, the processor waited until the drum rotated to the word-time specified by the T field before the transfer phase began. In other words, T specified the location of the operand on the source line and behaved like an operand address in other architectures.
- Transfer generally occupied one word-time if the S/D bit was 0 (a single-precision operation) or two word-times if the S/D bit was 1 (double-precision operation).
- Note that in deferred mode the processor required one extra word-time after the command was read into the processor, so if the word-time specified by T was immediately after the word-time where the command was located, a delay of a full drum cycle took place before the transfer phase could begin. Good programmers tried to avoid this.
- Wraparound from the last word on the line to word 0 was automatic.
- Access to words in the shorter lines was modulo the line size, so word-times 2, 6, 10, 14, ..., 102, 106 all referred to word 2 in the 4-word lines.
When the I/D bit had the value 0 (immediate), the transfer phase began in the word-time immediately following that of the command word and continued up to but not including the word-time specified by T. This meant that a single command could execute against a vector of words, as long as the words resided on a single drum line.
- This made it easy to set a sequence of words from a value in the AR register, to copy a sequence of words from one line to another, or to sum a sequence of words within a line. This was a powerful capability on an otherwise rather slow drum-based computer, and it was used extensively. The trick was to arrange for the command word so that it immediately preceded the sequence of words you wanted to process, although that sequence could be on a different drum line than the command.
- In certain cases, it was useful to have T exceed 107.
- As an exception, the T number in multiply, divide, and shift commands was interpreted not as a specific word-time but as two times the number of word-times that the transfer phase would last, because those commands implicitly used the double-precision register lines, MQ, ID, and PN.

I/D (Immediate/Deferred) Bit

This bit determined the mode in which the instruction operated, 0=immediate, 1=deferred. This affected when the transfer phase began and how long it lasted. See the T field above for details.

This very minimalist command structure supported a lot of useful, if unorthodox, capabilities. It provided a means to specify instruction sequences that would minimize rotational delay of the drum, but it also transferred a lot of responsibility and effort onto the programmer to specify things just right and to figure out optimal locations for commands and data. The programmer had to keep in mind at all times the current position of the drum, the length of the transfer phase, and the amount of delay there would be between the end of the read-command phase and the start of the transfer phase.

There were also a number of caveats and restrictions on commands not mentioned in the overview above, e.g., most commands involving the double-precision registers had to be located at an odd word-time so that when the transfer phase began at the next (even) word-time, the operation could start with low-order (even) word of the register on the drum. The G-15 was not an easy system to program, and it was significantly more difficult to program well.

One thing that should be apparent from this discussion is that the G-15 commands did not have what you could consider to be an operation code. The operation that a command performed was a function of at least the I/D, S, D, CH, and S/D fields, and in some cases the T field as well. That is up to 21 of the 29 bits in the word -- quite a large selection range. It was more like programming in what today we would call microcode than typical machine code.

Input-Output (I/O) Subsystem

For a computer system that had such a minimalist design, the G-15 had an interesting and capable input/output subsystem. I/O was built into the processor, but it functioned asynchronously. Once software initiated an I/O, the processor could continue executing while the input or output operation took place in parallel with its own access to the drum memory. Only one I/O could be in progress at a time, however there were situations where initiating an I/O operation while another I/O was still active could be useful. See Tech Note 33 (starting on PDF page 152) for one such case.

One of the test commands (D=31, S=28, CH=0) could be used to determine if an I/O was still in progress. If the I/O was still active, the next command would be taken from the location specified in the N field of the test command. If no I/O was active, the next command was taken from the location after that. This test command was often written with N specifying the command's own location, which caused the processor to repeatedly execute the test (with a full drum cycle delay between iterations) until the I/O finished, at which point execution would continue with the the command at N+1.

As mentioned earlier, the basic G-15 configuration supported only paper tape and the typewriter, and could read or write only hexadecimal data. It represented values externally using the digits 0-9 and letters u-z, rather than the 0-9, a-f scheme that is common today.

Data was generally output from drum line 19. Data was read into line 19 via line 23, which was used as a high-speed buffer. Words were stored in these lines in reverse order of their external appearance -- on input the first word read ended up in the last word of the line; on output the last word on the line was the first to be output.

The reason for this is that the I/O subsystem was not able to index to a particular word-time on a line. It could only index to word-time 0. The digit values on the line were precessed (there's that word again), i.e., shifted, four bits at a time. On input, as bits were read, they were shifted into word 0 on the line, with all of the remaining bits being shifted towards higher word-times, and the last bits on the line being discarded. Hence the first word read ended up as the last word on the line. On output, zero bits were shifted into word 0, all of the remaining bits were shifted upwards, and the last bits on the line ended in a buffer register from which they were routed to the device.

Paper Tape

The paper tape reader and punch were built into the top of the main cabinet. Both used a five-level tape code. This provided codes for the 16 hexadecimal digit values plus six special function codes used to format data and control the reader. See the Paper Tape Format document for details on the tape code.

The reader operated at 250 frames/second, or one frame every 4ms. Tapes were spooled inside flat metal cartridges that mounted onto the reader housing on the front of the cabinet, as shown in the G-15 picture above. This made changing tapes and interleaving data from multiple tapes quick and reliable.

The data was read in blocks of up to 108 words, but in groups of up to four words at a time. 4ms per frame was too fast for digits to be precessed directly to line 19, which cycled every 29ms. Instead they were precessed to the 4-word line 23, which cycled in about 1ms.

After no more than four words of data, the tape needed to have a frame with a certain control code, "Reload," which caused the four words in line 23 to be copied to another 4-word buffer line on the drum, MZ, which was not visible to software. That took another millisecond. From there, while input from the reader continued without pause into line 23, the four words were precessed from MZ, four bits at a time, to the first four words of line 19. The remaining four words of line 19 shifted upwards by four words, with the final four words on the line being discarded. There was plenty of time for MZ to be precessed to line 19 before line 23 filled up again.

Thus a block of paper tape typically looked like the following (this is a short block with new-lines inserted between the four-word groups for legibility):

uv0yxu00000000000000002u8034u/
131339z09898zz84444y7w2408738/
0z0z39z08888zz83w3w37w1u1w4xw/
000000006059wxu2w142z012123zy/
0808333038573y81414y7w0y0y5zy/
0000000020235zw0808994020215uS

The "/" characters represent the Reload codes. The "S" represents a Stop code, which terminated the block and halted the reader. An entire block was read in one I/O operation. This is an example of the so-called "compact" form of data entry, where the four words of 29 bits each are packed into a 29-digit hexadecimal string, with some of the hex digits containing bits from adjacent words. The canonical form of input represented the data word-wise, with tab or carriage-return frames between the words. In canonical form, the first line of the example above would be this:

uv0yxu0T0000000T0000000T15401u5C/

where "T" represents a tab frame code and "C" represents a carriage-return frame code. In this canonical form, leading zeroes in a word did not need to be entered and signs were not entered unless they were negative. Negative signs ("-") could be entered at any point within a word. The input logic stored the state of the sign in a flip-flop until a tab or carriage-return frame was detected, which signaled the end of a word and caused a one-bit precession from the flip-flop into the sign's proper position in low-order bit of the word.

Blocks on paper tape needed to have about seven inches of blank tape (termed "leader") between them, to allow the reader time to accelerate and decelerate between blocks.

The paper tape punch operated at 17.2 frames/second. Since all 16 possible values of the four-bit digits precessed from line 19 were needed to represent the hexadecimal digits on output, there was no way to embed the necessary control characters with the data in memory. Instead, the digits coming from memory were processed against a formatting table composed of 3-bit codes. This table had to be present in the first four words of line 2. The formatting codes were:

Code	Symbol	Description
`000`	`D`	Copy the next memory digit to output
`001`	`E`	End of format
`010`	`C`	Output a carriage-return control code
`011`	`P`	Output a period (.) control code
`100`	`S`	Output the sign of the current word, "-" for negative, space otherwise
`101`	`R`	Output a reload control code and restart from the beginning of the format string
`110`	`T`	Output a horizontal tab control code
`111`	`H`	Discard the next digit from memory and do not output it (rarely used)

The standard format that was typically used for the paper tape punch and typewriter generated 4-word groups and looked like this, using the letter symbols from the table above to represent the codes:

SDDDDDDDTSDDDDDDDTSDDDDDDDTSDDDDDDDCE

In other words, format four words, each with a sign followed by seven hexadecimal digits. Tabs were output between the words, with the last word followed by a carriage-return. Note that there is no "R" to output a Reload code. Reload codes were seldom used in these format strings, because that could prevent the "E" code at the end of the string from ever being sensed. Instead, the reload process was handled as follows:

When an E code was encountered, line 19 was sensed to determine whether it was now zero or still contained some 1 bits.
If there were still 1 bits on the line, a Reload control code was output to the device and output continued at the beginning of the format string.
If the line was now all zeroes, the I/O operation terminated.

Typewriter

Output to the typewriter operated at 8.6 characters/second. It worked much the same as for paper tape, except that Reload codes were ignored. Carriage returns and tabs performed their customary typewriter carriage functions. The output of data words was zero-suppressed, with spaces replacing any leading zeroes in the word.

The typewriter could receive it data from either line 19 or the AR register. In the case of line 19, format codes were taken from the the first four words of line 2, as for the paper tape punch, and output terminated once the precession of line 19 resulting in the line containing all zeroes.

Output from AR always involved one word, with AR being cleared in the process. A separate format table was used for this operation, with the codes taken from the first four words of line 3.

There was a switch on the base of the typewriter, labeled "PAPER TAPE," as shown in the image below. When this switch was set to its "PUNCH" position, each character output to the typewriter was copied to the paper tape punch. The punch operated at half speed in this mode, the same as the typewriter.

G-15 Typewriter and Base

Input from the typewriter was handled in two ways, as an I/O operation or as control commands. Software could initiate an I/O operation known as "type in," which enabled the typewriter keyboard for data entry. Hexadecimal digits entered on the keyboard were precessed into line 23 in the same manner as for the paper tape reader. A Reload code (the "/" key) caused the contents of line 23 to be precessed to line MZ and from there into line 19. The canonical form was typically used when entering data from the typewriter, although compact form could be used as well.

One difference between entry from paper tape and entry from the typewriter was that a Reload code was required after the last word entered and before the Stop code (the "S" key) that terminated the I/O operation. Thus a four-word entry of data from the typewriter would typically look like this (with T representing the Tab key):

060235zT040237xT0403uz7T02693vwT/s

The second way the typewriter was used for input did not involve the Input/Output subsystem. The G-15 had a very minimal control panel, with few switches or buttons for controlling the operation of the computer. Instead, certain keys on the typewriter keyboard were hard-wired to logic circuits within the processor. Pressing one of these keys activated a control function. The keys used were chosen such that they did not conflict with keys required for data entry.

To prevent accidentally entering one of these control functions, there was another switch on the base of the typewriter labeled "ENABLE," and sometimes referred to as "safety." This switch had to be in its "on" position in order for a key to be recognized as triggering a control function. For example, ENABLE+P would cause the system to read the next block from paper tape. Obviously, the system should be halted when doing so. This was typically used to bootstrap a program into the system. The first block on a tape was usually a loader that would read the rest of the program into the drum and distribute it to memory lines as required.

As another example, ENABLE+S would cancel any I/O operation that was currently in progress. This could be used to abort output that was not wanted (typing 108 words from line 19 took about two minutes) or to recover from a hung I/O, e.g., trying to read from paper tape with no tape loaded in the reader.

Turning on the ENABLE switch would also pause output to the typewriter. Output would resume at the point it had been suspended when the switch was turned off.

See the G-15 Operating Manual, Part II, for details on entering data using the keyboard and on the ENABLE-switch control commands.

Other Input/Output Devices

The G-15 could support up to four magnetic tape units. These functioned somewhat like a faster paper tape that could be both read and written. Similar to paper tape, data could be written in blocks of up to 108 words. No formatting, as for paper tape and typewriter output, was done. Recording density was 57 bits/inch at 7.2 inches/second using six parallel recording tracks. The recording format was unique to the G-15 and incompatible with tape formats used with other systems. One tape could hold the equivalent of about 300,000 paper tape frames.

Although the basic G-15 only supported hexadecimal input and output, there was an optional adapter, the ANC-2, that could be inserted between the G-15 and its typewriter. This device allowed the typewriter to operate in either hexadecimal or alphanumeric mode. In alphanumeric mode, which was activated by the low-order (sign or double-precision) bit in the I/O command word, each character on the typewriter was represented by two adjacent hexadecimal digits in memory.

Another alphanumeric adapter, the AN-1, supported input and output between the G-15 and a Friden Flexowriter electric typewriter or the HSP-8 and HSR-8 external paper tape units discussed below. It was also possible to connect the AN-1 to other types of devices through a custom interface.

The following optional paper tape devices were available:

The PR-1 paper tape reader was identical to the reader that was internal to the G-15 cabinet, running at the same speed and using the same five-level tape format. Up to three of these could be attached to a system. Additional units were daisy-chained from the one that plugged directly into the G-15 cabinet.
The PR-2 paper tape reader could read at 430 frames/second. It could also read tapes with five- to eight-level codes. When reading tapes with codes of six or more levels, alphanumeric mode was used as for the ANC-2.
The PTP-1 paper tape punch produced five-level tapes with the same format as the inbuilt punch, but operated at 60 characters per second. PR-1 and PR-2 units could be daisy-chained from this punch.
The HSR-8 paper tape reader could read one-inch tapes having codes of eight or fewer levels at a speed of 60 frames/second.
The HSP-8 paper tape punch could punch one-inch tapes having codes of eight or fewer levels at a speed of 100 frames/second.

There were two adapters that allowed the G-15 to read and punch cards using IBM card devices:

The CA-1 was an interface between the G-15 and an IBM 026 keypunch. The interface supported only hexadecimal input and output using the standard IBM card codes for 0-9, U-Z, and the minus sign. Format of the data on input was controlled by the program-drum card in the 026. Format on output was controlled by a combination of the drum card and the four-word format codes in words 0-3 of line 2 on the G-15 drum. Cards were read at 17 columns/second and punched at 11 columns/second. The device could read 12-44 cards/minute, depending on the number of columns read from each card. Up to two 026 devices could be attached to a system through a single CA-1 adapter.
The CA-2 was an interface that allowed the G-15 to use IBM 514, 519, and 523 card reader-punches or IBM 402 and 403 tabulating machines. The interface could process all 48 characters in the standard IBM card code, although the alphanumeric encoding within the G-15 was different than that for the ANC-2. All units operated at a speed of 100 cards or printed lines per minute.

Although not strictly speaking an I/O device, the DA-1 Digital Differential Analyzer was a peripheral accessory for the G-15. It could be used, among other applications, to solve differential equations. It implemented 108 integrators that could be logically connected to each other in numerous ways to model the equations it was to solve. While in operation, it used several tracks on the G-15 drum for storage of working values. The DA-1 was a derivative of an earlier, standalone DDA, the Bendix D12.

Software

The G-15 eventually had a large library of system and application software, much of it written by customers and freely shared with other customers. Bendix wrote a number of significant programs to aid in software development. Notable among these were:

PPR, the Program Preparation Routine -- a utility program that was loaded from paper tape and could often be left resident in the machine while developing and testing other programs. It allowed a user to enter and edit machine code as the decimal fields in a command word, load tapes with machine code for existing programs and edit it, merge routines from library tapes with the edited code, and punch new tapes from the edited code.
INTERCOM -- an interpretive programming language with an assembler-like syntax that supported floating-point calculations and allowed users to perform complex calculations much more easily (and usually much more slowly) than by using G-15 machine code. It was apparently very popular.
INTERCARD -- another interpreter, similar to INTERCOM, but which read its programs and data from punched cards instead of paper tape. The interpreter was more efficient than INTERCOM, running about four times faster.
POGO -- a translator with a programming syntax somewhat similar to INTERCOMM. It generated actual machine code, however, and optimized the locations of instructions and data to reduce drum latency and increase the speed of execution.
ALTRAN -- another translator, developed at E. I. DuPont, with a programming syntax similar to G-15 machine code, but which provided scaled, fixed-point, double-precision calculations.
ALGO -- a compiler for an early variant of the International Algorithmic Language, also known as ALGOL-58.
CPM/PERT -- a program for evaluating project task networks using the Critical Path Method and the Program Evaluation and Review Technique.

A catalog of software developed and shared by G-15 customers is available on bitsavers.org in two parts, Volume 1 and Volume 2.

The retro-g15 Emulator

I have written a software emulator for the G-15. It runs in a web browser, reproduces much of the front panel of the system, and attempts to operate at the same speed that a G-15 would have. The emulator presently implements a basic G-15 configuration and supports only paper tape and typewriter I/O.

The project has a hosting site from which you can run the emulator. The source code is publicly available in a GitHub repository from which you can download the code and set it up on your own web server if desired. See the project's wiki for details. In the next post I will describe this emulator and briefly describe how it can be used.

There is not much G-15 software available at present, but I am actively looking for more. I have set up another GitHub repository as a software archive for the machine and am presently organizing the software I do have so it can be stored in that repository.

Retro Emulation

Monday, May 30, 2022

Introducing the Bendix G-15