To avoid getting into meta-argument about what you can prove...hex_usr wrote:Absence of evidence is not evidence of absence.loopy wrote:Show me one game that does this.
Loopy's point is there's no demonstrated utility in including the CRC.
If you want, you could make a working disk image to prove that you could make something that relies on a bad CRC. Such an example doesn't demonstrate utility though, just that it could be done. It's obvious that it could be done, nobody here is doubting that.
I don't think there's a harm in trying to emulate/record the CRCs in some way, but arguing that it's theoretically possible isn't a very convincing way to make anyone interested in it. If you could actually discover a cool new game that it was meaningfully relevant to, maybe people would care, but otherwise it's an extremely academic desire.
...and I still think trying to do it with heuristics on the disk image is underperforming for this academic goal. There's not much point in adding only a CRC, add the whole enchilada and be done with it! If you're trying to cram it into the .FDS format instead of a new format, do something that doesn't affect the integrity of the disk image you're trying to test! That's why I suggested using the header and changing the FOURCC.
Though, actually I think Loopy's suggestion to just use a new file extension is a much better idea than reusing .FDS and changing the header. Simply changing the extension to, say ".FDC" would solve the whole issue with no effort, and no "heuristic" workarounds.
...or if you just want CRCs use the .QD format since it already has them?