Re: Architectural implications of locate mode I/O

Scott Lurndal wrote:

Thomas Koenig <tkoenig@netcologne.de> writes:

John Levine <johnl@taugh.com> schrieb:
>

The 709 introduced data channels in 1958 which allowed the CPU to do
other stuff while the channel did the I/O. Wikipedia says the first
I/O interrupt was on the NBS DYSEAC in 1954 but it's hard to see how
an I/O interrupt would be of much use before channels. Once you had a
channel, I/O buffering made sense, have the channel read or write one
area while you're working on the other.

>
Not sure what you mean by "channel" in this context - hardware
channels like the /360 had, or any asynchronous I/O in general,
even without hardware support?
>
Sending the next character to a teletype after the user program
fills a buffer and waiting for the next interrupt to tell you it's
ready makes sense, without a busy loop, makes sense anyway.

>
Although in the mainframe era, most terminals were block-mode
rather than character-by-character, which reduced the interrupt
frequency on the host (often via a front-end data communications
processor) at the expense of more logic in the terminal device.

Once you recognize that I/O is eating up your precious CPU, and you
get to the point you are willing to expend another fixed programmed
device to make the I/O burden manageable, then you basically have
CDC 6600 Peripheral Processors, programmed in code or microcode.