Reproducing old machines with newer technology
cclist at sydex.com
Wed Jul 15 11:59:34 CDT 2015
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.
More information about the cctech