Emulator Coder, Site Developer, Site Owner, Expert player
(3601)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
What game are you trying to load?
If it is a homebrew, there is a homebrew db file, you can simply add an entry to it. (IF you get that working, please share so it can be in our official copy).
But it maybe that you are using a game that does not have that mapper implemented yet? I will provide a mapper compatibility list soon. And I will prioritize implementing mappers that have been requested.
I'm testing development builds of NES Chu Chu Rocket on it.
adelikat wrote:
If it is a homebrew, there is a homebrew db file, you can simply add an entry to it. (IF you get that working, please share so it can be in our official copy).
C'mon, that's not very user friendly, just make it use the iNES header for unrecognized roms, even if you need to put up a warning message indicating that it is playing an unknown rom. I know that iNES headers suck, since they can't easily specify how much WRAM is in the cartridge, but they're better than exceptions and refusing to run the game.
Edit: especially unfriendly to need to get the SHA1 sum excluding the header.
Edit again: I like to use NES Chu Chu Rocket because it's so hard to emulate correctly. It makes a very good emulation accuracy test rom.
Here's a bug: (probably in MMC3 emulation)
When the text window is up, the interrupts are one scanline off.
Also, 256x223 resolution!?
This emulator uses a policy which I expect to be controversial.
Games are emulated strictly using boards. We have a table that relates iNES header parameters (including mapper number) to a board name. This table is pretty incomplete. At some point I got started adding a convention of board types like "NROM-HOMEBREW" which are more lenient in their validation. These can be added to the table as a catch-all. But unless it's added to the table, there is no possible way to load a ROM. I will be glad to do this when supplied details about what needs doing.
There is one other possible way to load the rom, which you seem to have found. The gamedb.txt #includes gamedb_user.txt ; you can supply this file with records from your personal build process to make sure it gets processed correctly by the rom loader.
Here's the problem. Different people have different opinions on what it means to have hacky HOMEBREW variants of mappers. Different conflicting opinions. Our policy is devised so that we have an explicit record of whose opinion we are accepting (the iNES header -> board type table) along with reasonably cleanly encoded rules in the board type validation. Incompatible opinions have a way to express themselves, via the gamedb system.
Yes, you may call this user unfriendly. But continuing the traditional clusterfuck of hacks and madness is user unfriendly, too. I thought we'd try something different here. Can you play along until we discover whether I was right or wrong?
Regarding the accuracy of bizhawk's nes core:
It is, at present, not the most accurate emulator. It is roughly on par with FCEUX, as per the original scope. More accurate in some ways, less than some others. So, bugs are expected.
The organizational business of the mappers and basic compatibility will be supported at maximum level.
Core timing precisions can't be supported very well without the assistance of someone willing to adopt the core as a primary programmer. But feel free to post the bugs for such a time.
It will support nonexistent boards by defining them in a structured way. This one probably through a newly defined CNROM-HOMEBREW board type which I will define and bind to iNES headers specifying mapper 3 which don't bind to anything else first.
You can't expect a new emulator to support every hacked up bogus 'mapper' ever conceived, unless it does so by having virtually no validation on anything, which guarantees bugs later.
i found a bug related to ppu bus address strobing which made was breaking your game in bizhawk and fixed it in r1773; also i added a catch-all for mapper 4 so that it can boot without a hash
It will support nonexistent boards by defining them in a structured way. This one probably through a newly defined CNROM-HOMEBREW board type which I will define and bind to iNES headers specifying mapper 3 which don't bind to anything else first.
You can't expect a new emulator to support every hacked up bogus 'mapper' ever conceived, unless it does so by having virtually no validation on anything, which guarantees bugs later.
Yes, you can. All you have to do is to put up a message saying that the mapper cannot be validated, and ask the user if they want to go ahead anyway. If they do, you temporarily pretend it's been validated (for the rest of the session). If bugs pop up after the user has chosen to skip validation, that's not your problem.
It will support nonexistent boards by defining them in a structured way. This one probably through a newly defined CNROM-HOMEBREW board type which I will define and bind to iNES headers specifying mapper 3 which don't bind to anything else first.
You can't expect a new emulator to support every hacked up bogus 'mapper' ever conceived, unless it does so by having virtually no validation on anything, which guarantees bugs later.
Yes, you can. All you have to do is to put up a message saying that the mapper cannot be validated, and ask the user if they want to go ahead anyway. If they do, you temporarily pretend it's been validated (for the rest of the session). If bugs pop up after the user has chosen to skip validation, that's not your problem.
Emulator Coder, Site Developer, Site Owner, Expert player
(3601)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
This is an outdated topic (like many that someone has posted in today), rom heuristics have been in place for about 6 months now. Almost any ROM out there will load now, warn if it is making a guess at the mapper, and displays an error if the mapper has not been implemented. This situation has been fixed.
When the text window is up, the interrupts are one scanline off.
Also, 256x223 resolution!?
