Acmlm's Board - I2 Archive - General Emulation - Help with Nester
| User | Post |
HyperLamer
Posts: 4364/8210 |
Well I do agree that there wouldn't be a problem if the emulators had proper support for these standards. Thing is, back when this was done, they didn't. I really doubt any new ROMs are being released with this problem, so there isn't really anything wrong with fixing the ones that were. And now that more emulators do support them properly, such things may not happen so often in the future.
Personally I think it'd be great if the emulator just fixed it silently on disk. That way anyone who uses a corrupt ROM ends up with a non-corrupt ROM, even if they have no idea what that means, and poof, the problem basically disappears. |
Dish
Posts: 384/596 |
Originally posted by R2H2
Disch, I always thought you were pretty bright, but you're hardly coming off that way here.
I guess I'm just arguing the principle. Most people (dan, and you apparently) seem to be saying "hey, just do whatever to make it work and to hell with the standards." -- I'm saying "The standards should mean something, and you shouldn't make exceptions for boneheads who don't want to follow them".
Diskdude was a moron for using those reserved bytes and thus breaking the ROM, yes, but fixing it isn't going to cause more problems.
That's the thing -- this ISN'T fixing it. This is just feeding it. If these ROMs didn't play in emulators, the problem wouldn't even exist because people wouldn't be spreading around busted ROMs. Like i said before -- if emus were more strict about this kind of thing we wouldn't even be debating this -- since the problem wouldn't exist. So lax header checks are part of the problem.
I can't believe it's gotten to the point where an emulator is frowned upon by actually interpretting the file format PROPERLY. I mean seriously -- stand back and look at what you're actually saying, you guys. It's madness. You're saying an emulator should intentionally do things WRONG in order to get a handful of BROKEN games playable. Dress it up with your rationalizations and stats all you like --- but that's what you're saying. I, for one, think that's not only awful, but one of the worst things an emu could do. And no emu should do that. EVER.
If the emulator can detect that the game is broken, and knows exactly what needs to be done to fix it, then by all means fix it.
Fix it, fine. As long as it prompts me before writing over any of my ROMs. Ignores it, NO. Never. No how. That's absolutly bad. That just feeds the problem.
As for making the user find and run obscure programs to fix the problem -- maybe that is a little off the top. I really REALLY wish GoodNES and all the other auditing tools would actually address this problem rather than just completely ignoring it. I mean a simple "[bad header]" in the GoodNES name would work WONDERS towards reducing the number of dumb DiskDude roms around. |
HyperLamer
Posts: 4340/8210 |
Disch, I always thought you were pretty bright, but you're hardly coming off that way here. Diskdude was a moron for using those reserved bytes and thus breaking the ROM, yes, but fixing it isn't going to cause more problems. When he did this, those bytes were all unused - or reserved as you call them as if it meant something different - meaning they could not have been anything but 00. Thus it's perfectly safe to assume that if bytes 8-F are THAT SPECIFIC PATTERN, that they're supposed to all be 00. No ROM is ever going to have that pattern in its header legitimately - the chances are 1 in 18,446,744,073,709,551,616! (That's one in eighteen quintillion four hundred forty-six quadrillon seven hundred forty-four trillion seventy-three billion seven hundred nine million five hundred fifty one thousand six hundred sixteen. You couldn't begin to comprehend how big that number is.)
For that matter, why complicate the issue by having one program fix the games and the other play them? If the emulator can detect that the game is broken, and knows exactly what needs to be done to fix it, then by all means fix it. It's somewhat annoying to have a "do you want to fix this" prompt for every bad ROM you load (not that a prompt is even needed - make the file read-only if it's absolutely necessary to keep it), but it's much more annoying for it to close with a "This ROM is corrupt, do this and this and that and try again" message, forcing you to find and download some obscure program and figure out how to work it. Not to mention, what happens when you download a new ROM and it's corrupt? Now you have to run the program and re-scan every single ROM again! |
Kefka
Posts: 2978/3392 |
Am I the only one who thinks it's folly not to use FCEUXD over Nester? I mean, Nester was ok, but FCEUD and FCEUXD are just WAY better. Granted, it may be that the emulator used has nothing to do with this, but I still just found this kind of... well, I saw it and couldn't help but think what I said. |
Dish
Posts: 377/596 |
No, see. Those bytes were never unused.
"Reserved for future use, must be 0" was there for those bytes prior to the iNES update for this exact reason. 'Reserved' does not mean "put whatever you want here". It means "Reserved, MUST BE 0". DiskDude didn't put 0 there, because of that it ignored the file specs -- because of that the ROMs broke when the format updated. ROMs that actually followed the specs didn't break and still work to this day -- even with the most recent iNES specs.
Current day -- DiskDude ROMs are broken. I don't know how you can debate this -- I mean they say to use mapper 65 when it's really mapper 1. That's about as broken as a header can get.
So your comparison is flawed -- it's not providing backwards compatibility (iNES already is fully backwards compatible with previous versions/revisions) -- it's providing 'compatibility' (though I hate using that word in this context) for files which disregarded the format specs and made their own rules causing them to require special treatment. I'm saying you shouldn't provide special treatment to goons which want to break the format. The file format is there for a reason -- the rules it has are there because they're how the file works. If some goon is going to piss on the format and advertise his name in the header, breaking his ROMs in the process -- then no... emus shouldn't go out of their way to support him.
I really want to point you back to my IE example -- because I know that's something you'll be able to relate it with, and it really sums up my argument quite well. DiskDude ROMs are like broken webpages -- they don't follow any standard, and an emu doing things in accordance with the standard will not run them properly. In order for emus to run them -- they have to break the standard (potentially breaking ligit ROMs in the process -- and yes, while unlikely this is a possibility. Escpecially so as iNES updates and uses more of the expansion bytes). Without the standards why bother having a format at all? I mean really, if every ROM is just going to use the bytes differently -- what's the point? |
dan
Posts: 557/782 |
Originally posted by Disch
Originally posted by dan
However, I think it would safe to assume that the parts of the header taken up by the diskdude text are all zeroed out.
Most of the time you're right. However it is possible for a proper ROM to have some of those bytes having a nonzero value. If you apply the DiskDude "correction" to that ROM, you're breaking that ROM in order to fix the broken ROMs.
Auto-correction in this manner is not the solution. It's not even a solution -- it's just a way of weaseling around the problem to make the problem work.
I think you misunderstand when I say to check for the Diskdude text. The check would check all the bytes that are normally taken upby the Diskdude text. No other ROMs would be affected.
The Diskdude ROMs aren't broken. Typically, they are ROMs, which don't use the higher bytes (7-0F) of the iNES header. Apart from the higher mapper bit, not many ROMs do. I think what probably happened was that the Diskdude ROMs were dumped before the high mapper bits were even decided upon (it quite literally makes no sense to use nibbles from two different bytes to get a number, unless of course it was tacked on when the need arose). If that is the case (which seems a reasonable enough hypothesis), it's similar to providing compatibility for old file formats in programs. Except for the fact that the file format is virtually identical, with a potential difference in 8 bytes. |
Dish
Posts: 373/596 |
Originally posted by dan
However, I think it would safe to assume that the parts of the header taken up by the diskdude text are all zeroed out.
Most of the time you're right. However it is possible for a proper ROM to have some of those bytes having a nonzero value. If you apply the DiskDude "correction" to that ROM, you're breaking that ROM in order to fix the broken ROMs.
Auto-correction in this manner is not the solution. It's not even a solution -- it's just a way of weaseling around the problem to make the problem work.
I don't think the solution of fixing your ROMs before using them in an emulator is a good solution.
It's the only solution. The ROMs are broken -- they need to be fixed.
Lots of people don't have knowledge of headers or the inner-workings of NES ROMs, so if a ROM doesn't load in a certain emulator because it doesn't have any kind of checking for Diskdude ROMs, they assume that the emulator is faulty and try another.
That describes the problem we're debating quite well. That's exactly why these headers need to be fixed. Emulators treating the header properly don't run these games and because of that people think it's a problem with the emulator... which it's not.
Compare this to the whole IE thing. If you make a page that will only load in IE due to its faulty rendering methods -- and someone tries to load the page in Firefox or Opera and it doesn't show up right -- they might think it's a problem with the browser -- but it's not. It's a problem with the page. And in fact -- some more educated users embrace that Firefox and Opera play closer to the standards than IE does.
This is exactly the same as the diskdude situation. The iNES format specs are layed out clear as day -- DiskDude ignores them. It breaks the rules. Because of that... THE ROMs DON'T WORK. They're broken. A less educated user might think that an emu not running these ROMs has a problem -- but that's not the case. As with the IE example... it's the ROM/page which has the problem -- not the emu/browser. A more educated/advanced user would appreciate the strict header check.
And just like the browser situation -- the solution is not to ignore the standards and make up your own rules to make the bad ROMs work. When you start doing this you're working towards making the IE of emus -- focusing more on getting the games running rather than running them right. NESticle is the perfect example of this kind of emu -- it doesn't follow strict specs -- rather it relies on many, many hacks to get games up and running -- rather than emulating properly. And because of that, NESticle is a piece of shit.
Especially, if the ROM is a GoodNES verified good dump (GoodNES ignores headers,
This is exactly why I dislike GoodNES. "Verified Good Dumps" have bad headers and don't run properly/at all. Rad Racer 2 comes to mind -- which isn't plagued by DiskDude, but still has an otherwise broken header (wrong mirroring mode set) -- only way to 'auto-correct' it is to CRC check. If GoodNES actually looked for and flags bad headers like it should, these problems would be a lot less common.
which is quite sensible, as there are the same version of ROMs floating around, but with slightly different headers)
It's not sensible at all. It's problematic. For any given ROM... there can only be only ONE mapper number. only ONE prg size. only ONE chr size. only ONE sram state. And provided the mirroring is hardwired... only ONE mirroring mode. There can only be ONE correct header. Dumps floating around with "slightly different headers" have bad headers. There's only 1 correct one. There's only one that will work properly.
I believe that providing compatibility for these ROMs is the emulator's responsibility.
That's the thing... It's not compatibility. The ROMs are broken! They have incorrect mapper numbers! They're BUSTED! Emus should not disregard file format specs in order to get BROKEN games running. I'm tempted to point you back to my IE examplE. |
dan
Posts: 556/782 |
Or, the emulator could just fix the header if it contains the diskdude text, in memory and not save it to the file. I do agree with the whole ROM auditing/emulator hybrid being cumbersome. However, I think it would safe to assume that the parts of the header taken up by the diskdude text are all zeroed out.
I don't think the solution of fixing your ROMs before using them in an emulator is a good solution. Lots of people don't have knowledge of headers or the inner-workings of NES ROMs, so if a ROM doesn't load in a certain emulator because it doesn't have any kind of checking for Diskdude ROMs, they assume that the emulator is faulty and try another. Or post on a messageboard. Especially, if the ROM is a GoodNES verified good dump (GoodNES ignores headers, which is quite sensible, as there are the same version of ROMs floating around, but with slightly different headers)
I believe that providing compatibility for these ROMs is the emulator's responsibility. |
Dish
Posts: 371/596 |
The thing is, when 99.9% of the people click the "Do not show this warning again" box, that becomes completely worthless. Or it auto-fixes every file it loads (which might not actually be broken).
My position seems to have become clouded. So let me clarify my standing on these points.
1) DiskDude headers are bad. They should not exist. Every ROM which has one should be fixed.
2) Emulators should not go out of their way to support bad files -- whether the header is bad due to DiskDude, or someone just setting the header wrong -- the emu should not have to correct it. If the emu can't use the header as-is, the whole point of having a header at all is lost.
3) The problems listed in #2, which I said emus should not do, are the perfect job for an auditing tool -- since that's kind of what auditing tools are for (well that and renaming files).
4) A hybrid emu/auditing tool would be cumbersome and/or intrusive. As I'm sure most everyone would agree -- having an emu change files without prompting you is bad. Likewise being prompted every time you load a file is also bad.
5) The clear, simple, straightforward, make-everyone-happy solution to this problem is to run an auditing tool once to correct all your bad headers, and have an emu run normally. This solves the problems listed in #2, while avoiding the problems associated with #4, and keeps an emu doing the work of an emu -- and nothing more.
6) To further address #1 -- problems should be solved -- not "worked around". Weaseling around these problems so that bad ROMs will run just furthers the problems and opens the door to allow more problems in. Format specs exist for a reason. Diskdude broke/ignored these specs -- and because of that several ROMs are broken. Instead of emus conjuring ways to support broken ROMs, people should just fix their ROMs. |
Kyoufu Kawa
Posts: 1493/2481 |
Originally posted by Disch
Building the auditing tool into the emu is one idea (correcting and saving the ROM when its loaded in the emu) -- but personally I'd be pissed if an emu started changing my files around when it loaded them -- since that's not what it's supposed to do.
This image is screwed in the header. It has the infamous Diskdude text in it. Fix it and continue anyway? Fixing would permanently alter the image (in a good way).
[X] Do not show this warning again.
[Yes] [No] |
Dish
Posts: 370/596 |
Originally posted by dan
So, I still see no reason why emulators don't have a Diskdude check and corrector. It's really not that difficult to do.
It's not about it being difficult, it's about it being counter-productive. Emus bending over backwards to support improperly headered files is not a good thing -- they shouldn't do it... it's not their job. The header works for the emu, not the other way around.
Now an auditing tool -- yes, a DiskDude check and removal would be great -- and in fact would be a GREAT value in solving this problem. However emus doing it doesn't solve a thing, and just perpetuates it.
Building the auditing tool into the emu is one idea (correcting and saving the ROM when its loaded in the emu) -- but personally I'd be pissed if an emu started changing my files around when it loaded them -- since that's not what it's supposed to do. |
dan
Posts: 553/782 |
A CRC check isn't needed to correct ROMs with Diskdude in the header. All that is needed is to check whether the text exists or not, and zero it out if it does. The games that usually have the diskdude text in the header are mostly older games that don't have mapper numbers higher than 16, so the rest of the header isn't needed. There's probably meant to be stuff after that, but there's so many different versions of the iNES header specification floating about, it's impossible to tell. And different emulators don't support everything.
So, I still see no reason why emulators don't have a Diskdude check and corrector. It's really not that difficult to do.
I don't think GoodNES will make much difference though, it seems to ignore the header completely. |
Colin
Posts: 8090/11302 |
...And this is why people should be using roms that are named correctly (like through the GoodNES system) instead of downloading anything that has a .nes extension and thinking it's the rom. 
Of course, people who know squat about emulation don't know that some games have different revisions, bad dumps, overdumps, hacks, etc.
(I remember when Dragon Warrior 4 was first dumped and it was a whole MEG in size. Everyone was going crazy (since back then a MEG was still a lot) and then a year or so later someone finally figures out it was overdumped and should be 512kb instead. ) |
Ailure
Posts: 9468/11162 |
Originally posted by Kawahless the Forgettable
This image is screwed in the header. It has the infamous Diskdude text in it. Ignore it and continue anyway?
[X] Do not show this warning again.
[Yes] [No]
I would love seeing IE to do that as soon there is a page with incorrect HTML. (as with the case of incorrect headers, incorrect HTML pages can be partly blamed on IE's way of handling them) Then people would check the "Do not show this warning again". Dosen't really work...
Althought out of my ROM collection, there is only one ROM with an incorrect header. And that's Snake rattle n roll (which have Diskdude! in the header, I know since I saw that while hacking the game. I never cared much about it, until a certain other emulator complained about the header.) |
Dish
Posts: 367/596 |
It's not a simple matter of ignoring bytes. The 'DiskDude' text occupies space used legitimately by other ROMs, like the high bits of the mapper number for example -- and more recently (but far less common) NTSC/PAL bit and CHR-RAM size.
Besides -- emus correcting this perpetuates the problem. If you build hacks into the emu to play bad dumps/bad headered ROMs -- it makes bad dumping practices acceptable, which just leads to further problems, as was my point in the previous post. If emus never let DiskDude get away with this bullshit, we wouldn't be having this debate. Hence lax emu behaviour is partially responsible for the problem.
"Reserved - Must be 00" does not mean "Unused - put whatever you want here". It means must be 00. |
Kyoufu Kawa
Posts: 1489/2481 |
This image is screwed in the header. It has the infamous Diskdude text in it. Ignore it and continue anyway?
[X] Do not show this warning again.
[Yes] [No] |
Dish
Posts: 366/596 |
Originally posted by dan
I don't see any reason for an emulator not to, quite frankly.
That's not their job. The whole point for headers is to supply that info -- that's what the header is for. If emus have to CRC check everything anyway, what's the point of having headers at all? I mean if their info can't be relied on or even used, they're completely worthless.
Emus that are lax in this area just encourage further bad headers from being spread. After all, people will think that if the game runs fine through hacks, why bother to correct the problem? Personally I feel that attitude is completely shitty. When there's a problem, the emulator should treat it as though there's a problem. It's the emulator's job to play the game as the system would -- if you wire the wrong mirroring mode or put the wrong MMC on a cart and pop it in the NES -- it won't play. So why should an emu be expected to play it?
But yeah -- emulators letting ROMs get away with having bad headers is bad news. I mean if the first Diskdude ROM was actually treated properly, we wouldn't have this problem at all, because the person adding DiskDude to the headers would realize "hey, this doesn't work". Instead the emus looked the other way and now a good 20% of the dumps out there have bad headers as a direct result.
So I stand by my statement. It's not the emu's job to look for bad headers. And in fact, I'd say it's the emus duty to be as strict as possible when it comes to such things. I mean it's not like the real system lets you get away with that crap. |
Ailure
Posts: 9462/11162 |
Originally posted by Colin
Ailure: I don't think you searched very hard.
...oi, I blame on the fact that I partly was lazy when searching and very tired.
Seems like Diskdude is some person who made dumping equipment.  He seems also to have a website, or at least used to. All links are either dead or down. |
dan
Posts: 550/782 |
Originally posted by Disch
Emulators shouldn't have to autocorrect bad headers
Yeah, they shouldn't have to, but it would be definitely preferable (at least in the case of the diskdude text). I don't see any reason for an emulator not to, quite frankly. |
Colin
Posts: 8063/11302 |
Ailure: I don't think you searched very hard. |
| This is a long thread. Click here to view it. |
|
