Oversize FDS disk images

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

Moderator: Moderators

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

Re: Oversize FDS disk images

Post by rainwarrior »

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: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Oversize FDS disk images

Post by rainwarrior »

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: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Oversize FDS disk images

Post by tepples »

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 »

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: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Oversize FDS disk images

Post by rainwarrior »

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: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Oversize FDS disk images

Post by lidnariq »

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: 405
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Re: Oversize FDS disk images

Post by loopy »

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: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Oversize FDS disk images

Post by koitsu »

Loopy's proposal sounds good.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Oversize FDS disk images

Post by NewRisingSun »

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 »

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.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Oversize FDS disk images

Post by aquasnake »

FDS has 65500 bytes of data per disk side, which is a constant and is defined specifically for FDS.

For "game doctor", only one parameter needs to be modified:

side_ end = (side_ offset == 65499);



In this way, you have to redefine file suffixes for this disk format and do not need to be compatible.

The size of each side used is different, which does not mean that the size of the image format is different. The actual data used must be less than or equal to the set size of the maximum image. Therefore, a public maximum image value is defined. According to the limitation of the size of the physical disk, a value with low address lines of 0 can be selected

Remove common duplicate data from each side, such as for a fixed text string, so that the final dumped image is within 65500 bytes. I think this is not recommended. It destroys the disk record and needs extra cost to restore to the original image. Similar to that, you have compressed the data and removed the redundant files. However, the original meaning of these redundant files is to save the physical cost and do not need to repeatedly insert different disks to read them out. Therefore, the data are stored on different disks
Post Reply