Reproducing old machines with newer technology

[Chuck Guzis]

On 07/15/2015 07:16 AM, Paul Koning wrote:

> I just found it, in the old (rev B) version of the System
> Programmer’s Instant.  It’s the 6411/6414 “Augmented I/O Buffer and
> Controller”.  And yes, it has its own ECS instructions, which use
> what would normally be NOP opcodes.  Interesting, given that
> conventional PPUs got ECS access via the DDP, an I/O device.  I
> suppose they wanted to integrate it a bit better, or use less logic?

My impression is that the 6416 was a pretty early device/configuration 
so it probably never saw much deployment and hence, little development. 
  It's an interesting beast, however.

> Same here.  The PLATO system was pretty demanding of PPUs, but still
> it managed with the standard 10.  Partly that may be because it
> didn’t really use the standard CDC ones at all, relying on its own
> dedicated ones instead.  One for terminal I/O, two for disk I/O, one
> for OS-like functions — four persistent ones, that still leaves
> another four “pool” PPs.

Add tape I/O and things started getting tight.  You still needed PPs to 
handle the unit-record stuff (1LP and 1RC, IIRC, for the printer and 
card reader).  Then there's Intercom and IGS...  Things could get tight. 
  Channels were another scarce resource--and, in particular, the 
request/drop implementation in software could be pretty slow.  When the 
Cyber 70 introduced the ILR, that helped quite a bit.

All in all, the PP scheme for I/O was less than optimal.  I vividly 
remember struggling with the "long tape" driver (1LT) and ECS. 1LT 
attempted to get around the constraints of PP memory size by 
transferring data to/from CM on the fly.  This worked--after a 
fashion--if the system wasn't too busy--but a single ECS transfer choked 
the pyramid and the driver would get overrun/underrun issues, meaning 
backspacing back to the IRG and starting all over again.  A QSE 
introduced the "priority bit" on PPU CM reads and writes (just set the 
high order address bit), but that was disruptive to things like DSD that 
were generating the display in real-time from CM information. And, of 
course, that had to be sacrificed eventually on machines upgraded to 262K.

It was a nasty problem that we never really solved.  I can readily 
understand why Cray in the Cray-I completely dodged the issue of I/O and 
just provided a big pipeline.

--Chuck