🚀 go-pugleaf

In article <4339@sugar.hackercorp.com> (Peter da Silva) writes:
>Is this a significant problem with only one file to open? That is, once the
>file is open, will it continue to slow things down to have the header block
>on a different track?

Last time I checked the floppy file system did not cache the header blocks
specially (unlike FFS which does). Thus if the file itself was bigger than
your addbuffers command you could find yourself rereading the directory and
header blocks. 

On the question of exactly what do you have to do to make this happen,
the answer is straightforward, but not exactly simple. 

You have to use the trackdisk.device to circumvent DOS being helpful
in laying the blocks down for you. But the cheap way goes something
like this :

Format a fresh floppy, use Leo's used block display program (Fm) from 
Fish Disk 36 to note which blocks are used and not used. You should be
able to find several tracks that are not used. Then declare an array
in your code that looks something like :

/* Note that the ExtensionBlock and DataBlock structures can be derived
 * from information in the DOS Technical Reference manual (or the Bantam
 * AmigaDOS manual), or from some structures Carolyn posted on BIX.
 * NOTE: Must be in CHIP Ram for floppies. 
 */

	struct HeaderBlock 	*HB;
	struct ExtensionBlock	*EB;
	struct DataBlock	*DB;
	ULONG			*RawData;
	
	...
	/* Number of blocks needed to hold the data */
	DataBlockNum = ((FileDataSize + 487)/488);

	/* Number of extension blocks that will be needed */
	Extension_Blocks = (DataBlockNum - BLOCKS_IN_HEADR)/BLOCKS_IN_EXT;
	
	/* Total blocks (1 == Header block) */
	FileSize = DataBlockNum + Extension_Blocks + 1;

	RawData = (ULONG *)AllocMem(FileSize*512, MEMF_CHIP+MEMF_CLEAR);

	InitializeHB(RawData); /* Fill in the header block */
	for (i=0; i<Extension_Blocks; i++)
		InitializeEB(RawData +			/* Data Pointer */
			((BLOCKS_IN_HEADR+1) * 128) +	/* Skip over headr */
			((BLOCKS_IN_EXT + 1) * 128) * i); /* each extension */

	/* Note the define/function MAPBLOCK which should figure out where
  	 * in the rawdata array the blocks should be placed
	 */
	for (i=0; i<DataBlockNum; i++)
		InitializeDB(MAPBLOCK(RawData, i)); /* and the data blocks. */

	mp = CreatePort(0,0);
	ior.ReplyPort = mp;
	OpenDevice("trackdisk.device", ...);
	ior.io_Command = TD_WRITE;
	ior.io_Length = FileSize*512;
	ior.io_Data = RawData;
	ior.io_Offset = Sector_0_of_Track_nn;
	DoIO(ior);


Now this is only a rough sketch and you should really do error checking and
for a general tool you should be able to deal with low chip memory situations
such that you might only be able to write one sector at a time. 

After writing the track, you need to read in the rootblock, add an entry in
it's hash table for your file. Then set the Bitmap invalid flag and exit.
now do either a DiskChange or pop the disk out and re-insert it. To update
the bitmap. Now when A-DOS reads your file it will be as efficient as 
possible because the heads will always be over the track they need to be
on to read the data.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"If I were driving a Macintosh, I'd have to stop before I could turn the wheel."