This is the floppy format used by the Virtual98 emulator. Most of the below is from Ashura's post on the FMV forums, although I have added notes, generally indicated in italics below.
The data block containing the sector contents can be stored in any order, and each segment is pointed to via the offset in the Sector Map. As such, it is frequently not in C/H/S order.
0xC3FC (50172 bytes) fixed-size header, followed by raw sector data
Header:
0x0 - 0x6 = Magic Word "VFD1.00", Virtual98 only actually checks the first three bytes, the "version" part is ignored
0x7 = Reserved, 0x0, Virtual98 ignores this, VFIC requires this to be zero
0x8 - 0x87 = Comment field (128 bytes)
Virtual98 will display the first 128 bytes of this (through offset 0x87), does not recognize FF FF as a terminator, or appear to require one.
0x88 - 0x89 = WORD - Write Protect (per NP2)
0x8A - 0x8B = WORD - Special Read Drive (Per NP2) - 0xFFFF indicates no special read
MKFDD parks 0xFF 0xFF at 0x8A and 0x8B, VFIC does not
0x8C - 0xDB = Reserved (Should be all 0x00)
Adding text right up to offset 0xDB doesn't cause any problems for Virtual98, indicating this area isn't used for anything.
VFIC will refuse to convert any FDD file if those reserved bytes aren't filled with nulls (0x00) to FDI, although it will read the comment area to display, and convert to BKDSK format
Sector map starts at offset 0xDC, with 12 bytes for each sector:
Each entry of the sector map has the following structure
- 0x0 = track number (if 0xff the sector/track is unformatted/unused)
- 0x1 = head number
- 0x2 = sector number
- 0x3 = sector size (128 << this byte)
- 0x4 = fill byte. if it's not 0xff, then this sector in the original
disk consisted of this single value repeated for the whole
sector size, and the sector is skipped in the .fdd file.
if it's 0xff, then this sector is wholly contained in the .fdd
file
- 0x5 = DDAM (Deleted Data Flag) (By default, appears to be 0)
- 0x6 = MF (Double Density Flag)
- 0x7 = 2HD Flag (By default, appears to be 1)
- 0x8-0x0b = absolute offset of the data for this sector, or 0xfffffff
if the sector was skipped in the .fdd (and it has to be
filled with the value at 0x4)
FDD assumes that all tracks have 26 sectors. You'll need to dummy out the rest of the entries if your disk has less than 26 sectors/track.
There are thusly a total of 26 * 160 = 4,160 of these 12-byte sector map entries
Lastly, there's a 32 byte header tacked on to the end of that, starting at 0xC3DC
(If the Special Read value in the header was defined as 0xFFFF, this will all be zeroed)
Even if you don't, and leave that as 0x0000, it appears you can use the following data:
FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 FF FF FF FF FF FF FF FF 00 00 00 00
The "Special Read Data" defined as below:
/ * Data at the time of special reading * /
typedef struct {
SINT16 trk; // Current track position
UINT16 iax; // Input register value
UINT16 ibx;
UINT16 icx;
UINT16 idx;
UINT16 oax; // Output register value
UINT16 obx;
UINT16 ocx;
UINT16 odx;
UINT16 ofl;
SINT32 dataPoint; // File pointer to the data
SINT32 nextPoint; // File pointer to the next data
SINT16 count; // Special read counter
SINT16 neg_count; // Count ignore flag
}
Emulation Data It appears the Special Read Data contents are not actually implemented and are ignored, regardless of the value set, at least by Virtual98 0.28. The format as specified above allows for chaining of multiple special read segments, but this has not been observed in any known images. Track Limits Because it assumes a maximum sector and track count, this format cannot handle overtracked (> 160 track) disks, or those with more than 26 sectors/track (No standard disk layouts have this) VFIC will let you convert the images to FDD format but it also gives you a warning that the additional tracks are ignored. FIVEC will not let you convert such images to FDD at all. In short, it means each of your FDD images would be missing the last 18432 bytes (2 tracks * 9 sectors * 1024 bytes). Version 1.01 One of the common versions of the game "177" by Macademia Soft has an identifier of "VFD1.01" and claims in the comments to have been "Converted by VFIC(No!Anex86 Version)" but there is no known version 1.01. The image works correctly when the magic number/version ID is changed back to 1.00.
