What are the 16 bytes of metadata in disk sector headers for?

[hjalfi]

I'm reading Amiga floppy disks (context: http://cowlark.com/fluxengine).

An ADF file has 2x80x11 512-byte sectors.

However, an Amiga floppy disk has an extra 16 bytes of data in each sector header, which the documentation I've been able to find just says 'reserved for filesystem use'. So, an Amiga sector really stores 528 bytes of data.

But ADF files don't store this, and given that I can boot uae off an ADF system disk just fine, this suggests that the Amiga filesystem does not, in fact, use this data.

So what's it for? Can I get away with ignoring it completely? If I can't, how am I supposed to represent it in a disk image, given that ADF doesn't store it?

[ross]

Originally Posted by hjalfi

I'm reading Amiga floppy disks (context: http://cowlark.com/fluxengine).

An ADF file has 2x80x11 512-byte sectors.

However, an Amiga floppy disk has an extra 16 bytes of data in each sector header, which the documentation I've been able to find just says 'reserved for filesystem use'. So, an Amiga sector really stores 528 bytes of data.

But ADF files don't store this, and given that I can boot uae off an ADF system disk just fine, this suggests that the Amiga filesystem does not, in fact, use this data.

So what's it for? Can I get away with ignoring it completely? If I can't, how am I supposed to represent it in a disk image, given that ADF doesn't store it?

Yes, not used in any (standard) filesystem, you can safely ignore it.
If you want to store this data in a file you need to resort to extended ADF.

PS: welcome on board

[hjalfi]

Is there a standard extended ADF format for storing this sort of thing? Or do I need to come up with a custom format (which no emulator would understand, of couse)?

[ross]

Originally Posted by hjalfi

Is there a standard extended ADF format for storing this sort of thing? Or do I need to come up with a custom format (which no emulator would understand, of couse)?

Custom MFM format.

Perfectly usable by WinUAE.

[Toni Wilen]

There is no "cooked" (not based on raw MFM) format that is able to store both data and sector headers. Ext adf is quite simple, short format description is in UAE disk.c.

I think there was one or two programs that used sector headers for some purposes but I don't remember any names.

[mark_k]

PackDev supposedly supports storing and writing back sector header data. WinUAE supports PackDev (.pkd) files.

I say supposedly, because I seem to remember playing with it and not being able to write or read anything other than all-zero sector header data. I took a .pkd file, hex-edited something non-zero in the part corresponding to sector header data, then wrote the .pkd to a floppy (extended ADF). On creating a .pkd from that floppy, I think the sector header data in the .pkd file was all-zero. That was a while ago though, maybe I mis-remembered???

[mark_k]

Ugh, I checked the PackDev source code. Back in the day I archived my original Amiga disks using PackDev because it was supposed to archive/handle sector label data...

(Some comments etc. deleted from the source extract for brevity.)

/*
Read sectors

Inputs:  DiskExtIO    Pointer to IOExtTD
         SectorBuffer Buffer for sector data
         LabelBuffer  Buffer for LabelBuffer data
         Offset       Number of first block to read
         NumBlocks    Number of blocks
         Block size   Size of a block in bytes
         Diskchanges  Number of disk changes having to stay constant,
                      -1 to ignore it

Return:  None

Comment: Note that an ETD command is not used because some HDs don't support
         them (e.g. oktagon.device). To avoid the disk change problem, the
         number of disk changes is checked by hand.
         It is a good idea to use buffer pointers divisable by 4 because HD
         devices may be much faster with this

*/

VOID ReadSectors(struct IOExtTD *DiskExtIO,APTR SectorBuffer,APTR LabelBuffer,
  ULONG Offset,ULONG NumBlocks,ULONG BlockSize,LONG Diskchanges,LONG Errblk)
{
	DiskExtIO->iotd_Req.io_Command=(UWORD) CMD_READ;
	DiskExtIO->iotd_Req.io_Offset=Offset*BlockSize;
	DiskExtIO->iotd_Req.io_Data=SectorBuffer;
	DiskExtIO->iotd_Req.io_Length=NumBlocks*BlockSize;
	DiskExtIO->iotd_SecLabel=(ULONG)LabelBuffer;
	Do(DiskExtIO,Errblk,_SpcVerify ? IGNOREERROR:ASKRETRY);
}

ReadSectors() uses CMD_READ. But in order to actually read sector label data ETD_READ must be used instead. WriteSectors() has a similar problem (CMD_WRITE not ETD_WRITE). However it looks like FormatTrack(), used when writing to floppy disk with ETDFORMAT argument, might actually use ETD_FORMAT.

So you can probably use the current buggy PackDev to write sector label data to a floppy, but reading it back won't work (you'll get all zero bytes).

[hjalfi]

I'd like to tackle nibble disk formats one day --- there are some unpleasant wrinkles with my code, which assumes the data's broken down into sectors --- but that day is not today.

I hadn't realised that Amiga hard drives don't support label data. That explains why the filesystem doesn't use them. PackDev looks promising but I'd need to read the source to determine the file format. I'd have to mandate that you weren't allowed to use a packer, but as the uae code appears to ignore the packer field completely (https://github.com/FrodeSolheim/fs-u...file.cpp#L1059) that's probably not an issue.

TBH, I suspect that what I'm going to do right now is Nothing; my code already produces simple 512-byte sector arrays which means that they're ADF compatible, it looks like genuinely nobody is using the metadata fields, and I've just discovered a nasty sampling problem which manifests when reading the middle tracks of Macintosh 400kB and 800kB disks which means my foreseeable future will be spent slaving over a hot logic analyser, so I don't need to more on my plate right now...

(I'd have thought, though, that using the sector label would be a really cheap and easy way of annoying people who wanted to copy their games to a hard drive.)