Oversize FDS disk images

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
rainwarrior
Posts: 7893
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Oversize FDS disk images

Post by rainwarrior » Thu Feb 14, 2019 9:26 am

Great Hierophant wrote:Bytes 1-5 are the ASCII for FDS, the DOS end of File Character $1A and the Number of Disk Sides
Bytes 6-8 are the ASCII for GDM, which is intended to stand for Game Doctor/Magicard.
...
Now you might observe that this limits you to four disk sides whereas the Game Doctor can use at least eight. What do you do then? You tack on another header after the end of the data on Disk Side 4 and continue with the data. The second header is identical to the first until Bytes 9-10, which represent the additional storage space required by Disk Side 5.
I think if you're going to go that route, just replace FDS+1A with GDM+1A directly. That would better let old emulators know that it's not the kind of file they think it is, and have a better chance of them producing a meaningful user error than having them incorrectly assuming it's a valid FDS file and trying to run it.

At that point, you can make the header whatever size it needs to be. There's no need to compromise to make it fit in 16 bytes, that's just seems a needless complication.

Get rid of the old "FDS" FOURCC, and make the rest of the header an appropriate size for the different format. You could still use the .FDS extension if you think that's important (though I don't, personally), but at least with a different FOURCC you don't have to make the cause of incompatibiliy so obtuse for people using older emulators. Leaving the old FOURCC on there will just "trick" them into trying to run something they can't.

User avatar
rainwarrior
Posts: 7893
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Oversize FDS disk images

Post by rainwarrior » Thu Feb 14, 2019 9:42 am

Though an additional question: if there are 8 sides possible, is there any reason why two sides of the same disk would need to be different sizes? Are there even more than one size for the disks in question at all, or can all these GDM disks be accomodated by one size of dump, just like worked for the FDS?

And if so... then maybe just change the FOURCC and don't add anything else to the header? Parsing would then be identical to FDS file parsing but with a different predetermined disk length.

tepples
Posts: 22160
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Oversize FDS disk images

Post by tepples » Thu Feb 14, 2019 10:09 am

Is there a possibility that a side will ever exceed 80000 bytes?

User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: Oversize FDS disk images

Post by B00daW » Thu Feb 14, 2019 2:11 pm

Well FDS homebrew scene is possible. Probably already had a couple? Not sure what the limitation would be since FDSEmu and FDSStick are out. Who's to say there can't be a 6 disk, 12 side game?

User avatar
rainwarrior
Posts: 7893
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Oversize FDS disk images

Post by rainwarrior » Thu Feb 14, 2019 2:33 pm

B00daW wrote:Well FDS homebrew scene is possible. Probably already had a couple? Not sure what the limitation would be since FDSEmu and FDSStick are out. Who's to say there can't be a 6 disk, 12 side game?
FDS homebrew is already accommodated, and it doesn't really have a limit on sides. This is about game doctor, though if a fixed size can be used for that there'd similarly be no real limit for it either.

lidnariq
Posts: 9859
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Oversize FDS disk images

Post by lidnariq » Thu Feb 14, 2019 2:58 pm

I suppose the obvious question is just how long does it take the FDS read head to go from the very beginning of the disk to the very end of the disk...

That times 12kB/sec should give the theoretical maximum possible to store on an overformatted disk.

User avatar
loopy
Posts: 396
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Re: Oversize FDS disk images

Post by loopy » Thu Feb 14, 2019 5:05 pm

The largest Game Doctor image I have is 66458 bytes (and that's really pushing the limits). The largest Game Doctor game I've seen is 12 sides. I guess 13, if you want to count the saver disk -- some Game Doctor devices do save states which adds another disk, I don't know if you want to accomodate that. If you want variable length disks and there's no real limit to the number of disks in a game, it'd be better to have a header per disk.

There is a physical limit to the disk size of course, and tweaking the motor speed / gap sizes you could squeeze out more bytes at risk of nobody being able to load your game. For homebrew images, I'd recommend staying within 64k for compatibility. That raises another interesting point - file size doesn't necessarily reflect disk size because gaps aren't included. You can easily make a disk image under 64k that doesn't fit by having hundreds of tiny files on it.

I like rainwarrior's suggestion. The FOURCC determines how it's parsed.
FDS^Z: Fixed length, 65500 bytes per side
GDM^Z: Fixed length, 66k (or whatever) per side. Put the size in the header for flexibility though.
Easy enough to expand. You can add a BIN type that includes GAP + CRC since I know some ppl have a hardon for that stuff.
Last edited by loopy on Thu Feb 14, 2019 10:20 pm, edited 1 time in total.

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Oversize FDS disk images

Post by koitsu » Thu Feb 14, 2019 6:50 pm

Loopy's proposal sounds good.

NewRisingSun
Posts: 1239
Joined: Thu May 19, 2005 11:30 am

Re: Oversize FDS disk images

Post by NewRisingSun » Sat Feb 23, 2019 2:54 am

Fancy Quickdisk (.FQD) Format Specification (removed)
Last edited by NewRisingSun on Tue Jun 25, 2019 8:30 am, edited 4 times in total.

User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: Oversize FDS disk images

Post by B00daW » Sat Mar 16, 2019 7:08 am

This reminded me of all the different memory mappers used for NES/Famicom cart rips. Guess those will be emulated if we're maintaining this format.

Post Reply