Game number 14 on the Asder 20-in-1 multicart is "Benico", a game that has not been discovered so far in single-cartridge form. While gameplay is emulated fine, during the self-running demo, the game performs a number of writes in the $F000-$F0FF range that throw most emulators off, causing graphical corruption. I can mask them off by excluding the F000-F07E area from the bankswitching emulation code without problems, but I'm wondering: what is the game doing there that it's not doing during actual gameplay?
I would not necessarily assume that the game works correctly on the original multicart hardware...
The mapper hardware (since this isn't documented on the wiki) seems to be:
A~[1PPP PMCC Sp.. .CCC]
P - PRG A18,17,16,15
C - CHR A17,16,15,14,13
M - 1:VRAM A10 = PPU A11 ; 0:=A10
S - 1:PRG A14=p ; 0:=CPU A14
In fact, given this description, I don't see a way that that could work correctly on the original multicart.
If that description is correct, that is. I don't know that it is based from actual hardware analysis, as opposed to just figuring out how to make emulation of the ROM image work.
The only YouTube video of the original hardware that I could find unfortunately does not show the game's attract mode.
I still cannot make any sense of what the game is trying to accomplish with those writes.
More or less the only possibilities are:
* Some bits are required to be 1 or 0 for a write to succeed
* Some bits, after having been written to with a 1 or 0, disallow any further writes to all or part of the register
But, seriously, don't overestimate the amount of testing that went into any pirate multicart.
It's not a pirate multicart, but a multicart by the original makers of the games. (That NTDEC/Asder pirated other companies' games on other occasions does not make this one a pirate multicart.)
I'm really not certain what you think your point is.
A company that released pirate multicarts releases a multicart of in-house games. Do you think this somehow magically means their testing will have improved?
Yes, in fact I would think that.
But that was not my original question. My original question was that regardless of whether that individual game works correctly on the multicart hardware or not, the programmers of that individual game intended those F000-F0FF writes made during attract mode to do something, and I cannot figure out what that would be, and that someone might have an idea of what that could be.
The routine that writes to $F000,Y reads from a pointer that usually points to somewhere in $E000. The value that is written is the simulated joypad input during attract mode.
I strongly suspect that the way attract mode was created was they put the game on a RAM cart, and wrote the sequence of button inputs into $F000,Y. For final manufacture, these 128 byte sequences were then moved to other locations in ROM, and the code that read from the controllers was replaced with a playback loop reading from the pointer instead. Since the original game was released as NROM, there was no need to remove the side-effect-less writes to the PRG ROM addresses.
Thank-you, that makes sense. Together with
krzysiobal's confirmation that the graphic errors occur on real hardware as well, we now know that the previous description of the mapper hardware does not need to be amended.