Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!hp4nl!telmail!neabbs!dirr
From: dirr@neabbs.UUCP (DIRK REISIG)
Newsgroups: comp.sys.amiga.tech
Subject: Trackdisk
Message-ID: <321112@neabbs.UUCP>
Date: 4 Mar 90 09:08:07 GMT
Organization: NEABBS multi-line BBS +31-20-717666 (13x), Amsterdam, Holland
Lines: 28

I am meddling with floppydiskdrivers on the Amiga for some time
now and I found two things perhaps worthy to bring up for
discussion.

--  MFM-deterioration.
Trackdisk maintains some data integrity scheme by calculating a
kind of CRC-value over the datapart of a sector. But only the
databits are involved in this calculation. The timing bits (e.g.
the one's inserted between a serie of zero's) are not involved in
this calculation.  If such a bit is read wrong from disk, it will
not be detected.  And if this bit is in a sector that is left
unchanged, this erronous bit wil be written back to disk.

An example: Let's look at a track with some sectors containing the
bitmap, and some other sectors containing a program.  The bitmap
will be constantly updated and the program never.  At one moment
there may be so much bad bits in the program sectors that this
track becomes not readable anymore.  Now you loose the bitmap too
(probable the root included) and you are left with an unreadable
disk.  It may take some time, but it will eventually happen!

--  Don't care buffers.
Building a new MFM encoder/maintainer for Trackdisk, I reached a
point to choose for the allowence of non-chip memory for data
delivery.  If you have fast buffers containing data to be written
to disk, there will be a moment that these are to be copied to
chip.  Why not when it is realy necessary: in Trackdisk.  And
because it is a dedicated algoritm, it will be the fastest way.
Consider the effects on the FileSystem and Addbuffers.