Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ucdavis!iris!auyeung
From: auyeung@iris.ucdavis.edu (Tak [UlTech] AuYeung)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Smooth Operator (for disks)
Message-ID: <5896@ucdavis.ucdavis.edu>
Date: 10 Nov 89 01:28:42 GMT
References: <5850@ucdavis.ucdavis.edu> <81.filbo@gorn.santa-cruz.ca.us>
Sender: uucp@ucdavis.ucdavis.edu
Reply-To: auyeung@iris.ucdavis.edu (Tak [UlTech] AuYeung)
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Lines: 28

In article <81.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes:
>
>Transfer rate is not an insignificant problem either: since Amiga-format
>floppies don't use sectors, an entire track must always be read.

I thought you have to scan thru half of the track on the average in order
to locate one sector (even if you have sectors).

>At 360
>RPM, that's 1/6 second.  (Or is it 300 RPM and 1/5 sec?)  I suspect that
>trackdisk.device also waits for start-of-track before beginning to read,
>adding another 1/12 sec average latency.

Thanks, I didn't know that.

>[...]
>Proposal: trackdisk.device should cache a user-settable number of tracks
>for each drive.  The cached tracks should be in data format (i.e., after
>being run through the blitter) and should optionally be storable in fast
>memory (at the expense of using the 68000 to move them there).
>
Good idea!  Thanks for your response!

--Tak
      #   #    =====         everything's only what it seems to be
      #   # #    # ===\ /=== #   # >>>>> auyeung@iris.ucdavis.edu
      #   # #    # ----X     #---# >>>>> Tak-Ying (UlTech) AuYeung
      \===/ \=== # ===/ \=== #   # >>>>> Logical Entity in Netland