koster@cory.Berkeley.EDU.UUCP (07/02/88)
In article <734@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >I am having a most difficult time trying to TD_RAWREAD and WRITE whole >tracks from/to the trackdisk. ... Could you have set the IOTDB_INDEXSYNC flag some how and set it up to for a pattern that doesn't exist on the disk? How are you setting up the iorequest block? I've never used those routines. Maybe your write protect tab is set on df1:. You seem to be able to do something to DF0:. Maybe you cannot just do a rawread then a rawwrite. THere is the gap between sectors to worry about. When trackdisk reads a track in, it starts anywhere at a 4489 sync word. This could be any sector. Then it does a block move to get rid of the gap and put all 11 sectors together. Maybe you have to clean up the raw data before you can do a write. Cleaning up could be repairing missing 4489's at the start of each sector, re-aligning the sectors, patching the byte that tells sectors to gap, etc. In short, just what trackdisk must do. Tell us more about how you are setting things up. These are general suggestions and may not be of use.
dirr@neabbs.UUCP (DIRK REISIG) (03/04/90)
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.