Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!helios.ee.lbl.gov!pasteur!cory.Berkeley.EDU!fadden
From: fadden@cory.Berkeley.EDU (Andy McFadden)
Newsgroups: comp.sys.apple2
Subject: Re: Fast reading of floppies...
Summary: the hard way
Message-ID: <22917@pasteur.Berkeley.EDU>
Date: 11 Mar 90 01:35:43 GMT
References: <14075@fs2.NISC.SRI.COM> <14076@fs2.NISC.SRI.COM>
Sender: news@pasteur.Berkeley.EDU
Reply-To: fadden@cory.Berkeley.EDU.UUCP (Andy McFadden)
Organization: University of California, Berkeley
Lines: 26

In article <14076@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes:
>How do those fast disk copiers work?   
>
>I mean, I go to read $xx number of blocks from a floppy, and it takes
>its own sweet time about it. 
>
>What I'm really asking for here, is a slice of code that will accept a
>starting block #, and an ending block #, and go fetch. Fast.

Suggestions for 5.25" disks:
1) Use something like the ProDOS routines, which decode the raw track data
   on the fly.  That is, it undoes the 6&2 disk encoding while it's reading
   the data fromt he disk.  You will not get the blocks in order, but
   reassembly is relatively trivial.
2) Read the entire track into memory as raw data, then decode that.  There's
   no particular advantage to this method, except that it's easier to write
   and debug.  Keeping the track in memory will improve things, if you have
   the memory to spare and aren't reading by whole tracks every time.
3) Leave the drive running.  This leaves you in slow mode, but you don't have
   to wait for it to come back on.

>    Chan Wilson -- cwilson@nisc.sri.com <!> I don't speak for SRI.

-- 
fadden@cory.berkeley.edu (Andy McFadden)
...!ucbvax!cory!fadden