It is currently Tue Feb 19, 2019 4:34 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 38 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Oversize FDS disk images
PostPosted: Tue Feb 05, 2019 11:29 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
I would like to release a few Game Doctor/Magicard disk images. They are mostly like regular FDS disks, the major difference being that most of them cram more than the standard 65,500 bytes into a side; the longest I have seen is 66,184 bytes on a Magicard disk. How to represent such a multi-disk set using the headered "fwNES" FDS file format, which assumes a fixed size of 65,500 bytes per side? Games use between 1 and 8 disk sides.

I would just amend the definition to "at least 65,500 bytes per side. To reach the next side, advance 65,500 bytes from the start of the current side, then further until \x01*NINTENDO-HVC* (begin of block 1) is found", which works well enough for any standard-size as any oversize disk.


Last edited by NewRisingSun on Wed Feb 06, 2019 9:34 am, edited 3 times in total.

Top
 Profile  
 
PostPosted: Tue Feb 05, 2019 2:11 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 617
The simplest solution might be to give those disks another extension and add a section on the FDS page defining the differences between .fds files and those? (rather than having non-FDS disks labelled as .fds files, assuming the hardware that uses those disks isn't identical to an actual FDS unit in behavior). It might help avoid confusion and allow emulators to tweak the behavior for either type of disks as needed.


Top
 Profile  
 
PostPosted: Tue Feb 05, 2019 11:24 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
The disks are read by the FDS disk drive and the FDS RAM adapter. The devices connect in-between the Famicom main unit and FDS RAM adapter, provide additional bank-switched RAM, and substitute the $8000-$FFFF area with that RAM and their own BIOS only once activated.

The question was not how to distinguish oversize from normal FDS disks, but how the oversize disk should be represented in the image, how the file should be laid out.


Last edited by NewRisingSun on Wed Feb 06, 2019 12:15 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Tue Feb 05, 2019 11:40 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
(example files removed per request)


Last edited by NewRisingSun on Wed Feb 06, 2019 2:07 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 12:20 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 388
Location: UT
If they are Game Doctor images, why not release them as such? (*.A, *.B, etc)

Quote:
To reach the next side, advance 65,500 bytes from the start of the current side, then further until \x01\x2A (begin of block 1) is found"

This doesn't seem very safe to me. Since this is a bastardized .FDS format that breaks compatibility anyway, just pick the simplest thing that works. Go off of the file size, or put the disk length in the header somewhere.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 1:30 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
loopy wrote:
If they are Game Doctor images, why not release them as such? (*.A, *.B, etc)
For the same reason we do not put multi-side licensed FDS games in a separate file per side: inconvenience. That inconvenience is even greater for Game Doctor games, because you need all sides right away at boot time.
loopy wrote:
This doesn't seem very safe to me.
Every Game Doctor and Magicard disk still uses the \x01*NINTENDO-HVC* disk header, so I do not follow.
loopy wrote:
Go off of the file size, or put the disk length in the header somewhere.
The problem is that the length of each side differs, so one would either
  • have to specify a size for each of the maximum of eight sides in the yet-to-be-defined header, or
  • pad each side to the longest side. The side length then is derived from (fileSize -16) /numberOfSides.
The second solution would also work nicely with licensed FDS images, which is why I like it more.


Last edited by NewRisingSun on Wed Feb 06, 2019 2:04 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 1:59 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 388
Location: UT
*shrug* Inconvenience of multiple files, or inconvenience of another new unsupported (except in your own emulator) format. I prefer the former, personally...

Quote:
Every Game Doctor and Magicard disk still uses the \x01*NINTENDO-HVC* disk header, so I do not follow.

If a game happens to have 0x01,0x2A in it that isn't a header, then what? Better to avoid a format that can't handle special cases or need extra heuristics IMO.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 2:03 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
loopy wrote:
*shrug* Inconvenience of multiple files, or inconvenience of another new unsupported (except in your own emulator) format. I prefer the former, personally...
There is nothing inconvenient about the latter --- if you do not support the devices to which these disks are targeted, you need not support the format. One goes with the other.

I can already see that this consultation was a pointless exercise, so whatever.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 2:15 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 388
Location: UT
Welp, you asked for opinions, you got mine. I'm a fan of KISS.
It's your thing, do what you like. As you said, it's for your own emulator and not likely to see adoption anyway so go nuts and make a FDS 2.0.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 6:42 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
No, I was not asking for opinions on whether to have several oversize disk sides in one file, but on how to best include several oversize disk sides in one file. "No answer is also a kind of an answer", so I suppose have received an answer. And I have made quite clear that my preferred solution is not FDS 2.0, but what I described in the initial post, which been successfully tested with almost three thousand FDS side dumps yielding slightly less than 900 sets.

But since it was so wonderful talking to you: a different reason for why separated side dumps are bad that I just remembered is that, at least for Magicard disks, the .B side and following dumps cannot be properly parsed without the information present in the .A side dumps.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 10:51 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
If it requires redefining the existing format in an incompatible way, I would strongly recommend not redefining the existing format.

The specifics of what you create instead don't really matter, but there is a very good reason to not make fragile and backwards-incompatible changes.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 11:05 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
Nothing that I described is backwards-incompatible, though one might have to take the time to ponder "the specifics" that "don't really matter" for a moment to understand why. I am using the same code for all disks, licensed and unlicensed, regular FDS or otherwise. And I need no lecture on the virtues of compatibility.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 11:40 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
To be blunt, you described a messy fragile system, and when Loopy pointed out one of the sharp edges you pooh-poohed his concerns instead.

It seems like you come to this forum to ask for a final approval, and when someone points out a problem, instead of accepting and trying to address that problem you instead get irritated about it. It took you the better part of two days to finally cool down enough to even accept the issue that Rainwarrior identified with the NES2.0 controller field specification.

If you'll accept an arbitrary suggestion, I'd recommend using a novel header that explicitly specifies the padded disk side size. Yes, it is still an FDS disk in an FDS drive going to the FDS RAM adapter, but at the same time it is an overformatted FDS disk and that is what is not compatible with the existing definition.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 11:44 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
lidnariq wrote:
To be blunt, you described a messy fragile system, and when Loopy pointed out one of the sharp edges you pooh-poohed his concerns instead. (...)
To be blunt, you and he have not pointed out any fragility, because the objection was not based on the actual thing that I explained.
lidnariq wrote:
It seems like you come to this forum to ask for a final approval,
No, I come to the forum seeking direct answers to specific questions. I asked a very specific question: "How to represent such a multi-disk set using the headered "fwNES" FDS file format", and got no answer on that question. I received answers on how I should use a different file extension, that I should be using split files, that backwards-compatiblity is really important, and finally, that the data after 65500 bytes might contain 0x01 0x2A, even though my explanation was looking for a much longer string, as shown in the quoted section of that very post. So yeah, thanks for nothing.

I'll take the answers, such as they were, as "It cannot be represented at all, so use a new format", even as the reasons for it may not be convincing, but further discussion of them would be belaboring the point in any case.
lidnariq wrote:
It took you the better part of two days to finally cool down enough to even accept the issue that Rainwarrior identified with the NES2.0 controller field specification.
No, it took me two days to cool down about people coming with (initially poorly-reasoned) change requests shortly after a specification has been implemented who have not said anything in the six months (!) it was laid out for comments, as I have explained to you before. And I still don't think my reaction to that was unjustified, and I have agreed to the post-implementation change only as a matter of compromise, not for having accepted the validity of the objection.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 2:22 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
NewRisingSun wrote:
(initially poorly-reasoned)
No. That is your interpretation of the events to justify your own actions. Rainwarrior's bug report was perfectly clear and perfectly unambiguous. Yes, his initial post was "poorly" reasoned, in the sense that it didn't identify the root source of the problem, but you didn't get defensive until after your mistake was identified.

Quote:
change requests shortly after a specification has been implemented who have not said anything in the six months (!)
You still seem to be operating the impression that everyone else is smarter and more infallible than you before you do something, and that everyone else is stupider and more fallible than you after you do something.

Quote:
I have agreed to the post-implementation change only as a matter of compromise, not for having accepted the validity of the objection.
How kind of you. "You didn't make an argument I want to hear, so to shut you up I'll change it". Obviously upwards compatibility with previous versions of the standard can be wholly disregarded.

Your behavior is not doing yourself nor anyone else any favors.



NewRisingSun wrote:
finally, that the data after 65500 bytes might contain 0x01 0x2A, even though my explanation was looking for a much longer string, as shown in the quoted section of that very post.
You are being petty.
You opened the entire thread only stating the two-byte form, which is the thing Loopy objected to, which I see you have now edited out from the first post to provide no evidence of your misspeaking.

NewRisingSun wrote:
To be blunt, you and he have not pointed out any fragility, because the objection was not based on the actual thing that I explained.
Searching for magic numbers within a file is fragile. Doesn't matter if it's two bytes or many.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 38 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group