nesdev.com

The actual:
main mapper 255(At least the nes is 2.0 )
sub mapper 15 (sub mapper max 15)
4096 is next version.

If the same main MAPPER,but submapper information completely different, nes 2.0 very chicken ribs.

unif After the completion of can reach the PRAM, CRAM (SIZE, SAVE) .
nes 2.0 use ines header,Limited, impossible to 4096 * 15


7 0
---------
SSSS MMMM

S: Submapper number. Mappers not using submappers set this to zero.
M: Bits 11-8 of mapper number.

MMMM 1111 is 4096?
Nes 2.0 is the most chicken ribs, and one of the most chaotic mapper management solution

Please read the NES 2.0 header description carefully before claiming more nonsense. The NES 2.0 header provides twelve bits for the mapper number (byte 6 bits 4-7, byte 7 bits 4-7, and byte 8 bits 0-3), yielding 2^12=4096 mapper numbers, plus an additional four bits (byte 8 bits 4-7) for the submapper number, yielding 2^16=65536 different board types or variants.

I can't say I don't understand Zxbdragon though. But I guess the real chicken ribs here that's too well established to be thrown away is the original iNES format (even Nintendo's official emulators are using it). NES 2.0 is a carefully designed upgrade to the already messy iNES that solves the problems with it while maintaining backwards compatibility.
Sure it's messy but I think the mapper hell for Famicom/NES is the main source for the mess. In later Nintendo systems, cartridge manufacturing was more regulated, and the mask ROMs came with official headers, which is why there's not such a mapper hell for Game Boy or Nintendo 64.


UNIF just has too many problems for it to be useful.

There's a proposal for MAME-like metadata in the wiki to be used in a separate file. I guess that's the way to go if you want that kind of data to go with the ROM.

Is there a ROM file available?

The ROM is hoarded because the cartridge owner requested it. At least it's preserved.

I assume this is some unlicensed game then? Is the owner willing to sell?

I had the same issuse with Moero Pro Yakyuu - this and yours game decodes $6000-$7000 but does not take M2 into account, so it uses caps & diodes to de-glitch. But deglitching will work only if timings are same like on NES. Kazzo probably does not respect them and thats why the register writes are not properly decoded.

He's not willing.

I would say it uses D6-D3

Doesn't correspond to what the game writes, and what the Kazzo dumping script produces. If I understand your PNG file correctly, I basically would need to emulatewhich does not work and cannot possibly be right: during the first game level, the game writes $01 to $FFE1 and $10 to $6000 to select the 8K bank number 1. Your schematic would indicate that the CHR ROM chip U2 takes $8000.3 and $8000.4 as A13 and A14, which would be zero rather than one with this game's write sequence. It cannot be zero since the title screen is already at bank zero ($00 written to both $FFE0 and $6000) and needs a different CHR bank.What's "deglitching"?

One thing that is concerning is that I do only see one latch, not two; with only one latch clock input there can't be two disjoint registers.

To decode the memory region from $6000-$7FFF requires hardware that isn't present — there's only a 74'32, a 74'161, and that KC5373 appears to be a charge pump ( = CIC stunner).

Given the values that are written, the functionality should be Mask: $8000 ; $8000 - [.... PPCC] ; bus conflicts.

But then the CNROM Kazzo script should at least dump the 32K CHR-ROM, which it doesn't. (Although I'm not quite sure I understand the "deglitching" part --- does CNROM need no deglitching and this one does?)

I understand, and yet, there is no physical way on this board for it to have two registers in two separate memory regions.

EVEN IF the two 74-series parts are total lies, are actually random ASICs with surprisingly persuasive incorrect markings, there's not enough pins on them to be able to fulfill your description of what the behavior is.

The electrolytic capacitors (C1, C2, C5) are not there for deglitching. They're part of the CIC stunner.

(Deglitching is removing very brief incorrect digital values)

Looking again the Kazzo CNROM script, I wonder why line 23 doesn't always fail due to bus conflicts, since it just writes to $8000. My Kazzo script for this game writes to FFE0+i, which is what the game actually uses. Maybe that's the true reason why the CNROM script fails with this game, and it's really just $8000-$FFFF ....PPCC? I'm still waiting for krzysiobal for clarification of the D0...D3 instead of D3..D6 bits before I change the wiki article.

Of course, that still leaves open the question why the game writes to $6000 as well. I suppose it could be a kind of compatibility write for a different PCB; no other NTDEC game has those however.

If the ROM is hoarded, and the cartridge is not for sale, and no other copies of this game are known to exist, and no other games using the same mapper are known to exist, then the existence of games using mapper 81 is no more verifiable than someone's research project in his bedroom. So if no ROM dump is available to emulator developers, against what test ROM should emulator developers test their implementations of mapper 81? What am I missing?