Unable to load unofficial disks which expect smaller gap sizes

[TakuikaNinja]

Trying to load Sunsoft's Tile Editor (Newer version) on the FDSKey results in error 25. The display shows the disk as being filled completely, despite the fact that all the file blocks fit well within a single-sided .fds file. I'm wondering if there's an inaccuracy regarding the gap size between files (mainly block types 3 & 4). Editing the file amount to 3 (the minimum required to boot the tool) works fine for now but it's quite annoying that the included graphics files cannot be loaded at the moment.

The Sunsoft Dev Disks which contain the program in question will not be linked here. The archived disks aren't hard to find.

[TakuikaNinja]

Update: this might apply to more unlicensed/unofficial disks than I initially thought. I just tried "The Golf - Bishoujo Classic" and it fails to load the B side for seemingly the same reason. I'm guessing that these disks use/expect a smaller gap size compared to licensed disks.

[TakuikaNinja]

I've had a look at some resources regarding the gap sizes. The NESdev wiki article for the disk format appears to have had these numbers for the gap sizes since 2012 (originally present on the FDS hardware article before being moved):

• Before the start of the disc : At least 26150 bits, 28300 typical.
• Gap between blocks : At least 480 bits, 976 bits typical.

Meanwhile, the technical reference by Brad Taylor from 2004 lists the following:

• The length of the first GAP period present on typical FDS disks (relative to the instant the disk drive's "-ready" signal is activated) is about 40000 bits, after which the first block start mark (indicating the beginning of the first file) will appear.

• Writing to the disk does not occur in sync with the existing data on the disk. Where a write period starts and ends is bad news because it creates a gap between pulses almost always of an invalid length. This would lead to the RAM adaptor misinterpreting the data, causing errors. To overcome this, the RAM adaptor always ignores the first 488 bits (aprox.) to follow after the immediate end of any file. This period allows the RAM adaptor (or the game rather) an oppertunity to make the switch from reading from the disk to writing or vice-versa.

• The typical GAP period size used between files on FDS disks is roughly 976 bits (this includes the bits that are ignored by the RAM adaptor).

So 480~488 bits may need to be considered as the minimum gap size for the contents of these disks to fit onto a disk side?

I suppose this has only become an issue now because the FDSKey needs to read a .fds format file (which lacks gaps/CRCs) and provide an accurate data stream including gaps/CRCs, while somehow keeping track of the disk capacity in case a disk image actually managed to overfill a disk side. For reference, VirtuaQD (a generic QD drive emulator) and its disk image conversion tools use an MFM encoded format. It treats a complete disk side (excluding the external header) as 80KiB on the FDS. I can't recall any other cases of the "true" capacity being measured or referenced.

[TakuikaNinja]

I have example files which reproduce the issue, based on a WIP version of a disk capacity test program I've been writing:

• disk-capacity-tests_cfff.fds has the final file at $CFFF bytes long, which FDSKey claims as fitting within a disk side.
• disk-capacity-tests_d000.fds has the final file at $D000 bytes long, which FDSKey claims as not fitting within a disk side.
  disk-capacity-tests_wip.zip

They don't do anything special upon loading - FDS Disk Lister can be used to list the disk contents if needed. Both versions have their contents fit well within a single-sided .fds file (~7398 bytes free).

[TakuikaNinja]

I really should have said this sooner - If the loaded disk side is full, the FDSKey seems to omit the file data which exceeds the limit instead of truncating it like on a real disk. The BIOS is capable of detecting when files prematurely end during reads/writes.