Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!hplabs!pyramid!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga.tech
Subject: Re: SDB and tracing through the ROMs
Keywords: SDB, BCPL, breakpoint
Message-ID: <5595@cbmvax.UUCP>
Date: 29 Dec 88 19:40:00 GMT
References: <1988Dec27.223345.29513@ziebmef.uucp>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 72

In article <1988Dec27.223345.29513@ziebmef.uucp> mcp@ziebmef.UUCP (Colin Plumb) writes:
>I'm trying to reverse-engineer the disk validator, and encoutering a few
>snags.  Could someone help me out?
>[stuff deleted]
>Also, in the interim, my attempts involving patching the rn_RestartSeg
>vector to go through a jump to the real code I set up in RAM cause
>machine crashes.  Can someone tell me what I'm doing wrong?
>
Yes, you're playing around in system structures and using private fields
that are not guaranteed to remain the same for all Kickstart releases.
You can consider this a polite slap on the wrist if you like :-)  Really
though, what you are attempting to do is completely unsupported, the only
way to take over a small part of the filing system is to write the big part
too and mount that on the appropriate device.

>So... suggestions?  My eventual aim is to have my format of floppy auto-
>recognised when a floppy is stuck in the drive, which I decided was
>best achieved by patching in my rn_RestartSeg disk validator, which
>would read the boot block, check the DOS type, and possibly punt to
>the old one, but might do what the current disk vallidator does
>(whatever that is), but using a different handler.
>
'fraid you have hit a pretty glaring hole in the current AmigaDOS filing
system environment.  Right now, the filing system is mounted on a device
and remains there for all time.  The mounted filing system decides if it
can grok the inserted disk, if it can't, it just says "not a DOS disk" and
gives up.  There is no facility for "passing-on" a disk to an alternate
filing system.  Unfortunately, this is what you need.

Once again, the solution is to mount your own filing system on the trackdisk
unit and do everything yourself.  To handle the case of the ROM filing system
you could send an inhibit packet to it when your task starts up;  this will
prevent it from snooping the disk before you do.  If a disk is inserted that
you don't recognise, simply send an uninhibit to the ROM filing system and
it will then log and check the disk instead.  Of course, you mustn't touch
the disk once this has been done.  There will also be complications when
the oldfs disk is removed and one of your disks is inserted.  Really, this
kind of trickery just ain't supported.


>In furtherance of this, I'm trying to reverse-engineer the disk validator.
>Any help at any stage of this descent to detail would be appreciated.
>
OK, that bit is easy, the disk-validator/restart code does the following
when a disk is inserted or the volume is uninhibited (by format for example).

1.  Read the boot block, if !DOS0 then "not a DOS disk"

2.  Read the root block and make sure the checksum is OK.
    Check various fields in the root block for consistency.  These include
    the hashtable size and the size of the volume name.  Parent key and
    a couple of others are checked to make sure they are 0.  If any of
    these tests fail then "not a DOS disk"

3.  Check the bitmap-valid flag in the root block.  If it's 0 then the
    validator will be called.  Under the old filing system, this involves
    loading it off *SOME* disk and creating a separate process.  Under FFS
    the validator runs on the same task as the main filing system code but
    as a separate co-routine (or thread or lightweight process, whatever :-)
    The validator code is an integral part of FFS, not loaded separately.

The main task of the validator is to check the files on the disk and report
any corrupted headers or duplicate keys etc.  If no uncorrectable problems
are found, then the bitmap is rebuilt and written to the disk (if there is
room).  If there's no room on the disk (which can be the case with floppies)
then just the memory copy of the bitmap will be used and the disk will get
validated every time it is inserted.

I won't go into the details of how the bitmap is built since this isn't
really pertinent to what you were asking about.  Hope this helps though.

	Steve