CDC 6600/Cyber 73 Memories - WAS: Harris H800 Computer

Chuck Guzis cclist at
Thu Apr 21 14:55:20 CDT 2016

On 04/21/2016 11:04 AM, Rick Bensene wrote:

> I think that you were remembering the console of one of the Control
> Data 6000/Cyber-70 series computers that you may have seen somewhere.
> This series of Control Data machines were famous for their consoles
> with two large, round, green-phosphor monitors that used vector
> drawn-characters (generated by one of the Peripheral Processors).
> Most of the normal system screens were all text, but there were some
> special programs written (including a nice graphical chess game, a
> little program that would put up eyes on the screens that would look
> around and blink, and some others that don't come to mind at the
> moment.

You forgot BAT - the baseball game.  Chess 3.0 used the display, but I
believe that the pieces and board were formed from characters.

During my tenure at CDC SSD, I wrote quite a bit of CP and PP code for
these beasts.  The 6000 series systems were recognizable as simple beige
and gray cabinetry.  The CYBERs are more wood-grain and blue glass.

As I recall the systems numbering from low to high end:

CYBER 72 - 1 CYBER 73 CPU with extra "wait" states, mostly as a
marketing gimmick to sell at a lower price than the 73.  Most CEs knew
how to disable the slowdown, but were told in no uncertain terms that
doing so for a customer was a capital offense and would not be tolerated.

6400 = CYBER 73- Jim Thorton-designed "plain" CPU; unified
arithmetic/logical unit, no instruction "stack".  Timing very
straightforward to calculate.

6500 = two 6400 CPUs in the same box, only one of which could be in
monitor/supervisor mode at any time.  Shared memory.

6600 = CYBER 74 - Seymour Cray's multiple funcitonal unit CPU, with a
primitive instruction cache and scheduler.

6700 = one 6600 CPU and one 6400 CPU in the same box, shared memory.

6415 -  a 6400 with missing PPUs and minimum central memory--which
really had to be a marketing gimmick, since the only thing that really
defined a PPU was a couple of registers, channel interface and a 4KW
core module--the rest of the logic was time-shared by all PPUs.

There were other oddball QSEs, extra PPU versions, etc.  I've been told
that S/N 1 6600 gave different floating-point results from subsequent

Ten was a number that figured into various aspects.  The clock was
nomially 10 MHz; a minor cycle was therefore 100 nsec and a major cycle
1 usec.  Each central memory word was 60 bits, holding 10 6-bit
characters.  As mentioned, there were 10 PPUs, with 12-bit memory
words, so 5 PPU words comprised on CPU word.

Initially, the maximum central memory size was 131KW; late in the
series, a 262KW option was added, necessitating extensive code changes,
as some code treated the 18-bit addresses as signed quantities, not
unsigned.  Arithmetic was ones' complement.

User programs occupied contiguous memory; an individual user had an
"exchange package" that reflected its register contents as well as field
length and relocation address. Context changes were performed by an
"exchange jump" instruction initiated from either any PPU or the CPU (if
the CEJ option was installed).  It swapped the contents of the exchange
package with the working registers.

What was surprising is how long the architecture lasted well into the
1980s, given the non-paging/non segmented memory management and oddball
word size.

For a couple of years, I worked on the development a system using up to
4 CPUs with a common 4MW of bulk core (ECS).  Since ECS transfers, after
an initial startup overhead ran at full memory speed, a model was
contrived that divided programs up into modules to create "chains", with
inter-module communication, each module resident in either ECS or in a
CPU.  The idea is that you could swap a module in where resources were
available.  Modules did not talk to PPUs as was the case for normal
programs, but rather to a per-CPU I/O supervisor, which then
communicated with PPUs.

All this to get a realtime transaction-oriented facility implemented on
a system that was designed for batch processing.  It was
interesting--and sadly, lost in the sands of time.


More information about the cctalk mailing list