Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!uwvax!astroatc!nicmad!madnix!jason
From: jason@madnix.UUCP (Jason Blochowiak)
Newsgroups: comp.sys.apple2
Subject: Re: Fast reading of floppies...
Summary: Kinda long techie answer
Message-ID: <1174@madnix.UUCP>
Date: 16 Mar 90 10:25:31 GMT
References: <14075@fs2.NISC.SRI.COM> <14076@fs2.NISC.SRI.COM>
Reply-To: jason@madnix.UUCP (Jason Blochowiak)
Organization: ARP Software, Madison, WI
Lines: 77

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. 

	Well, the blocks (on floppies) are composed of two sectors. Each
5.25" disk has 35 tracks (there are some with more or less, but that's how
many standard Apple drives & OS'es use), and each track has 16 sectors. The
sectors each consist of an address field, and a data field. The address
field indicates which track & sector this is, and the data field is the
encoded data for that sector. Each field has a prologue, some data, a checksum,
and an epilogue.

	When a disk driver goes to read a specific sector, it seeks to the
specified track, and looks at what's passing under the head, until it either
times out or sees an address prologue. At this point, it reads the address
field's contents, decodes, and verifies (using the checksum) it, and then makes
sure that the proper epilogue is there. It then checks to see if the sector
number in the address field matches what it's looking for - if it is, then it
waits for the data prologue, reads, decodes, and verifies the data, and makes
sure that the epilogue is in place. If the sector in the address field doesn't
match, the disk read decrements a safety count, and goes back to reading the
address field (actually, waiting for one to come under the head).

	So, when a ProDOS (or GS/OS) 5.25" driver goes to read a block, it
has to 1) Wait for the first sector to come under the head, 2) Read/decode
it, 3) Wait for the second sector to come under the head, 4) Read/decode that
one. Now, depending on how things are set up exactly, the "wait for sector x
to come under the head" may take a really long time (relative to the speed
at which these toys generally operate).

	Then, the problem is to avoid waiting for the sectors to come under
the head. There are two ways of going about this: 1) Constantly read and
decode whatever comes under the head, or 2) Read an entire track image into
memory and then decode it. Both of these work, as the sectors are laid out
(basically) one next to another. I can't remember if the first way is
possible on a 1Mhz machine - you may end up reading every other sector due
to timing constraints.

	So, the really fast disk copiers generally read in a track, decode it,
and then re-write it. Some of them don't even decode the track - they just
read a bunch of data, figure out where the track starts and ends (using
methods that I'm not going to describe here), and then dump the track to the
target disk. Due to the way the data is encoded (which is a little bit weird,
as you're not allowed to put more than two 0 bits next to each other on the
Disk ][), it's more memory efficient to read, decode, write (assuming you're
going in chunks - read,decode, read,decode, ..., encode,write, encode,write
...)

	All of the stuff I've described here has to do with 5.25" disks. It's
what I'm most familiar with on that level - by the time the 3.5" drives had
come to the Apple // world, I had lost interest at this level. But, Apple's
3.5" drives are pretty much like the 5.25" drives, with enough differences
to make life interesting ;)

>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.

	Well, you'd probably have to do block->sector/track conversions, but
that's easy enough (with 8 blocks/track it's pathetically easy). As for the
rest of the code, most of what I know I got from fiddling around and from
reading _Beneath Apple DOS_, from Quality Software. They also wrote _Beneath
Apple ProDOS_, which might be a bit more of what you're looking for, but I'm
almost certain that the low-level info contained in _BAP_ is basically the
same as in _BAD_, perhaps with more of an eye towards the ProDOS way of
doing things. I'm almost positive that they include a track-read routine,
and if they don't, and programmer with more than 3 tufts of hair left to pull
out while writing the routines should be able to manage without any great
difficulties.

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


-- 
                      Jason Blochowiak - jason@madnix.UUCP
or, try:         astroatc!nicmad!madnix!jason@spool.cs.wisc.edu
       "Education, like neurosis, begins at home." - Milton R. Saperstein