Changes to jdisk.device
=======================

Steve Beats
===========


Jdisk.device (the program to allow the Amiga to use a partition on a PC hard
disk) now supports bad block mapping.  Two programs were changed on the
A1060|A2000 Workbench.  These programs were c/DJMount and devs/jdisk.device.

A couple of changes will be needed for the documentation.  These changes are:

        The user should be warned that formatting takes a L--O--N--G time.
        It takes just over 5 seconds per track because each track is being
        written and read back again twice.  There is a slight overhead if
        a bad block is found and has to be mapped, but this is negligible
        compared to the overall format time.  Special mention should be made
        of the format time for track 0!  To prevent the need for an extra
        program, jdisk automatically creates the bad block map whenever
        track 0 is formatted.  Since these blocks are VERY important, they
        are given special attention when it comes to testing them.  The
        bad block map is held on the last 2 cylinders of the partition and
        is formatted at the same time as track 0.  Each block is tested
        and entered into a map-block table if it checks out OK.  A maximum
        of 127 bad blocks can be mapped to these good ones (providing no
        map blocks were excluded because they too were bad).  Because of
        all the extra work involved, track 0 will take approximately
        10 to 15 seconds to format.  The program hasn't crashed.
        (NO! It is not possible to display a 'wait a minute' message!)

        There is now a slight inconsistency between the number of cylinders
        allocated to the Amiga partition by the program 'ADisk' and the
        number of cylinders AmigaDOS actually gets.  This is due to the
        changes in DJMount.  When DJMount is executed it sends an enquiry
        to the PC (through the Janus interface) asking about the partitions
        that are assigned to the Amiga.  It retrieves information concerning
        number of heads/surfaces/sectors-per-block etc. and feeds this
        stuff to AmigaDOS by building a unit structure.  DJMount now reserves
        2 cylinders for the bad block map.  These cylinders had to be put
        at the end of the partition to account for a bug in DPFormat which
        calculates the root block position incorrectly if the base cylinder
        is not cylinder 0.  Since we don't have the source for DPFormat we
        are stuck with this for all time.  Even if we could fix it later, we
        will have to leave the bad blocks where they are because everyone's
        hard disks would be set up like this by that time.  Because two
        cylinders are reserved, DJMount will totally ignore any partition
        with less than 3 cylinders.


Other stuff
===========
The format command at the device level (CMD_FORMAT) is no longer asynchronus!
Jdisk.device was not initially designed with bad block mapping in mind.  It
worked well as it stood, but I had to re-write large sections and cheat in
others to make it handle bad blocks.  CMD_READ/WRITE and all other device
commands will return to the caller immediately and reply the IO_Request when
the function has been performed.  CMD_FORMAT will not return to the caller
until the format has completed.  This shouldn't cause any problems because
AmigaDOS waits for the format to complete before doing anything else anyway.

If the Amiga partition has enough bad blocks to fill the bad block table, then
jdisk will ignore any subsequent bad blocks.  This means that the verify part
of the format command will fail when it reaches those blocks that have not
been mapped to good ones.  I consider this to be OK, since a 20/40MB disk
with more than 100 bad blocks is probably well on the way to the scrap heap
anyway.  If this does become a problem (ie. someone wants 50% data and 50%
bad blocks) I can change the code in a reasonable amount of time.

I FOUND A TERRIBLE BUG IN DJMOUNT !!!!!  This bug has been with djmount ever
since it was first released.  I'm amazed that people haven't been screaming
thier heads off about it.  With the current DJMount, when the Amiga partition
on the PC hard disk becomes half to three quarters full, the boot block is
written over by AmigaDOS itself.  This means that next time you boot the
machine and run DJMount, the partition that is getting full will make
AmigaDOS put up the "Not A DOS Disk" requester and ALL data will be lost.
(I spent 3 hours looking for that bug in my bad block code until I decided
to try it with the old jdisk.device!!!)  Did anybody report this ?  Don't
tell Henri or he'll have kittens.  Anyway, it's fixed now and we should get
the new version of DJMount out there as soon as possible.  It was really
quite a simple fix and mainly due to the lack of documentation on the
internal workings of AmigaDOS, specifically about the BlksReserved field
of a unit structure.

   TESTING! TESTING! TESTING! TESTING! TESTING! TESTING! TESTING! TESTING!
Believe it or not, I was unable to find a bootable hard disk with real bad
blocks on it.  I tested the bad block mapping by inserting a random error
generator into the block testing routine.  I made it generate fake errors
on the disk about 5% of the time.  I used diagnostic printouts to determine
if the block was being mapped to the correct place and checked the data
that was being mapped to the good blocks.  Everything SEEMS alright.  After
about 5 hours of testing, my hard disk developed a real error.  It was one
of the errors listed in the defect map.  It was at this point that I found
a serious problem with the bad block detection.  It just isn't reliable with
marginal errors.  Out of 20 formats of a small section of disk containing
a hard error, 13 passes didn't detect any error at all, 5 passes detected
the error and mapped it correctly on format and verify cycles, 1 pass got
the error on the first cycle but appeared to find another on the second and
1 pass caught and mapped the error on the first pass but failed on the
verify cycle.  I doubled the number of checks on the disk after I got these
results and did 10 more format checks.  In this case 6 out of the 10 passes
were mapped correctly and 4 didn't detect any error at all.  Unfortunately,
doubling the number of checks on the track doubled the format time to 11
seconds per track or almost 2 hours for a 20MB disk, not counting the
verify pass.  I don't know what to do about this!  It seems that the only
reliable way to detect errors is to read a track about 10 times and seek
all over the disk between each read.  This would take days to format!!

Concerning the above problem.  It just occured to me that system/format
formats and verifies each track in turn (instead of formatting all and then
verifying all like DPFormat does).  If Andy Finkel gets system/format
working with jh0: then the problem may go away.  At least if the check
for bad blocks fails, then the verify won't find anything wrong either
because there is no head stepping happening between the two operations.

It is not possible to map bad blocks if a read or write error occurs AFTER
the disk has been formatted.  However, MSDos can't do this either so it's
not really that much of a drawback.

