CDC 6600 - Why so awesome?
paulkoning at comcast.net
Wed Jun 22 10:55:53 CDT 2016
> On Jun 22, 2016, at 11:32 AM, Swift Griggs <swiftgriggs at gmail.com> wrote:
> On Tue, 21 Jun 2016, Chuck Guzis wrote:
>>> - It had some wicked cool "demos", to cop a C64 term. (ADC, PAC, EYE)
>> Those were mostly toys to amuse the CEs, like the baseball game BAT.
> I was trying to find some video of one of those actually running. I wanted
> to see how the "calligraphic displays" painted the graphics. Do you happen
> to know why they went with two displays like that? Did the two have
> different purposes?
The displays could do vector-drawn text ("calligraphic") or arbitrary graphics by drawing dots (basically just periods). No line vectors. Plot speed was about 2.5 microseconds per character. The displays did not have any kind of refresh memory -- instead, the controlling software would just redisplay stuff fast enough. This meant that your status display was always up to date, because it was rebuilding the display from the current state each refresh. This is very handy to get a feel for what a system is doing. For example, if something gets stuck, the corresponding display element would freeze. If things were running, that element might flicker or be a blur. You'd get the same intuitive view of stuff as you do with a classic "lights" console (only more so).
Text could be displayed in three sizes; the smallest characters were 64 across, 32 lines, per tube. I suspect one reason for two tubes is the same reason that people today put two displays on their desk: more screen real estate to show more stuff. Given the way the circuitry was done, two displays were only slightly more expensive than one. The controller would send the signals to the tube pairs, and a tube select signal would control which tube would light up for that particular signal. So things like the character waveform generator did not have to be duplicated.
I've seen some photos but haven't run into videos. There's an emulation that fairly accurately shows what things looked like; one could do screen capture videos from that. But that wouldn't be quite the real thing.
>> It had several *cool* OSes, but really only two major ones for general
>> consumption (Special Systems Dvision had several more). SCOPE (later
>> NOS/BE), pretty much initially a PP-resident OS based on the old
>> Chippewa Operating System--and NOS (was KRONOS, originally MACE),
> I tried to find some info on SCOPE, but it's very sparse. Did it have an
> interactive command line? What was your main "interface" to the OS?
They all started out as batch (card deck input), unless you count job entry from the console display which was for operator use. Remote Job Entry showed up in some of them, as did timesharing. The early timesharing stuff was amazingly primitive but it worked. Roughly speaking you'd enter the same commands as might appear in a card deck, but each would be executed when entered.
>> There aren't any alignment issues, since the CPU was only
>> word-addressable. This was when a character was 6 bits (think IBM 709x,
>> UNIVAC 1100, etc.) So a word with 10 characters was logical.
> I figured it was something like that, but I'm so used to 8-bit bytes and
> such. It takes a minute to adjust my thinking to a different base, but
> it's not that hard.
Bytes, in the sense of 8 bit clumps that were addressable, showed up in the IBM 360 series. Before then, and for that matter in many other computers for years after, machines tended to be word addressable, and character sizes might vary. 60 bits with 6 bit characters (usually) is one example. 36 bits with 6 or 7 or 8 bits is another. 48 bits with 8 bit characters... the list goes on. If you think these are odd, consider the Electrologica machines, with 27 bit words and 5, 6, 7, or 9 bit characters.
More information about the cctalk