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
