mame
mame copied to clipboard
mamedev
msx_dsk.cpp: Attempt to more strongly identify MSX-DOS disk images
This is mainly intended for improving format auto-detection in floptool. Before merging, I'd like to settle doubts regarding whether FIFID_STRUCT is an appropriate response to satisfying the checks performed here (which were tested successfully on many MSX-DOS disk images), or if FIFID_SIGN or FIFID_HINT might be better. (I'm aware that some other formats misuse these.)
Wait a minute... @cuavas just changed the ioprocs API. This will need some updating.
So then what is FIFID_STRUCT appropriate for? I'm pretty sure that formats/acorn_dsk.cpp is misusing it.
Say you have a header with a number of sectors, and you compute the size it should give out and it matches. And the values in the header are acceptable too. That kind of stuff, structural integrity. While signature is more about "expected values are at the correct place in a pure memcmp way".
I believe the current identification rubric's assignment of highest priority to "structural" information contained in parameter blocks may be seriously flawed. One should consider that legacy copier formats assign all disk images the standard maximum size allowed by the given form factor and density, even on systems where many or most disks were actually formatted with fewer tracks. (This might have helped to expose some copy protection schemes that tried to hide extra tracks above the formatted limit given in the parameter block, which the OS might ordinarily respect.) There appears to be a temptation to simply write the comparisons between parameters and geometry as <= rather than == so that underformatted images will pass, but this weakens the integrity of the "structural" test so drastically that auto-identification is almost guaranteed to result in false positives unless other fields are tested more rigorously. It doesn't help when floppy format classes do not perform the parameter checks in the identify routine itself but in helper functions whose result semantics do not admit to any ambiguity in success.
Maybe, but signature is weaker, because any pure sector format can have any crap at the start, including what would be a format signature if you're unlucky.
No, I don't accept that "structural" checks are inherently rigorous as a general principle. The specific problem at hand is opus_ddos_format, which only checks that one or two 16-bit numbers at specific offsets happen to be 0 modulo 18 and gives false positives for lots of MSX disk images. To pick a non-random sample from the msx1_flop list, the false positives include ballblaz, beachead, blinkyss, cf3300, elidon, flightdk, maythfrc, oceano, ohshit, svi738 (738msxdos.dsk only), vozemlyu, vozemlyua, wiredsht and yobai.
That's because opus is not doing what I consider a structural check. Pure sector formats can't have a structural or a signature check in any case. What we could add though is an intermediate level between SIZE and SIGN we could call CONTENT which would indicate that the sector contents make sense for the system. Structural check is more about "am I going to be able to load that file given it's a more elaborate format than a pile of sector data".
What a "structural" check can and can't be was never clearly specified in the source, so it's not surprising that 41cffee11ae8b8aa59c1e8d9e6e29222110353d9 misunderstood the rule. In any case, opus_ddos_format needs to attempt a more thorough check than what it currently does.