iNES Mapper 81

A previously undumped game (Super Gun by NTDEC) uses the following mapper registers: Edit 2: see wiki entry for updated information.
The game's write sequence is as follows:The fact that Kazzo's CNROM script only yields 8K of CHR ROM data confirms that the CHR ROM switch does not respond to $8000-$FFFF bits 0 and 1.

Does this resemble any existing mapper number? All the GNROM-look-a-likes I have seen use 32K PRG banks, not 16 KiB. If not, which new mapper number should I assign?

Edit: PCB images attached; clarified text.

this rom dumped?
It is recommended to use UNIF

Actually, UNIF is deprecated, so its use is not recommended.

I think the unif is right, nes 2.0 is out of date
Actually, Nes 2.0 is very bad, so its use is not recommended. nes 2.0 submapper have 15. 255 * 15 mapper number,is Very don't meet the requirements .

Nes 2.0 does not record the real hardware information, at the same time, this version is a temporary patch version 1.0.

nes 2.0的submapper和PRAM,CRAM size 就是一个冲突。
完善unif才是王道。我更倾向于mame方式管理FC游戏。

Nes 2.0 submapper and PRAM, CRAM the size is a conflict.
Perfect unif is king. I prefer mame manage FC game.


this my dump game:
Unif: revision 8
Unif: board: COOLBOY
Unif: warning, skipping unknown chunk: "WRTR"
Unif: name: 360-in-1(CoolBoy) by www.nesbbs.com
Unif: dumped by: dragon2snow 4325692@qq.com
Unif: dump year: 2016
Unif: dump month: 1
Unif: dump day: 16
Unif: dumper agent: www.nesbbs.com
Unif: PRG-ROM 0 CRC: A095A8D7
Unif: PRG-ROM 0 size: 32768k
Unif: battery present
Unif: mapper controlled mirroring
Board: COOLBOY
Board: 32768k PRG-ROM
Board: 8k W-RAM
Board: 256k V-RAM
Board: MMC rev. B

this unif Record the information, but I think the record is not all .
nes 2.0 Is a no use outdated technology

my dumped new game,According to the number of the PCB, don't have to think what MAPPER number, can be executed directly .

In Chinese "Nes 2.0 is chicken ribs" ,食之无味，弃之可惜。

Having studied all Nestopia mappers that use a 16K PRG ROM switch and having found none that matches the above description, and having neither found a mapper that would be compatible even when taking advantage of the fact that the game writes both PRG and CHR bits to both $6000 and $FFE0, I propose assigning mapper 81 for this board. I prefer not to use a mapper number 256 or higher for a 1992 non-multicart game.

Mapper 81 is unimplemented by FCEUX, Nestopia, Mednafen [1] [2]; it is not listed in the wiki's mapper grid nor in Kevin Horton's mapper grid. The single mention of it I found is in the old fwNES mapper list from 1998, in which it is described as "Tatio C075 [sic]", without listing any game that uses it.

Any objections? If not, then I will create the INES Mapper 081 page on the wiki and post a Nintendulator mapper source file and a Kazzo dumping script. I may also submit the CRC32 info to NesCartDB if I can figure out the submission process.

I went through my code as well and found no mapper that matches this. Afaik, mapper 81 is not used in any emulator.
For what it's worth, the mappers in light gray in this grid are mappers I have been unable to find any information nor valid roms (as of a couple of months ago), so they are probably safe to use.

Only one game of a mapper ?

As promised, wiki mapper description, Nintendulator mapper source and Kazzo dumping script (rename to .ad) attached.

Edit: replaced mapper emulation source code with updated code reflecting how the hardware actually provides said functionality.

That's the number I was using for my next mapper, but emulating it is the least of my concerns, so I guess it doesn't matter much. Not listed in any thing I've posted publicly (at least I don't think so).

Where exactly in NES 2.0 is this conflict?

UNIF has lots of cool metadata like controllers and such, but even that is incomplete and therefore not very useful.
NES 2.0 may be messy because it's designed to be backward compatible with the insufficient iNES format, but it looks to me that it solves the problems that UNIF failed to solve with both licensed and unlicensed games. The authour of UNIF recognized it's drawbacks and even requested it to not be used.

I think UNIF is the chicken ribs here that needs to be thrown away.

nes 2.0 is the chicken ribs here that needs to be thrown away.

Without any motivation to back them up, your words don't hold any water.

Right now it just sounds like you like the MAME-like metadata stuff that UNIF has, disregarding practical use.

On the subject of NES 2.0 vs. UNIF: I'm planning to make a post about assigning NES 2.0 mapper numbers (256+ for non-Chinese/512+ for Chinese) for all those boards that so far are UNIF-only. For that purpose, I will also post a UNIF->NES 2.0 converter.

NES 2.0 has 4095*15 mapper numbers,is Very do meet the requirements.

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?

No one is claiming that this collector's copy is the only one in existence; it's just a rare game, much like all NTDEC original games. I posted the Kazzo dumping script so that some other collector could dump his copy and come forward and publicly release his dump. Having emulator support ready might increase the willingness to do so.

But how can emulator support be ready if it cannot be tested?

I said it at the beginning when noticed your post about registers ($6000) and the fact that this cartridge does not take M2 into account. So I thought of something that:

This cap shorts quick spikes when occur during CPU address setup, so no strobe on register clock is generated.
But this cap is able to short only short spikes, but for NES it will work ecause all address lines (and ROMSEL) changing almost at the same time (with diference of few ns).
Now if u dump using kazzo, there is noticeable delay between address lines change because atmega sets them probably one bit at time (or one word at time), so this cap might be not enough and false strobe will be seen by register. And those caps on this PCB are indeed for CIC purpose.

But later I saw at this PCB in more details and saw only 1 latch so there is no possible of having 2 regs.


Do you see any way how tracks from CART-45, CART-48, CART-48 can go to U1-11 (D0), U1-12 (D1), U1-13 (D2) and simulatenously go to U4-3, U4-4, U4-5, U4-6? Because I DONT unless there is third layer.

But that's impossible, because the game definitely writes $00 at the title screen and $01 at game start to $FFE0/$FFE1, expecting a CHR-ROM switch to occur. It would have to write $00 and then $08 according to your schematic. (And the PRG-ROM content at $FFE0/$FFE1 matches what is written.)

Actually, I don't see how you know for sure that cartridge pins 46-43 must go to U1 and then to U4A, but that pins 49-47 cannot. You've drawn the red lines that way, but I don't see that from the original pictures. If one had another picture with U1 removed, it would clarify further, but I don't think that's something I can ask of the original cartridge owner.
Nintendulator support is ready, since I already have posted a tested source file (and can repost a compiled Mapper DLL file). And if another emulator implements it, I can test it.

You know .... I bet it latches the address bus.

It explains the bizarre topology between CPU D0-D2, PRG D0-D2, and 74'161 D0-D2. And why D3-D7 have their vias where they do. And why the default CNROM dumper script doesn't work.

If it's actually A~[1... .... .... PPCC]... then there are no relevant bus conflicts, either.

Topologically, we know the following:



Draw non-crossing lines connecting all D0s, all D1s, all D2s; and do not have more than four lines visible in the region denoted with that constraint. This cannot be done.

Hm. There is at least one other NTDEC board (Asder 20-in-1) that does in fact latch the address rather than the data bus, so it wouldn't be out of character for them. So it would be actually:This would at least provide working emulation. For the $6000 write one would still need to resort to the "compatibility write for a different PCB" explanation though. Maybe it's used on a 60-pin version of the game.

There's a pirate multicart in FCEUX (mapper 214) that's awfully close, but it banks 16 KiB PRG, doubled up, instead of UNROM-style PRG.

In Nintendulator's style, you should probably use an h_Latch object. In FCEUX, this belongs in addrlatch.cpp.


Register at $6000 could be equally easily excused as "changed in development" or "there to confuse reproduction-makers"

All right, if krzysiobal agrees with the plausibility of the address latch explanation, I'll update the wiki entry accordingly.

Yea brilliant idea, a3-a0 can also be wired in this pcb. THat would also solve the problem why those two ground pads are orphaned - now they're also connected.

D3-D6: A0-D3:

BTW. The marking H/V on this PCB are wrong because this game wires VRAM-A10 to PPU-A11 (or maybe V stands for vertical arrangement, not vertical mirroring?)

Thank-you very much, krzysiobal and lidnariq. I have updated the wiki entry accordingly, and updated my Nintendulator mapper source file as well, using the h_Latch object, as suggested. The Kazzo dumping script needs no modification, as it just straight-up replicates what the game writes, including the spurious $6000 write. If that 60-pin cartridge version I hypothesized about with a data latch at $6000 exists, the dumping script would dump that one as well.

Speaking of dumping scripts: I still don't understand why Kazzo's CNROM script, which just writes to $8000, does not fail due to bus conflicts --- are the Kazzo device's electrical characteristics such that the Kazzo byte always wins over the PRG ROM byte at $8000?

Now, to figure out how to submit to Nescartdb...

Yes, the game is a vertical shooter. I suppose that with no access to official documentation, unlicensed Asian developers just realized that horizontal mirroring is appropriate for "vertical" and the other is suitable for "horizontal" scrolling and so used those words' initials.

So did licensed Asian developers. H and V on Nintendo discrete boards stand for arrangement. I think only RetroUSB and RetroStage boards are marked using the mirroring convention.

Microcontrollers, such as the Atmega used by the Kazzo, often have comparatively ridiculously strong port drivers, capable of sourcing or sinking 10+mA while keeping the voltage on the pin within a volt of the corresponding rail.

In contrast, old NMOS designs (looking at the NMOS 68k datasheet) are often only rated 2 mA sinking and 400µA sourcing. The Kazzo assumes it can just completely overpower the ROMs on the cart, and it's almost always right.

It'd still be ideal if the dumper script took steps to prevent bus conflicts.

Cut wires connecting microcontroller in kazzo to CPU data bus and put 200R serial resistors. Now ROM will always win bus conflict.

My guess would be that the $6000 writes are used for the unreleased Caltron 9 in 1 multi which does include this game and has a 1992 copyright on the menu screen. It was maybe done at the same time?

It was on sale a few months ago for a whopping 5 or 6k USD, BIN listing was put down because it wasn't available anymore. Here's the only PCB photo shown by the seller:

Exposed EPROMS? )))

NintendoAge people

Oh, so that's why it's not dumped.

When you resell pirated works, don't act like they're your IP.