Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in General Emulation.
Acmlm's Board - I2 Archive - General Emulation - Help with Nester | |
Pages: 1 2Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
Dane
Newcomer
Level: 2

Posts: 2/2
EXP: 39
For next: 7

Since: 04-26-05

Since last post: 189 days
Last activity: 189 days
Posted on 04-27-05 02:41 AM Link | Quote
When I try to open a ROM, I get the following message:

Invalid NES Header (8$-F$)

Please help.
dan

Snap Dragon
Level: 43

Posts: 549/782
EXP: 534516
For next: 30530

Since: 03-15-04

Since last post: 20 hours
Last activity: 14 hours
Posted on 04-27-05 02:57 AM Link | Quote
I'll take a stab in the dark, maybe it has the text DISKDUDE! (or whatever it is) in its iNES header, and the emulator really doesn't like that. You could fix it using a hex editor, or try a different emulator (FCEU checks for the DISKDUDE text, and ignores it).
Dish

Spiny
Level: 38

Posts: 365/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-27-05 04:36 AM Link | Quote
yes, use a hex editor and zero out bytes $00008-$0000F

Emulators shouldn't have to autocorrect bad headers
Kitten Yiffer

Purple wand
Furry moderator
Vivent l'exp����¯�¿�½������©rience de signalisation d'amusement, ou bien !
Level: 135

Posts: 9460/11162
EXP: 28824106
For next: 510899

Since: 03-15-04
From: Sweden

Since last post: 3 hours
Last activity: 4 min.
Posted on 04-27-05 04:41 AM Link | Quote
What the heck is Diskdude thought? A person? A tool? One of my NES rom's which I got back in 1998 had that text. A google search tells me nothing?
Colleen
Administrator
Level: 136

Posts: 8063/11302
EXP: 29369328
For next: 727587

Since: 03-15-04
From: LaSalle, Quebec, Canada

Since last post: 3 hours
Last activity: 1 hour
Posted on 04-27-05 06:27 AM Link | Quote
Kitten Yiffer: I don't think you searched very hard.
dan

Snap Dragon
Level: 43

Posts: 550/782
EXP: 534516
For next: 30530

Since: 03-15-04

Since last post: 20 hours
Last activity: 14 hours
Posted on 04-27-05 02:43 PM Link | Quote
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.
Kitten Yiffer

Purple wand
Furry moderator
Vivent l'exp����¯�¿�½������©rience de signalisation d'amusement, ou bien !
Level: 135

Posts: 9462/11162
EXP: 28824106
For next: 510899

Since: 03-15-04
From: Sweden

Since last post: 3 hours
Last activity: 4 min.
Posted on 04-27-05 06:30 PM Link | Quote
Originally posted by Colleen
Kitten Yiffer: 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.
Dish

Spiny
Level: 38

Posts: 366/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-27-05 11:45 PM Link | Quote
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.


(edited by Disch on 04-27-05 06:48 AM)
Kyoufu Kawa
I'm not bad. I'm just drawn that way.
Level: 70

Posts: 1489/2481
EXP: 3008456
For next: 7355

Since: 03-19-04
From: Catgirl Central

Since last post: 14 hours
Last activity: 13 hours
Posted on 04-28-05 12:39 AM Link | Quote
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

Spiny
Level: 38

Posts: 367/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-28-05 01:00 AM Link | Quote
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.


(edited by Disch on 04-27-05 08:13 AM)
Kitten Yiffer

Purple wand
Furry moderator
Vivent l'exp����¯�¿�½������©rience de signalisation d'amusement, ou bien !
Level: 135

Posts: 9468/11162
EXP: 28824106
For next: 510899

Since: 03-15-04
From: Sweden

Since last post: 3 hours
Last activity: 4 min.
Posted on 04-28-05 04:53 AM Link | Quote
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.)


(edited by Kitty Jedi on 04-27-05 11:55 AM)
Colleen
Administrator
Level: 136

Posts: 8090/11302
EXP: 29369328
For next: 727587

Since: 03-15-04
From: LaSalle, Quebec, Canada

Since last post: 3 hours
Last activity: 1 hour
Posted on 04-28-05 08:42 AM Link | Quote
...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. )
dan

Snap Dragon
Level: 43

Posts: 553/782
EXP: 534516
For next: 30530

Since: 03-15-04

Since last post: 20 hours
Last activity: 14 hours
Posted on 04-28-05 03:49 PM Link | Quote
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.
Dish

Spiny
Level: 38

Posts: 370/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-28-05 10:18 PM Link | Quote
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.
Kyoufu Kawa
I'm not bad. I'm just drawn that way.
Level: 70

Posts: 1493/2481
EXP: 3008456
For next: 7355

Since: 03-19-04
From: Catgirl Central

Since last post: 14 hours
Last activity: 13 hours
Posted on 04-28-05 10:30 PM Link | Quote
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

Spiny
Level: 38

Posts: 371/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-28-05 10:38 PM Link | Quote
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.


(edited by Disch on 04-28-05 05:38 AM)
(edited by Disch on 04-28-05 05:41 AM)
(edited by Disch on 04-28-05 05:51 AM)
(edited by Disch on 04-28-05 05:58 AM)
dan

Snap Dragon
Level: 43

Posts: 556/782
EXP: 534516
For next: 30530

Since: 03-15-04

Since last post: 20 hours
Last activity: 14 hours
Posted on 04-29-05 05:46 PM Link | Quote
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

Spiny
Level: 38

Posts: 373/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-29-05 10:45 PM Link | Quote
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

Snap Dragon
Level: 43

Posts: 557/782
EXP: 534516
For next: 30530

Since: 03-15-04

Since last post: 20 hours
Last activity: 14 hours
Posted on 04-30-05 02:59 PM Link | Quote
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

Spiny
Level: 38

Posts: 377/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-30-05 09:40 PM Link | Quote
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?


(edited by Disch on 04-30-05 05:04 AM)
Pages: 1 2Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - General Emulation - Help with Nester | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.029 seconds.