Mapper 255

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Mapper 255

Post by zeroone »

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?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mapper 255

Post by lidnariq »

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.
GreyRogue
Posts: 51
Joined: Fri Dec 08, 2017 5:12 pm

Re: Mapper 255

Post by GreyRogue »

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:

Code: Select all

/*
110 in 1

6 et44x (27c040?)
ks74hctls273n = 8 bit flip flop
gd74ls273 = 8 bit flip flop
ar +b9048 pal16l8anc
hd74ls139p = 2x 2to4l  00 = o0 low 11 = o3 low
*/

board <- {
	mappernum = 255,
	cpu_rom = {
		size_base = 16 * mega, size_max = 16 * mega,
		banksize = 0x8000
	},
	ppu_rom= {
		size_base = 8 * mega, size_max = 8 * mega,
		banksize = 0x2000
	},
	ppu_ramfind = false, vram_mirrorfind = true
};
function cpu_dump(d, pagesize, banksize)
{
	for(local i = 0; i < pagesize; i++){
		cpu_write(d, 0x8000 | ((i << 7) & 0xF80) | ((i << 9) & 0x4000), 0x00);
		cpu_read(d, 0x8000, 0x4000);
		cpu_read(d, 0xc000, 0x4000);
	}
}
function ppu_dump(d, pagesize, banksize)
{
	for(local i = 0; i < pagesize; i++){
		cpu_write(d, 0x8000 | (i & 0x3F) | ((i << 8) & 0x4000), 0x00);
		ppu_read(d, 0, banksize);
	}
}
Attachments
Scan_20171208 (3).png
IMG_20171208_1845431_rewind.jpg
IMG_20171208_1845183_rewind.jpg
Scan_20171201 (7).png
Scan_20171201 (6).png
Last edited by GreyRogue on Sun Dec 10, 2017 9:24 am, edited 1 time in total.
MLX
Posts: 110
Joined: Tue Feb 14, 2017 9:50 am

Re: Mapper 255

Post by MLX »

But wait, didn't CaH4e3 dump this cart in late 2011?
GreyRogue
Posts: 51
Joined: Fri Dec 08, 2017 5:12 pm

Re: Mapper 255

Post by GreyRogue »

MLX wrote: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):

Code: Select all

static uint16 cmd3;
static SFORMAT StateRegs110[] =
{
	{ &cmd3, 2, "L3" },
	{ 0 }
};

static void Sync110(void) {
	const uint16 address = cmd3;
	const uint16 mode = (~address >> 12 & 0x1);
	const uint16 bank = (address >> 8 & 0x40) | (address >> 6 & 0x3F);

	setchr8((address >> 8 & 0x40) | (address & 0x3F));
	setprg16(0x8000, bank & ~mode);
	setprg16(0xC000, bank | mode);
	setmirror(((address & 0x2000) >> 13) ^ 1);
}

static DECLFW(Super110Write) {
		cmd3 = A;
		Sync110();
}

static void Super110Power(void) {
	SetWriteHandler(0x8000, 0xFFFF, Super110Write);
	SetReadHandler(0x8000, 0xFFFF, CartBR);
	cmd3 = 0;
	Sync110();
}

static void Super110Reset(void) {
	cmd3 = 0;
	Sync110();
}

static void Super110Restore(int version) {
	Sync110();
}

void Mapper255_Init(CartInfo *info) {
	info->Power = Super110Power;
	info->Reset = Super110Reset;
	GameStateRestore = Super110Restore;
	AddExState(&StateRegs110, ~0, 0, 0);
}
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mapper 255

Post by lidnariq »

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.
GreyRogue
Posts: 51
Joined: Fri Dec 08, 2017 5:12 pm

Re: Mapper 255

Post by GreyRogue »

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.

Code: Select all

static uint16 cmd3;
static uint8 cmd4[4];
static SFORMAT StateRegs110[] =
{
	{ &cmd3, 2, "L3" },
	{ &cmd4, 4, "L4" },
	{ 0 }
};

static void Sync110(void) {
	const uint16 address = cmd3;
	const uint16 mode = (~address >> 12 & 0x1);
	const uint16 bank = (address >> 8 & 0x40) | (address >> 6 & 0x3F);

	setchr8((address >> 8 & 0x40) | (address & 0x3F));
	setprg16(0x8000, bank & ~mode);
	setprg16(0xC000, bank | mode);
	setmirror(((address & 0x2000) >> 13) ^ 1);
}

static DECLFW(Super110Write) {
		cmd3 = A;
		Sync110();
}

static DECLFW(Super110RamWrite) {
	cmd4[A & 0x3] = V & 0xF;
}

static DECLFR(Super110RamRead) {
	return cmd4[A & 0x3] & 0xF;
}

static void Super110Power(void) {
	SetWriteHandler(0x5000, 0x5FFF, Super110RamWrite);
	SetReadHandler(0x5000, 0x5FFF, Super110RamRead);
	SetWriteHandler(0x8000, 0xFFFF, Super110Write);
	SetReadHandler(0x8000, 0xFFFF, CartBR);
	cmd3 = 0;
	cmd4[0] = cmd4[1] = cmd4[2] = cmd4[3] = 0;
	Sync110();
}

static void Super110Reset(void) {
	cmd3 = 0;
	Sync110();
}

static void Super110Restore(int version) {
	Sync110();
}

void Mapper255_Init(CartInfo *info) {
	info->Power = Super110Power;
	info->Reset = Super110Reset;
	GameStateRestore = Super110Restore;
	AddExState(&StateRegs110, ~0, 0, 0);
}

Last edited by GreyRogue on Sun Dec 10, 2017 2:31 pm, edited 1 time in total.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mapper 255

Post by lidnariq »

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)
Last edited by lidnariq on Thu Dec 14, 2017 3:32 pm, edited 1 time in total.
GreyRogue
Posts: 51
Joined: Fri Dec 08, 2017 5:12 pm

Re: Mapper 255

Post by GreyRogue »

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.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mapper 255

Post by lidnariq »

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.
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: Mapper 255

Post by krzysiobal »

Very good:
Image Image Image

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:
Image Image
GreyRogue
Posts: 51
Joined: Fri Dec 08, 2017 5:12 pm

Re: Mapper 255

Post by GreyRogue »

lidnariq wrote: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).
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mapper 255

Post by lidnariq »

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.
MLX
Posts: 110
Joined: Tue Feb 14, 2017 9:50 am

Re: Mapper 255

Post by MLX »

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.
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Mapper 255

Post by nesrocks »

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.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Post Reply