Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!ames!lll-lcc!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDOS & DISKED
Message-ID: <2781@well.UUCP>
Date: Tue, 17-Mar-87 03:03:49 EST
Article-I.D.: well.2781
Posted: Tue Mar 17 03:03:49 1987
Date-Received: Wed, 18-Mar-87 07:02:14 EST
References: <1395@husc6.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Distribution: world
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 134
Summary: Here's one person's answer....

[ 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. ]