For the morbidly curious, my notes on reverse engineering the VFL format. Unfortunately, as the actual data is compressed by track with some kind of LHA-variant compression, it's going to be a bit of a chore to figure out.
Code:
The documentation says the following disk types are supported:
2HC(1.44M)
2HD(1.25M)
2HC(1.21M)
2DD(720kB)
2DD(640kB)
2D (360kB)
2D (8インチ ) 注:2HDとしてファイル化されます
1S (8インチ ) 注:fオプションが常にONになります
Compression technique described as follows:
1.1 If all tracks have the same data, do not create a file.
2. Look at FAT and don't file unused clusters.
3. Compress for each track. I borrowed the LHA algorithm.
(Reference material 1)
VFL's have the magic word: VOL_FILE0100 (First 12 bytes), VFZ's: VFZ_FILE0010
It appears the next 12 bytes (0xC through 0x17) serve as the volume label, in text;
purpose of 0x18 - 0x1F unknown
0x20 WORD Cylinders [77 in example]
0x22 WORD Bytes Per Sector [1024 in example]
0x24 WORD Sectors Per Side (Heads * Sectors)? [16 (8*2) in example]
0x26 WORD Bytes Per Side (Heads * Sectors * BytesPerSector) [16384 (1024*2*8) in example]
0x28 WORD Bytes Per Sector Again? [1024 in example]
Next 18 bytes are unclear, but the same in all the examples:
01 00 01 00 02 00 05 00 06 00 C0 00 0B 00 C6 04 01 00
Starting at offset 0x3C, we have a null-terminated string of 40 bytes (41 including the null terminator at 0x64)
Following that is another null-terminated string of 122 bytes (comment field?) with the null terminator at 0xDF
The 32 bytes after that string (0xE0 - 0xFF) appear to be reserved and set to zero
Starting at offset 0x100 appear to be a series of 16-byte header entries (Not identical to NFD's 16-byte headers)
They run through 0x5CF, for a total of 1232 bytes in our example, 77 entries, one for each cylinder
So these are presumably 16 byte track headers of some sort (As these entries can be completely identical, it's unlikely they contain any geometry values)
16 Byte Track Headers:
0x0 DWORD Offset - Appears to be an absolute offset from the start of file to the data chunk for this track, for example, the first value is always 1536 (0x600)
Blank entries at the end will point to the end of file (i.e. they're set to the total file size)
0x4 WORD Chunk Size - Set to zero for blank entries, size in bytes of the chunk after compression? [Always < 16384 in example]
Yes, appears to be that, added to the Offset, should give you the start of the next chunk
0x6 BYTE Type Flag - Set to 01 if this track is all one value and not stored;
Set to 02 for normal stored tracks...
Set to 00 value for ?? Value, DWORD at 0x4 matches offset to next chunk [16384 in example, 8x2x1024?]
0x7 BYTE Fill Byte - Apparently the fill byte if the previous byte was set to 0x01; 0xE5 is a common value.
If Type Flag <> 1, then this will be 0x00
0x8 WORD ?? - Set to zero for Flag 01 entries, but not for 00 or 02
0xA WORD ?? - Set to zero for Flag 00 and 01 entries
0xC WORD Allocated Bytes - Generally 16384 in our example, except for the last couple entries (zero for blank)
0xE WORD Reserved - Always 0x0000