hull@hao.ucar.edu (Howard Hull) (07/03/89)
While doing the Fatter Agnus upgrade, I also put in the AmigaDOS v1.3 ROM upgrade (which, so I hear, is needed by the Fatter Agnus) and put the local autoboot ROMs in the A2090A card. I am using the A2090A with a Quantum 80s hard drive. Before doing all this I wanted to backup the hard drive, and before doing that I wanted to check the condition of the file system to anticipate any problems with data recovery. Some of you will remember articles that I and other individuals posted to the net that recommended a prep using 739 cylinders (0-738) with 37 sectors per track, even though the Quantum 80s is a two-zone drive with some 264 cylinders at 28 sectors per track and 570 cylinders at 35 sectors per track - the specified block total is supposed to be 164058 blocks in 5004 total tracks. Well, just for the heck of it I ran DiskSalv1.4 on the outer partition of the disk, just to see what it would find. Surprise surprise - it found errors on the last two blocks. This indicates to me that either the usable block total is really 164056 (since my grand total for all of the disk was indeed accurately accountable to 164058), or some parameter was eating two of the blocks. I remember stating in the article that I could find no combination of sectors per track and total cylinders that would yield any result except 164052 or 164058, but never mind, what I see is what I get... There was some confusion expressed in my earlier article concerning the Reserved parameter - the A2090A manual recommends using "Reserved = 2" without saying why one needs to do that. However, as near as I can determine, the Format routine accounts for the Reserved blocks for use as the boot blocks for the volume, and simply allocates them in the bit map. I think I also noted that the AmigaDOS file system has 26 bitmap pointers, with each bitmap capable of accounting the use of 4096 blocks, giving a maximum of 54,525,952 bytes of disk storage which, at 488 data bytes per block allows a 54 megabyte AmigaDOS partition with a maximum data content of 51,970,048 bytes. Well I probably have an error there, too, as there is a four byte checksum in each bitmap (according to a recent Amazing Amiga article). If such were the case, then the 26 bitmap pointers could each only point to 4064 blocks, and that would allow the partition to account for 54,099,968 blocks (still 54 meg, I suppose), with the data content settling slightly to 51,564,032 bytes - which is about 400 Kbytes smaller than what I stated in the article. Sorry... So none of this explains why the two blocks had errors, nor does it say anything about why the Format reported no validation problems. (And I know that they are hard errors, as I re-formatted (no QUICK, either) and ran DiskSalv again with the same result on the uncluttered partition.) As I said, I was forced to decide that the blocks in question were simply not available. So - and this is the upshot of all this gibber, I changed my prep parameters to specify 882 cylinders (0-881) at 31 blocks per track, re-formatted, and was pleased to see that I could DiskSalv all the blocks. So if you, as well, used the 739-track recipe, some day you may be in for a surprise - a bad file that spans the end of the file system... Also, one example I showed had "Reserved = 0" in all partitions. That was a compositional error on my part, as I had it set to 2 in the DH2 partition and outedited myself swapping mount tables in the posted article - again, sorry... I was able to run all but the bootable partition with 0 for the Reserved value, though. It is entirely likely that the Reserved value is for the two blocks used for the volume boot code, and the reason for always using 2 is that if you ever change your mind about which partition you want to boot, and you preped it with 0 you will be in for a disk error if you have a file spanning those blocks and the system wants to write the boot in there. (This is probably one of the reasons one is cautioned not to re-prep unless one is committed to retrieving the disk content from backup. You could use exactly the same prep except for which partition has the two Reserved blocks, and prep would write the boot exactly where you told it to - in the middle of a previously stored and presently accounted file.) It's is not likely to be a problem for a lightly loaded partition, but there are folks on the net who routinely run out of disk space in 60 meg partitions, and the way some routines write to the disk this could happen at something around 60% or 70% of full capacity. For the last part of this note I want to add that it appears my Quantum 80s (from Hard Drives International) is indeed one of the ones that does not get up to speed in time for the A2090A Binddrivers kiss'n-go autoboot. I see the drive light respond to whatever Binddrivers does, and the drive does get mounted ok - BUT the A2090A puts up the disk in the hand of your helpful AMIGA hardware man... and wants to boot from the floppy. Blast. Has anyone yet come up with a way to coaxing the A2090A into hanging on for an Alfred E. Packer style standoff until the disk is able to comply with the boot procedure? Howard Hull hull@hao.ucar.edu