Path: utzoo!mnetor!tmsoft!dptcdc!jarvis.csri.toronto.edu!godzilla.eecg.toronto.edu!leblanc
From: leblanc@eecg.toronto.edu (Marcel LeBlanc)
Newsgroups: comp.sys.cbm
Subject: Re: turbodisk and IEEE
Summary: not much
Keywords: floppy rotation time
Message-ID: <89Feb16.150112est.2394@godzilla.eecg.toronto.edu>
Date: 16 Feb 89 20:01:01 GMT
References: <8902160843.AA11442@MATH.Tau.Ac.IL>
Organization: EECG, University of Toronto
Lines: 46

In article <8902160843.AA11442@MATH.Tau.Ac.IL> <finkel%TAURUS.BITNET@CUNYVM.CUNY.EDU> writes:
>>Subject: Re: turbodisk and IEEE
>>Summary: Non-standard formats can give much better speed WITH 1541
 ...
>a.   My Turbo is 50% faster than any THEORETHICAL 1541 speedup! my drives reads
>a 8250 track that contains 27 sectors in one revolution! the 1541 has only up
>to 20 sectors on a track. even if you will have such a
>full-track-reader-in-one-revolution for the 1541 ( which I doubt ), your
>turbo will STILL be 50% slower!

>b.   My turbo uses STANDARD 8250 sector format! it's the DOS format that isn't
>compatible, not the sector format! you can read these sectors using U1:, U2:,

You are right, of course.  The maximum possible speedup on a 8050/8250 is
greater than on a 1541.  Also, because the 1541 has only one processor, it
can't decode GCR and send it over the serial bus as quickly as it reads it.
To accomplish this requires the use of non-standard sectors that have a
lower information density that normal GCR.  If the information density is low
enough (but still useful), then the single processor can decode it and send
it over the serial bus as it reads it.  I think you would be able to get the
equivalent of 15 standard sectors on a 1541 track.  I haven't tested this new
low information density format yet, but I think it should work.

>to demonstarate the speed of it, lets say that loading a picture from within
>Doodle, it takes about 1 second, once you see the computer starts drawing it.
>( i.e. not including the directory search time, and the time required to seek
>to the appropriate track ).
>
>we had a demo disk ( made before I wrote the 'file' structure ), that recorded
>a series of doodle pictures on the disk's tracks, and a demo code that read them
>right of the disk's surface at predefined tracks. the avarage time between
>a screen change ( the demo read 8-10 pictures right after another, then
>restarted at the beginning ), was about 1 second.

I think you're being conservative again :-).  Reading 40 sectors worth of
information shouldn't take anywhere near 1 second with your turbodisk.  If
I remember correctly, the 8050 doesn't retain any directory information in
it's buffers, so it has to return to the directory track before reading each
new file.  This constant seeking would account for the 1 second delay between
screen changes.

Marcel A. LeBlanc	  | University of Toronto -- Toronto, Canada
leblanc@eecg.toronto.edu  | also: LMS Technologies Ltd, Fredericton, NB, Canada
-------------------------------------------------------------------------------
UUCP:	uunet!utai!eecg!leblanc    BITNET: leblanc@eecg.utoronto (may work)
ARPA:	leblanc%eecg.toronto.edu@relay.cs.net  CDNNET: <...>.toronto.cdn