Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Sat, 6 Jul 2024 02:16:34 +0000
Organization: Rocksolid Light
Message-ID: <2da727f94cc5cdf5cac1bfe57a0af001@www.novabbs.org>
References: <v61jeh$k6d$1@gal.iecc.com> <1bed88y8na.fsf@pfeifferfamily.net> <v69jgf$1lg1$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2304011"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$eimuZGXAenmnL6u8sgKgve9R9jppQuQS1Jq0Otoidrpg8K9bMD0UO
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5725
Lines: 89

John Levine wrote:

> According to Joe Pfeiffer  <pfeiffer@cs.nmsu.edu>:
>>> ... 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.
>>
>>The day the CPU became faster than a teletype (or any other IO device
>>you care to name) interrupts became useful.  Get an interrupt saying the
>>teletype is ready, send a character, go back to work, repeat.
>
> That's certainly the model that DEC used in the PDP-1 and their other
> minis.  Lightweight interrupts and simple device controllers worked
> for them.  But the tradeoffs can be a lot more complicated.
>
> Let us turn back to the late, not very lamented IBM 1130 mini. It
> usually came with an 1132 printer which printed about 100
> lines/minute. A drum rotated behind the paper with 48 rows of
> characters, each row being all the same character. In front of the
> paper was the ribbon and a row of solenoid driven hammers.
>
> When the 1130 wanted to print a line, it started the printer, which
> would then tell it what the upcoming character was on the drum. The
> computer then had less than 10ms to scan the line of characters to be
> printed and put a bit map saying which solenoids to fire into fixed
> locations in low memory that the printer then fetched using DMA.
> Repeat until all of the characters were printed, and tell the printer
> to advance the paper.
>
> Given the modest speed of the 1130, while it was printing a line it
> couldn't do anything else. But it was even worse than that. There were
> two models of 1130, fast and slow, with the difference being a delay
> circuit. The slow model couldn't produce the bitmaps fast enough, so
> there was a "print mode" that disabled the delay circuit while it was
> printing. As you might expect, students quickly figured out how to put
> their 1130s into print mode all the time.

We students, also, figured out that TSS had dumped OS process state in
page 0 (un accessible normally) of the user's address space. We then
figured out that while we could not LD or ST that data, we could queue
up I/O (out) write the data to disk, read it back where we could diddle
with it, write it back to disk, queue up I/O (in) and read it back into
page 0.

All we did was to set the privilege bit !!

We were generous and loaned out all the CPU time we did not need......
>
> The printer interrupted after a paper move was complete, giving the
> computer some chance to compute the next line to print in the
> meantime. To skip to the top of the next page or other paper motion,
> it told the printer to start moving the paper, and a hole in which row
> in the carriage control tape (look it up) to wait for. When the hole
> came around, the printer interrupted the CPU which then told the
> printer to stop the paper.
>
> The other printer was a 1403 which had 300 and 600 LPM models. Its
> print mechanism was sort of similar, a horizontal chain of characters
> spinning behind the paper, but that made the hammer management harder
> since what character was at what position changed every character
> time. But that wasn't the CPU's problem. The 1403 used its own unique
> character code probably related to the layout of the print chain, so
> the CPU translated the line into printer code, stored the result in a
> buffer, and then sent a command to the printer telling it to print the
> buffer. The printer printed, then interrupted, at which point the CPU
> told it to either space one line or skip to row N in the carriage
> control tape, again interrupting when done.

We (students) used to have comment cards that cause the hammers all
fly at the same time. So, instead of a natural z z z z z of the print,
it would go BANG BANG BANG and we knew out stuff was being printed...
>
> By putting most of the logic into the printer controller, the 1403 was
> not just faster, but only took a small fraction of the CPU so the
> whole system could do more work to keep the printer printing.
>
> The point of this long anecdote is that you don't just want an
> interrupt when the CPU is a little faster than the device. At least in
> that era you wanted to offload as much work as possible so the CPU
> could keep the device going and balance the speed of the CPU and
> the devices.
>
> As a final note, keep in mind when you look at the 400 page patent on
> the 709's channel that the logic was built entirely out of vacuum
> tubes, and was not a lot less complex than the computer to which it
> was attached. A basic 709 rented for $10K/mo (about $100K now) and
> each channel was $3600/mo ($37K now).  But the speed improvement
> was worth it.

Ah memories.......