CDC 6600 display character generation

[Chuck Guzis]

On 06/06/2018 09:31 AM, Noel Chiappa via cctalk wrote:

> The pronounced rounding which I noticed in the characters must be caused by
> the limited bandpass of the A-D system, amplifiers, etc - it can't actually do
> a sharp corner when going from e.g. a vertical stroke to a diagonal one. Or
> something like that.. :-)

Ah, Noel, you beat me to it--I wasn't even through my morning coffee
before I read the query.

Yes, a simple 5x7 scheme in an 8x8 "grid", which produced very readable
output in small characters, but as you went to medium or large
characters, the coarseness was immediately obvious.   Still, pretty
remarkable for 1964, a 64-character line with 64 lines of small
characters possible.

The 6602 programming reference is here:

http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/peripheralCtlr/60333900B_6602_6612_Console_Display_Sep74.pdf

The gotcha, of course, is that you were driving the display with a 12
bit PPU with 4K words and a 1 microsecond cycle time.   No
buffering--you looped in your display code to refresh the display.  This
was no storage device--if you didn't make the loop or your code hung,
the display blanked completely at worst, or flickered severely at best.

Although the "dot" resolution for graphics was 512x512, drawing of
involved graphics took a long time, so, even on simple games, such as
BAT (baseball), was a mixture of characters and pixel graphics.   The
display for CHESS 3.0 was mostly made up of characters-as-graphics.  For
example, to shade a square on the chessboard, the "/' character was used.

This need for continual refresh made for complex displays having some
degree of flicker.  The same PPU that generated both screen displays
(and there were quite a number of them for the operator--the default was
the AB display setup, scrolling master dayfile on one side and control
point status on the other) also had to handle operator commands entered
from the keyboard--and there were no interrupts, so DSD (the usual name
of the PPU program) had to poll the keyboard as well. As if that weren't
enough, DSD also performed auto-completion of operator commands.

Overlays were either loaded from disk (by calling another PPU to do the
I/O) or directly from central memory.

Space in the DSD driver was very tight, to the extent, I believe, that
much of the memory taken by the PP resident was reclaimed by DSD.  After
all, DSD was loaded at deadstart and never unloaded.  Like PP0, the
system monitor MTR, it was there for the duration.

There was also a user-callable PP program, called "DIS" that interpreted
data from a user's CM area.  DIS was granted access to the 6602 only
with DSD temporarily giving it up.  DIS was loaded only as needed.

--Chuck

P.S.  Somewhere, I ran across a 1967 (granted) patent that describes the
character generator scheme.