Cx4 Pinout

I can't seem to find a pinout of the Cx4 coprocessor, so I've traced it out for myself. I have 78 of the 80 pins traced, and the other 2 are probably inputs, which are a lot trickier to figure out than outputs. Maybe one is a Hi/LoROM signal like MAD-1 pin #10?

A0..23, D0..7, RD, WR, RST, etc. are connected to the cart edge
RA0..20, RD0..7, ROE, RCE, etc. are connected to the ROM
RCE1 is CE on the first ROM if 2x8Mbit ROMs are used, or the only ROM if a 16Mbit ROM is used
RCE2 is CE on the second ROM if 2x8Mbit ROMs are used
SCE is SRAM /CE



Pins 73-75 are a bit weird, the fact that they're all GND, and on MMX2, there's what appears to be an optional jumper between pin 75 and the other two. So they may have a purpose on the chip, but they aren't used on either MMX2 or MMX3.

Edit: I've removed the chip from the PCB, and pins 74 and 75 are NOT internally connected to GND, so they are obviously not supply ground pins, they're probably inputs, but possibly I/O, and just tied to ground on the PCB. I've changed them in the pinout list.

Edit 2: Pin 61 is /IRQ. Somehow missed that one during continuity testing.

Edit 3: Despite what I said about /RCE1 being used as the only ROM /CE for a single-ROM board, Nintendo apparently decided instead to use /ROE as a /CE signal on RMX3/MMX3, and the ROM chip's /OE pin is just connected to Gnd. Nonetheless, I can confirm that /RCE1 can be used as a /CE signal for a single ROM board, if /ROE is used for its intended purpose and connected to the ROM's /OE pin.

If anybody has any more information, I'd really appreciate it.

Gazing at the PCB photo, pin 73+74 seem to be wired straight to GND, so they are probably normal supply GND. If you really wanted to, you could lift the pins, and check if they are interconnected inside of the chip. If they aren't, then one of them may be something special.

And pin 75, looks as if one is supposed to cut the CL link, and to install the R4 resistor instead (which probably pulls pin 75 to VCC?). If you've some tool for dumping the cartridge, you could do some before/after test... maybe it maps it as HiROM instead of LoROM... or it makes the game 500 times faster :-)

For the two ??? pins, maybe SRAM select, and SRAM write? Since they are near ROM selects and ROM read accordingly.

Ah yes, if I haven't mentioned it ...

The Cx4 maps 70-77:0000-7fff to SRAM. It always reads as 0x00 (not open bus) on MMX2/MMX3.

Seems Capcom had intended to allow the chip to optionally support SRAM at some point, but of course it never ended up being used.

byuu, just thought I'd point out that pin 34 is not /WE like Charles MacDonald seemed to think. At least, I can confirm on MMX3, it's connected to ROM A20. So, I'm not sure if programming the ROM via the cart edge is even possible. I'm still figuring out the various quirks of my logic analyzer, but I'll try to figure out those last 2 pins. The assumption that they're SRAM control lines at least gives me something to go on. If it turns out that it's not possible to perform writes to ROM, but we can figure out the SRAM control signals, would it maybe be feasible to wire in an SRAM module, burn a simple ROM that bootstraps to SRAM, then you could upload your code to the SRAM and run your tests that way?

Would it not be easier to tap /WE right off of the connector pins at the bottom of the PCB?

I am not sure how easy it'd be to rig up SRAM onto the board, and be able to write into that SRAM otherwise. But ... yes, I can do any reads and/or writes after the cart is inserted to get code onto the Cx4 to execute.

I believe both nocash and Overload have successfully made their own Cx4 proto boards, so we might ask them for advice?

Overload's board:


My guess is they were probably able to just reprogram the flash ROM directly, which isn't something I can easily do.

Is that second board another SNES cart? Why??

And yes, it would be possible to just tie the ROM /WE directly to the cart /WE, I'll just have to do some tests to ensure that the data bus is active during writes to the ROM address space.

As for the SRAM, 70-77:0000-7FFF gives 480KBytes addressable, right? I know that's kind of a dumb question, but it's late, and I don't trust my sleep-deprived math skills...

I think that design isn't mandatory :-) maybe overload did have some un-socketed SRAM/FLASH memory on the left board, and decided to hook it up to the CX4 board.
A smaller daughterboard with memory chip socket should do it, too. Myself, I would probably use ribbon cables to wire it to the CX4 ROM pins (and keep CX4 ROM installed, only deactivate it's /CE pin).
Byuu, no, I don't have any CX4 hardware.


Ideally, you would full write access to ROM (via RD0..RD7 databus, and CX4 Pin51=/WE (or alternatly, less ideal, via SNES cart /WE)). Might be a 50% chance that Capcom has implemented it like that.

If the databus is inactive during ROM writes would be a problem. But there should be a way around that: You could have /ROMCE1 (CX4.Pin26) ANDed with /SRAMCE (CX4.Pin25, presumably), and wire that to you FLASH/SRAM chip. Then you'd have full write access (to banks 70-77), and would get the same memory mirrored to ROM area (banks 00-07). That should work fine (unless you need more than 8 banks).


Could be also 256Kbytes (8 x 32K)... but not sure, I just woke up and didn't had much coffee yet.

PS. no idea what CX4 Pin 61 could be intended for (if it does have any purpose at all).

That sounds better... not sure where I came up with 480 -_-

Yes, the second board is another snes board with the maskrom removed replaced with a socket. Flashrom is socketed on the second board and the wires match pins with the second maskrom of a Rockman X2 board which has also been removed. Used to run custom code on the CX4.

Why didn't you just wire a socket to the MMX PCB?

My guess would be pin sizes not accommodating the socket. The Cx4 ROMs are tiny.

It's not that bad

No big deal, though. To each his own

I've removed the chip from the board, and pin 73 is supply ground, pins 74 and 75 are not. I updated the list above to reflect that. So that leaves me with 5 unknown pins.

nocash, if you used my info in your docs, you should probably change that.

Pin 61 is /IRQ. It connects right up to the cart edge. Not sure how I missed it. Derp

The CX4 supports IRQs? Cool. That's new to me.
As far as I know the megaman games don't use that feature.
At least they seem to work without emulating it.

Well, all I know is that pin 61 on the Cx4 connects to pin 18 on the cart edge.

If it's anything like the SA-1, it probably uses this as a "trigger" to inform software running on the main SNES CPU when a particular "thing" has completed.

You just defined interrupt requests in fine /r/ELI5 fashion

Neat. If it has IRQ functionality, it'll most likely be tied to the HALT instruction. Aside from code in SNES WRAM constantly reading that register, that'd be the only way to know when the Cx4 finishes executing, since Cx4 programs have to take over the ROM chip.

Its status is returned in $7f5f twice, so one of those bits is probably an IRQ acknowledge.

The IRQ enable bit would most likely reside in $7f48, 7f4c, 7f50, 7f51 or 7f52. Most likely, it is not 7f52, as that configures the number of ROMs selectable. Based on the number of bits assignable, $7f48 or 7f51 are the most likely candidates.

If it's there, I'll find it with the dev cart =)

Well, I'm pretty comfortable calling pin 25 SRAM /CE with this. Reads and writes across the full $70-7F:0000-FFFF address space pull pin 25 low, then strobe pin 51 or 52 accordingly. Down to 2 unknowns.

Well, now that I have that all figured out, the next step is to build a from-scratch Cx4 dev board, with 2x16Mbit ROMs (though realistically 1x16Mbit + 1x8Mbit is all that's really useable...) and 256Kbit SRAM. Since I know the /CE pins get held low and don't toggle, I'm including an optional footprint for a 74*00 configured to decode a toggled /CS for non-volatile F-RAM instead of the SRAM. Or, if you prefer traditional SRAM, I'm also including footprints for a battery and a DS1312 NVRAM controller. With pins 74 and 75 unknown, I'm thinking I'll connect them each to Gnd through a solder jumper, so they can be disconnected if so desired. I may make it a 2-way jumper to Vcc or Gnd if I come across any indication that such a thing might be useful.

Just found another CX4 pinout document: http://cgfm2.emuviews.com/new/cx4tech.txt
It does have some missing pins, too. The pins marked "Likely A15,A16,A17,A18,A19" may be wrong. The two /RCS pins, /ROE and /IRQ are looking good. And well, look for yourself what is same/different.
Oh, but one very basic different thing: The cx4tech.txt file lists Pin 66 as Ground (not VCC).

Pin 66 connects to a short trace into a pair of vias that connect right in the middle of a fill plane on the back of the board connected to pin 27 on the cart edge. On RMX2, there's also a decoupling capacitor to Gnd, which may have been why that document listed it as being connected to Gnd, if they didn't understand the purpose of the decoupling capacitor and just traced it from the Gnd side of the capacitor, then it would have looked like it was connected to Gnd. But it's definitely Vcc, and based on a few geometry decisions on RMX3, as well as the decoupling cap on RMX2, I'm fairly confident it's a supply pin, not just a digital input pulled high by connecting it to Vcc. Again, I don't currently have a chip desoldered, so I can't check the Vcc/Gnd pins for internal connections, but that would be the easy way to know for sure.

Edit: Many of the differences between that document and mine are due to the pinout he used for the MaskROM. Take a look at this thread where they're discussing exactly that same issue. You can see from the fact that he wrote down the pin number that it matches up completely with my tracing of RMX2 here, he just used an incorrect MaskROM pinout for determining what to name the signals. I believe he has a typo for pin 52, because he says it connects to ROM pin 3, but calls it A18, then look at pin 33, also ROM pin 3, but he calls it A15. He probably meant ROM pin 31 for Cx4 pin 52. SNES MaskROMs, even those labeled LH538/LH534, do NOT share the same pinout as the Sharp LH538 datasheet. This is where the logic analyzer/functional testing comes in, because continuity testing requires reliable pinouts for all of the other devices in order to understand what they're connected to. I've only really done logic analysis on the control pins (the various /CE's, /OE's, and /WE's), however, the fact that I was able to program a ROM before mounting it to the board and the game ran correctly gives me a lot of confidence that my address lines are all assigned correctly. Same goes for the flash ROM program sequence, which requires writing to several specific addresses on the ROM, and wouldn't work properly if the ROM's pins had been swapped around like is sometimes done for EEPROM repros.