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?

Author:

lidnariq [ Mon Apr 13, 2015 4:27 pm ]

Post subject:

Re: Mapper 255

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.

Author:

GreyRogue [ Fri Dec 08, 2017 5:31 pm ]

Post subject:

Re: Mapper 255

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.

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.

Author:

GreyRogue [ Sun Dec 10, 2017 1:46 pm ]

Post subject:

Re: Mapper 255

lidnariq wrote:

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)

Author:

GreyRogue [ Sun Dec 10, 2017 3:18 pm ]

Post subject:

Re: Mapper 255

lidnariq wrote:

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.

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.

Author:

lidnariq [ Sun Dec 10, 2017 4:08 pm ]

Post subject:

Re: Mapper 255

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.

Author:

krzysiobal [ Tue Dec 12, 2017 9:51 am ]

Post subject:

Re: Mapper 255

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.

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.

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.

krzysiobal wrote:

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).

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).

Author:

lidnariq [ Tue Dec 12, 2017 7:43 pm ]

Post subject:

Re: Mapper 255

GreyRogue wrote:

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).

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.

Author:

MLX [ Wed Dec 13, 2017 1:12 am ]

Post subject:

Re: Mapper 255

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.

Author:

nesrocks [ Thu Dec 14, 2017 4:02 pm ]

Post subject:

Re: Mapper 255

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.