Hardware Architectures and I/O (was: Re: Jargon file...) **FLAME!!**

[Kevin D. Quitt]

In article <1990Dec2.154303.17105 at eddie.mit.edu> rs at eddie.mit.edu (Robert E. Seastrom) writes:
>In article <PST.90Dec1131440 at ack.Stanford.EDU> pst at ir.Stanford.EDU (Paul Traina) writes:
>>
>>Back when there were REAL(tm) computers like 780, a lot of time and
>>energy went into designing efficient I/O from the CPU bus to the
>>electrons going to the disk or tty.  
>>
>
>Damn right, but even the 780 was a step down.  Get your KL-10
>documentation set out and read about *them*.  Front-end PDP-11s that
>did Tops-20's command completion.  Seperate I/O and memory buses.
>8-ported (that's eight, son) memory that talked to the I/O front-end
>machines for *real* DMA, not cycle stealing!

    Which in turn was a step down from the Sigmas, with 12 ported
memory.  (lots of little wires in those donuts).  Every major device got
its own port - the CPU was just another device.  (You could plug a slave
CPU into the bus while the system was running; after its self-test, the
system would "find" it and start assigning it tasks).  Lot of nice
touches on that machine, like a line printer (not the driver) that kept
track of hills and valleys. 

    The CPU couldn't have been as powerful as a 68030 or 486, but it'd
do real-time flight simulation without a hitch, or timeshare more than
90 users before it started to get annoying.


-- 
 _
Kevin D. Quitt         demott!kdq   kdq at demott.com
DeMott Electronics Co. 14707 Keswick St.   Van Nuys, CA 91405-1266
VOICE (818) 988-4975   FAX (818) 997-1190  MODEM (818) 997-4496 PEP last

                96.37% of all statistics are made up.