Cx4-Based Game Ripping

Hello, long time lurker here, but this is my first time posting.

I recently built a homemade SNES Cartridge reader using MCP23017 expander chips for the Raspberry Pi:
http://familab.org/blog/2012/12/snes-su ... ed-system/

I have broken out the IO from the center 46-pin connector, and have read write access to all of the lines with the exception of the CIC pins.

Using Python, I am able to read almost every SNES title I throw at it, with the exception of Mega Man X2. I am guessing this has something to do with the CX4 chip. Checking my ripped image against a downloaded copy of the game seems to suggest that the first 1,048,576 bytes of data is identical. The next 249,422 bytes of data is a mirror from the beginning, as far as I could tell. The rest of the data I can't say.

Do I have to do additional steps to read CX4 games other than incrementing through banks and addresses? Such as, is there game data that I HAVE TO read through CX4 commands?

I am aware that the CIC lock is needed for SA1 games, but outside some passing comments on this forum, I am unable to determine if it is needed as well for CX4 games. As you know, finding this information on the web is increasingly rare. I have the desire to use the Super CIC lock chip for SA1 games, but I have no idea how it will behave outside of an actual SNES. Does the SNES provide the Super CIC with a clock source I'd have to emulate outside of the console? Anyone with experience would be greatly appreciated!

Maybe the banks are mapped in a way you don't expect. What address/bank do you dump from? The game is 12 megabits I think. So the first 8 megs was ok but you don't see the last 4 megs? I've never heard of anything with the Cx4 preventing you from reading ROM. Unless the Cx4 chip is executing and stopping the cartridge from responding or something like that. You're reading from $8000-$FFFF of each bank right?

Correct. I am reading from 0x8000 to 0xFFFF starting from bank 0x00. I also tried starting from bank 0x80 which is a mirror in LoROM. It reminds me. I hold RESET High. Let me try holding reset low, see if I get anything..

I ran the rip again with RESET held low, and it generated the same incorrect checksum. If the cart has special bank mappings, I wouldn't know. Hopefully someone else has had similar issues with this game.

It seems I am doomed to explain this every three months to a new person for the rest of my life :P

$007f52 is a Cx4 register that tells it whether only one ROM chip is needed (value = $00) or whether there are two ROM chips on the board (value = $01)

At power reset, the value is initialized to 0. Mega Man X2 has two ROMs. So because of this, you can't read from the second ROM and the last 4mbits is dumped as 0x00s. It works with Mega Man X3 because that board only has one ROM chip.

So to dump MMX2, write $007f52 = #$01 first. To dump MMX3, you don't have to do anything, but you may as well write $007f52 = #$00 just in case.

If you can't write to the bus with your dumper, then you're out of luck. But rest assured, a dozen people have dumped MMX2 and RMX2, the dumps out there are perfect copies.

Thanks, byuu! Maybe this should this topic should be made a sticky?

I do have complete I/O to all the lines. I've been afraid to turn the data lines into outputs as if the cart is outputting say a HIGH 5v, and my reader sends a 0v to the same line, wouldn't that be a direct path? Do SNES carts have protection for such things? I know you could use the /WR /RD and /CS lines for writing to SRAM, but haven't had to yet.

From http://www.emulatronia.com/doctec/conso ... skart.html:



Would this be similar to writing to SRAM? Do I place /CS and /RW LOW, and /RD HIGH?

One last thing. You said to write to offset $007f52. Is that assuming A15 is held high? This is a LoROM title, after all.
As it is writing to addr 0x7f52 with loROM in my code will write to 0xFF52 as it will OR 0x8000 to the value. I have complete control, though.

That's called a "bus conflict", and at least NES carts don't appear to be hurt too much.

byuu, you are the man! You have it backwards though. I found that $007f52 read 1 in Mega Man X 2. I was able to write to it, change it to 0, and that did the trick. I suppose if Mega Man X3 is 8megs, going by your analysis the value should be kept at 1.

To write to the register, I held /RD and RESET high, and held /CS, and /WR low. I changed direction of the data I/O to output, and wrote the value, and then changed the control values back, and ripped. The checksums match now. This should be stickied. I searched the web after you made your post, and I still couldn't find any information elsewhere on this register. If it's out there, provide me with a link. If I missed it I'd like to know so I could Google better next time.

> One last thing. You said to write to offset $007f52. Is that assuming A15 is held high?

No, we're writing to a different area where the chip's registers are at.

> byuu, you are the man! You have it backwards though. I found that $007f52 read 1 in Mega Man X 2.

Shoot, sorry. Boolean logic is my Achilles' heel.

All the same, glad you got it working.

> I searched the web after you made your post, and I still couldn't find any information elsewhere on this register.

It's on my forum, but it's not indexed; also gave the information to nocash and to the Retrode author. No big deal.

...

Well now that you can write, you can also dump S-DD1 and SPC7110 boards. Throw in a SuperCIC and you can dump SA-1 boards. Do that, and you'll have a fantastic product to sell :D