may@husc4.HARVARD.EDU (may) (03/16/87)
I've been playing with DISKED - yes, I know, dangerous - and I have some questions about disk layout in AmigaDOS. The material in the few pages on it in the AmigaDOS manual put out by Bantam is very meagre. How is the disk bitmap laid out? The root block contains about 25 long words giving the location of the disk blocks containing the bitmap, but their is nothing in the manual saying how the bitmap is stored. If the format is one bit per disk block, with the condition of the bit giving the allocated/unallocated condition of the block, then 1760 disk blocks should only take up 55 long words. Is this correct? If so, then which order are the blocks described in? Does the condition of the first bit show the condition of disk block 0, or disk block 1759, or something else? I'm trying to lock out permanently damaged sectors by putting them all in a file, but I can't figure out how to tell the system that those blocks have been allocated, and not to give them to another file. Thanks in advance, Jason May may@husc4.harvard.edu seismo!harvard!husc4!may
glu@gypsy.UUCP (03/16/87)
Just a hint on how I have been using Disked so far. I usually don't bother about the bitmap. After I have recovered some files or changed anything in the file structure, all I do is set the bitmap-valid flag in the root block to false, recompute checksum and save root block. When I use the disk for the next time Amiga's disk validator takes care of updating the bitmap. I have used Disked pretty often in the past (before there was Diskdoctor) and I haven't gotten into any problems with this approach. Of course, if you want to do anything special just concerning the bitmap, like blocking of dead sectors, then this doesn't work. Raimund Gluecker Siemens RTL Princeton, NJ princeton!siemens!glu
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/17/87)
[ 81000005.00237F3E ] In article <1395@husc6.UUCP> may@husc4.UUCP (Jason May) writes: >I've been playing with DISKED - yes, I know, dangerous - and I have some >questions about disk layout in AmigaDOS. The material in the few pages >on it in the AmigaDOS manual put out by Bantam is very meagre. >How is the disk bitmap laid out? [...] > > Thanks in advance, > Jason May >may@husc4.harvard.edu seismo!harvard!husc4!may Some time back, I wrote a little goodie to display the bitmap allocation on a disk. I posted that program here, and it also appears on Fish Disk #33. Rather than repost the whole program, I'll just repost the pertinent code and explanatory comments. This should give you enough information to utilize the disk's bitmap. Note that the following is rather dependent on floppies. The code will undoubtedly require major hacking to work on a hard disk, or Perry's RRD. If you'd like the whole program, I can mail you a copy that will compile under MANX. Send me mail asking for it. Hope this helps. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun." _-_-_-_-_-_-_-_-_-_-_-_- Code sections follow: -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ /* :ts=8 bk=0 * Disk mapper. Uses trackdisk.device to grab and read sector bitmap * to discover what's allocated, then displays a (hopefully) pretty picture * showing disk useage. * * Crufted together by Leo Schwab while desperately bored. 8606.8 * Turned into something working for the Manx compiler. 8607.23 */ #include <exec/types.h> #include <exec/memory.h> #include <intuition/intuition.h> #include <libraries/dos.h> #include <devices/trackdisk.h> #define REV 0L #define BLOCKSIZE TD_SECTOR #define NUMBLOCKS (NUMCYLS * NUMHEADS * NUMSECS) #define ROOTBLOCK (NUMBLOCKS / 2) #define BITMAPINDEX 79 #define NUMLONGS (NUMBLOCKS / 32) [ ... ] main (ac, av) char *av[]; { long k, x, y; int unit, bmsect, free = NUMBLOCKS-2; short i, n, l; char buf[80]; if (!ac) { /* Run from workbench (ick!) */ strcpy (buf, "df0:"); } else { /* Run from CLI (thank you) */ if (ac == 1) { printf ("Drive specifier: "); gets (buf); } else strcpy (buf, av[1]); } openstuff (); if (!(lok = Lock (buf, ACCESS_READ))) die ("Can't obtain lock for specified device."); if (!(id = AllocMem ((long) sizeof (*id), MEMF_CLEAR))) die ("Can't get InfoData memory."); if (!Info (lok, id)) die ("Call to Info() failed."); if (id -> id_DiskType == ID_NO_DISK_PRESENT) die ("No disk in drive."); unit = id -> id_UnitNumber; FreeMem (id, (long) sizeof (*id)); id = NULL; opendisk (unit); /* Opens trackdisk.device for given unit */ MotorOn (); GetSector ((long) ROOTBLOCK); bmsect = diskbuffer[BITMAPINDEX]; GetSector ((long) bmsect); MotorOff (); /* * At this point, we now have the bitmap in the disk buffer. * This is what the first longword in the bitmap represents: * * 333322222222221111111111 * 32109876543210987654321098765432 Sector # * -------------------------------- * 10100101001010010010010001010011 Longword * MSB LSB * * If the bit is set, the sector is free. * * Sectors 0 and 1 contain the boot block. Thus, the DOS is not * allowed to walk on them, and they are permanently allocated. * However, the bitmap does not reflect this i.e. the bitmap starts * at sector 2, which is indicated by bit 0, longword 1. This means * we have to offset everything by two. Can you say "crock?" * * Actually, I suppose this is good, since it prevents some would-be * smart person from un-allocating those sectors and messing things * up badly. * * Bitmap starts at longword 1; longword 0 appears to be some kind * of significant garbage (checksum?) * [Bitmap ends at the NUMLONGS'th longword in the diskbuffer.] */ [ remaining code deleted. ]