Mapper 255

The 115-in-1 cart requires Mapper 255, but there is no wiki for this mapper yet. Nestopia supports it. Does anyone have any info on this mapper?

Nothing better than the source there.
Note that FCEUX's source says "Mapper255_Init}, // No good dumps for this mapper" so I'd be skeptical about putting much effort into implementing it.

Hope you don't mind a necro bump.
I bought a Honey Bee adapter a while ago because I'd heard good things, but that's another story.
The Honey Bee came with a 110 in 1 famicom cart, which until recently was one of only two carts of mine I hadn't dumped yet.
I finally got around to dumping it.
It runs fine in Nestopia.
The PRG CRC-32 is 0x8763c67e and the CHR CRC-32 is 0x122d2157 (although sometimes it read a few bytes differently, might have a failing trace somewhere).

I included my notes on using it with the connection testing results. I can't guarantee it's complete, but I think it's at least close. Lots of traces are behind chips. If it's not clear, I guess I could type it up a little more formally, if anyone cares.
I suspect the writes to 0x5FF0/1/2/3 are used when the unpopulated chip is in place (not in my copy), as the data being written is the same (but in a different form) as the data being written in the 0x8xxx range from analyzing with a debugger.

Kazzo dumping script:

But wait, didn't CaH4e3 dump this cart in late 2011?

If this refers to the dump with overall CRC32 of 0x93DA1E37, then it appears one of the PRG lines was accidently held low. i.e. PRG data at 0xXXX4XXXX=0xXXX0XXXX. If running in Nestopia, Flipull-the first game, for example, is scrambled because it's using the wrong PRG (duplicate copy of Elevator Action?) with the right CHR. Roughly half of the games will be incorrect because of this. This would explain why it's marked as a bad dump in FCEUX.

The first post was asking for more info, and I thought I'd just share what I found while dumping it in case anyone else wanted to dump theirs.
In case the notes/code in Nestopia aren't clear (Nestopia matches my findings):
Writes to 0x8000-0xFFFF do the following:
The 16 bit address is used. The data is ignored.
CHR is set in a complete block indexed by (Address & 0x3F | Address >> 8 & 0x40)
PRG can be a mirrored 0x4000 block, or a complete 0x8000. I skipped the complex processing when dumping and just did 0x8000 at a time.
H/V is set by (Address & 0x2000)

Writes in the 0x5FFX occur, but they don't do anything. I believe they would if the chip that isn't populated on my board was present.

Here's some quick copy and pasting in FCEUX that looks like it works (EDIT - Whoops. Messed up H/V. Fixed now):

It seems weird to me that they used a PAL where just a 74'153 could have done.

The unpopulated space matches the pinout of a 74'670 (a 16-bit RAM). After all the mappers that have been reported to have one, it's neat to find evidence of that not being a shared hallucination.

Oh, that's why the PAL. To decode the region for the 74'670. If the game expects it at $5FFx then I guess the PAL is decoding addresses in the $5800-$5FFF range.

Ah. Yep. RAM makes sense. It's storing the game selection in there at least. With this mod to the mapper code, it returns to the list at the last selected game on Reset, rather than the default one.

If you try and select past the last page of games on the actual cart it malfunctions. With the RAM in place with this code in the emulator, it wraps correctly to the beginning of the list. Somebody decided wrapping/resetting to the last selected game wasn't worth the cost of the chip.

Other 74'670s we've found power up with all 4 values equal to 0xF, not 0.

Not clear if that's even a consistent thing, or if different manufacturers and/or technology choices tend to other values.

(edit, unrelated: this was apparently my post #6502, which I feel I need to commemorate by ... point it out, I guess)

Yeah, the game looks at 0x5FF1 and if it equals 0x2, then it assumes the data is valid. Otherwise it sets defaults. (Looks like 0x5000 = Cheats/Hacks/Init values for ROMS, 0x5001 = valid RAM data if =0x2, 0x5002/3 store the position in the game list for reset). So 0xF could just as easily be the power up value. It might be more accurate to just set 0x5001 on power on (and again the value isn't 2, but otherwise could be anything). I also used 0x5000-0x5FFF as the range, but I only used that because it was only one character to change when copy/pasting the code. 0x5800-0x5FFF also might be correct, or any values the PAL can access from it's address lines that don't conflict with other things (ie can't be >= 0x8000). Difficult to check either of these without the actual RAM chip in place.

You might just be able to put an LED across the outputs of the PAL (into pins 11&12 of the '670 footprint) and see when it lights.

It'll only be lit for 350ns on each read/write, so you may need a relatively short loop to be able to see it. Or maybe just a dark room?

As you noticed, only A11-A15 go to the PAL, so the window can't be anything finer.

Very good:


Can I ask for ROM so that I can test it on my fpga cartridge?

BTW. 168-in-1 multicart does not have any external register, but it still remembers the position of last chosen game after resetting console.

Never mind, I found that I have this ROM with date of 2011-11-04 so probably it's not so new (and PRG & CHR CRC matches the one you said).

BTW. It's first time I see famiclone PCB with chips populated on both sides.

But it stil not record if taking number of ROMS into account:
https://vk.com/retronicaru:

Hmm...
I remembered that I actually bought a cheap $60 USB scope a couple years ago and opened it up for the first time today.
It looks like I can just barely make out the CLK signal going to the Flip Flops from the PAL (says it's sampling at 2.5 MHz), so I think I ought to be able to see the WE and RE lines going to the 670.
Unfortunately, it looks like I can't. It's actually constantly reading half the voltage of the other pins read when they are high (not sure I trust the displayed voltage on this scope). Maybe this PAL isn't programmed to control those lines because they decided not to with the 670 not in place? Might need to actually have one with the populated RAM to check. For now, I think I like your theory of 0x580x-5FFx, though, as I'm not sure why they'd need the lower address lines going to the PAL if not for this.


If your PRG and CHR match my CRCs than I'm sure you've got the same thing as me. As MLX mentioned earlier, it looks like it was successfully dumped before. I was just basing my knowledge on google searches that said no known good dumps existed, and the one I found to compare with my dump was indeed bad. It looks like someone else did have a good dump, and it's nice to have confirmation that my dump matches someone else's.

As for the resetting, I can think of two ways of keeping the game list position on reset:
1. If they can free up a byte somewhere in all the games you can store it internally. (Maybe reducing the stack size of the games by 1?)
2. If the reset vector for each game writes its own menu values to internal RAM before switching to the bank where the MENU is, that should work.

In any case, this game's menu code was clearly designed with the RAM in place, and not changed when it was removed. Otherwise, the list wrapping wouldn't have required it to work properly. Also, the Cheat/Hacks/Trainers value might have worked as well.
Note that because the RAM is missing, on the actual cart, the menu selections that are supposed to affect gameplay don't work properly. For example, all versions of The New Human/Super Man #(Dino Riki, I think?) have him shooting clones of himself. On the emulator with RAM enabled, the projectiles are different (fireballs, boomerangs, clones) when different versions are selected. Title screen color similarly is different with RAM, and the same on the actual cart (my copy without the RAM).

PALs are digital devices, not analog. If you're seeing a weirdly middling voltage, and not the same as what's going into the two 74'273's latches, then ... I guess it could have configured the pin as an input instead?

My first thought was that it was getting into a fight with something else, but with what could it possibly do so? Those pins don't appear to be connected to anything else.

Maybe I should have linked the CaH4e3 blog post. But yeah I sent this cartridge to him in 2011 because the previous dump was bad.
I have a bunch of those SuperVision carts, I should try your script on them someday.

I'm not sure if it's still not properly dumped or an emulator bug, but I'm super interested in this and I had no idea he had dumped it. I promptly went to test it on emulators and the page changing on the games list bugs on the last page and the second to last page. Try moving the cursor from below and from above. Different bugs but neither works. Also, can't start games from #105-#110. Using nestopia 1.40.

... wait, isn't that exactly mapper 225?

As mentioned in this thread. There is a RAM chip missing from the board. Nestopia does not add this to its emulation. This makes it more accurate to the actual (known) cart. Adding support for the RAM chip depends on whether you want it to work as intended or as implemented, at least until a cart with the RAM populated is found. I'm not sure if that's an intentional choice for Nestopia or not or if they recognized it was designed to have a missing 74670. If you want wrapping to work, you'll need to build your own. The hacks/cheats used in the high numbered games will also not work as expected, as the value used there is also written to the missing RAM chip. The code I posted works with FCEUX (I just threw it into the existing Supervision cpp file for convenience), and just needs the 255 Mapper uncommented: the first one without RAM support; the second with. Adding it to Nestopia would be pretty straightforward.

I'm sorry if this is unwanted or poluting, but I have the 72 pin version of this and I took some photos. Maybe they are interesting somewhat. (nevermind my gradius and arkanoid tips stickers)

Ha. Sure looks like it. I note that Nestopia keeps them separate and doesn't implement the shared high bit on 225 for some reason.


And there's a version with the missing 74670. Nice.

So, were you just looking for the information on the chip or do you want me to do something about it? XD I think I know a friend who could dump it but maybe he can't and haven't talked to him in a while.

Whether you dump or not is up to you. I assume you'll get same thing I did and that CaH4e3 did in 2011. Our PAL contents would be different, as yours only has 3 ROM chips instead of the 6 mine has, but I assume yours are 1MB instead of the 512KB in mine. I think this also explains why I wasn't measuring anything from the PAL to my unpopulated socket. They had redone it when they changed to 512K chips. I apparently only got a pirate copy of the pirate cart (Pirateception), which is why mine is missing the 74670. I should demand a refund! I demand only the finest original pirate carts when purchasing famicom adapters.

Okay... So let me see if I got this right:

- due to the lack of extra ram chip the cartridge you got has the same behavior as the emulated version (bugged last page).
- meaning the emulation is correct for your cartridge.
- meaning it's possible to correctly emulate the version I have (that fully works because the ram chip is present) and you've done it with the code you posted for the ram version.
- the code you posted is meant to be used on fceux source.

All correct?

Rather not, they're probably the same. PAL is not responsible for decoding ROM - it is 74*139's role. THe cartridge latches 15 address bits.
In the NES version there is 74*174 (=6) + 74*273(=8). Probably one of 74*74's gates latches the fiftenth bit and second gate is used as inverter to select between one and the other PRG rom.

Please dump PAL content to confirm the combinatory logic I suggested in my schematics. Be advised, that some of I/O pins are used as inputs. .

Yes it is? By RAM we mean the 74'670.

Sorry, I mean ROM.

this cart, I dumped,mapper 255.

mapper 255,have 10 or more cart!

Congratulations, but how can we help you? When do China holidays start?

Today was the first day I saw the 110-in-1 cartridge being correctly emulated. I used Cah4e3's 2011 dump and mesen. Tried every game, and they all started perfectly, which was a first. I haven't tested games beyond the title screen though. Are there other emulators that can do this? Nestopia does not seem to work. Some games work and other games don't. Is it possible to add support to the everdrive n8 for this mapper?