Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10    5/3/83; site cornell.UUCP
Path: utzoo!linus!decvax!harpo!floyd!vax135!cornell!lee
From: lee@cornell.UUCP (Lee Barford)
Newsgroups: net.micro.6809
Subject: Re: RS Floppy Disk Interface
Message-ID: <5877@cornell.UUCP>
Date: Wed, 4-Jan-84 13:32:50 EST
Article-I.D.: cornell.5877
Posted: Wed Jan  4 13:32:50 1984
Date-Received: Fri, 6-Jan-84 01:02:56 EST
Organization: Cornell Computer Science
Lines: 28

>> Talk about cycle stealing!  The CPU isn't even running during the time the
>> keyboard data is lost.  This design is quite elegant for an operating
>> system like TRSDOS, and it certainly simplifies the read/write inner loop
>> for the disk driver, but what a loss in a multi-tasking system like OS-9!
>> I wonder if the desired latency could have been achieved using NMI or
>> FIRQ, while keeping the CPU running to service other tasks?
>> -- 
>> /Steve Dyer
>> decvax!bbncca!sdyer
>> sdyer@bbncca


Well, yes some other processes could be handled while waiting for the
sector you want to read or write to rotate under the head.
However, even with single-density 5" floppies, there isn't enough time
to do a pair of context switches between reading (writing) two sucessive bytes
from (to) the controller chip. It wouldn't be possible to service an
interrupt in that short a time, either.
FLEX shuts off spooling before it does a disk IO. OS-9 on SS-50 machines
with disk controllers without DMA or on-board sector bufferring (e.g.,
the old SWTPC 30-pin slot controllers or the Smoke Signal BFD
controller) disbles IRQ and FIRQ before entering the read (write) loop.

			Lee Barford
			lee@cornell.ARPA