SNES memory write interception using Raspberry Pi Pico (for an achievements adapter)

[odelot]

Hi everyone!
I'm the developer of the NES Achievements Adapter project: github.com/odelot/nes-ra-adapter

I’ve been thinking about what the main challenges would be to build something similar for the SNES, using a Raspberry Pi Pico and the PIO for fast bus monitoring.

I made a proof of concept to intercept WRAM writes, but I realized that not all writes were being detected.

Here’s what I did so far:

I tapped into the data lines and address lines A0–A16, which should map to the two WRAM pages.

I also used the M2 and WRSEL signals to detect writes.

With that setup, I was able to catch some writes, but definitely not all of them.

My main questions are:

1. Is WRSEL a reliable signal to detect writes to WRAM, since it’s on the side usually not used by cartridges?

2. Since the SNES has two buses, do I need to intercept both?

3. Do DMA writes trigger WRSEL as well?

4. Is it common for games to use SRAM on the cartridge? If so, would WRSEL also be triggered?

5. Would there be a better signal or strategy to detect writes to both WRAM and cartridge SRAM?

If you’re curious, the source code for my PoC is here:
github.com/odelot/snes-ra-adapter-poc

And I’ve also made a couple of short demo videos:

https://youtu.be/BznORG7JtVQ

https://youtu.be/alV1YOO3Cyo

Any insights or hints about what I might be missing would be greatly appreciated. Thanks in advance!

[creaothceann]

1. Is WRSEL a reliable signal to detect writes to WRAM, since it’s on the side usually not used by cartridges?

If the game uses address bus A, yes (afaik).

2. Since the SNES has two buses, do I need to intercept both?

WRAM can also be accessed via registers $2180..$2183 - specifically, DMA'ing a sequence of bytes to register $2180 will write these bytes into WRAM.

5. Would there be a better signal or strategy to detect writes to both WRAM and cartridge SRAM?

Cartridges can theoretically handle address bus and data bus values in any way they want, but most cartridges follow one of several conventions.

Nintendo used/offered several cartridge PCB layouts and mapper chips, and games could fill these mapped areas with varying amounts of SRAM and/or ROM. Near/byuu actually spent several years and thousands of dollars on documenting all SNES games. I don't know how far he got with the Super Famicom games.

If you're curious, check out the source code of bsnes/higan/ares.

[stan423321]

Can you say more specifically how you detect a system RAM write? It seems to me 17 bits of A address bus is merely enough to get the address within the RAM, but there are other writes that can happen there even in a simplest configuration without cartridge SRAM (DMA registers, for example).

Based on the above and cartridge SRAM being fairly common I'm afraid you may need an rp2350b, just for the pin count of course.

Expect problems with finding interesting RAM to watch for games with bigger coprocessors.

[odelot]

Can you say more specifically how you detect a system RAM write? It seems to me 17 bits of A address bus is merely enough to get the address within the RAM, but there are other writes that can happen there even in a simplest configuration without cartridge SRAM (DMA registers, for example).

Based on the above and cartridge SRAM being fairly common I'm afraid you may need an rp2350b, just for the pin count of course.

Expect problems with finding interesting RAM to watch for games with bigger coprocessors.

I already got a rp2350b to have enough pins to cover all the address lines but I am gathering information (and courage) before start a new project.

I am also afraid of how PIO works with more than 32 IOs. If I have two use two PIOs with DMA to cover all the bus will be a nightmare to sync the readings.

Thanks guys for all the info! I will try to study the SNES architecture a little more.

[Oziphantom]

SRAM has no fixed layout so you will need to detect which mapping the board is in, LOROM,HIROM, ExHiROM, ExLoROM or SA-1 not sure how you could do this by snooping the bus though or detect the amount of SRAM the game has by snooping but as you will need to load a program for the actual game for achievement tracking it will have to tell your code which memory map layout the game uses. And then you will have to track the full 24bit address bus to track all and any SRAM writes by doing a full address decode. SRAM will only be A bus only at least.

[odelot]

Can you say more specifically how you detect a system RAM write? It seems to me 17 bits of A address bus is merely enough to get the address within the RAM, but there are other writes that can happen there even in a simplest configuration without cartridge SRAM (DMA registers, for example).

Based on the above and cartridge SRAM being fairly common I'm afraid you may need an rp2350b, just for the pin count of course.

Expect problems with finding interesting RAM to watch for games with bigger coprocessors.

About use 17 bits to detect memory writes:

Since the Raspberry Pi Pico has 30 GPIOs available for the proof of concept, I followed this line of reasoning: 8 pins for the data bus, 2 for serial communication with the ESP32, 3 control lines (WRAM, R/W, and M2), and 17 for the address bus.

That means A0–A15 take 16 pins, and I used the remaining one to read A23 A16 — the highest address bit. According to this doc: https://snes.nesdev.org/wiki/File:Snes_overall_map.png, the SRAM is mapped into two 16-bit banks at addresses $7E and $7F (binary 01111110 and 01111111 - range A23-A16). Since the WRAM signal tells me when the access is to Work RAM, I only needed A23 to know which of the two banks was being accessed.

This way I could detect some memory writes as you can see on the videos, but is far from ideal. Had some buffer overflows from pico DMA, I am not sure I am getting data transfered by snes DMA and probably games are using internal ram that I am also missing

edit: corrections in bold

[Oziphantom]

no WRAM is 7e0000-7fffff and mirrors at 0000-7FFF in half the banks.
SRAM is all over the place.

[93143]

no WRAM is 7e0000-7fffff and mirrors at 0000-7FFF in half the banks.

You mean 0000-1FFF, right? Shadow RAM is only 8 KB. I guess that shouldn't matter for this exercise...

[Oziphantom]

yes 1FFF for WRAM, I had mirroring in my head, which is the full range.

[odelot]

I guess mirroring isn’t really relevant when you’re sniffing the hardware bus and you have a signal that actually enables the memory chip. Mirroring usually just happens because some address lines aren’t connected to the RAM chip, so those bits are ignored by the hardware.

[stan423321]

I mixed up WRAMEN signal with something else.

Based upon the SNES WRAM pinout on the wiki, you can get away with WRAMEN and eighteen A address pins. Namely, A0-A16 (17) and A22. You need to ignore at least A16 unless A22 is also on; 010000 maps to the same byte as 000000, 800000 and 7E0000, but not 7F0000. A23 has no real stake in this.

Perhaps some games would work for achievement detection without intercepting B bus if you wrote to your RAM copy when they're read over bus A. Hard to say, really.

[tepples]

"and" in the sense that you may not have to connect both A22 and A16 as inputs if you can AND them together some other way, right?

[odelot]

I mixed up WRAMEN signal with something else.

Based upon the SNES WRAM pinout on the wiki, you can get away with WRAMEN and eighteen A address pins. Namely, A0-A16 (17) and A22. You need to ignore at least A16 unless A22 is also on; 010000 maps to the same byte as 000000, 800000 and 7E0000, but not 7F0000. A23 has no real stake in this.

Perhaps some games would work for achievement detection without intercepting B bus if you wrote to your RAM copy when they're read over bus A. Hard to say, really.

I revisited my PoC and realized I had actually hooked up A16, not A23, to select the WRAM banks (I’ll edit my previous post to fix that). I wasn’t using A22 (the chip enable signal) because I relied on /CS3 (or /WRAMSEL) to determine whether the A0–A16 address was a valid WRAM access.

I was also thinking that, since I’m tapping directly into the hardware lines connected to the SRAM chip, I don’t need any custom heuristic to handle SNES DMA memory writes. The DMA controller will use the same physical bus lines to transfer data to memory, making the bus busy during the operation.

So I believe this approach should capture all writes, including DMA transfers.

My next step will probably be migrating to an RP2350B, so I can get full address coverage, detect writes to cartridge SRAM, process data fast enough to avoid buffer overflows from the PIO reads, and also read the cartridge ROM to identify the game.

[stan423321]

If you plan to keep using A0-A16 and WRAMEN without involving A22, externally or internally, I don't see how you would distinguish writes to low RAM in odd LoROM areas from the writes to second half of full WRAM area.

If you're planning to monitor the full double bus now, that's obviously doable.