Advice wanted on manipulating $213F for region unlocking

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
meepowl
Posts: 11
Joined: Sat Oct 22, 2022 7:14 am

Advice wanted on manipulating $213F for region unlocking

Post by meepowl »

Hi,

I'm hoping to get some advice about manipulating reads of bit 4 on $213F for the purpose of spoofing the SNES's region, for those games that need it. I'm already using an Arduino Nano to switch between 50/60Hz on the PPUs and turning the CIC on/off. Ideally I'd like to implement something to deal with $213F as well.

So, my first question is quite basic and clearly I'm missing something obvious: if Bus B is the one attached to (amongst other things) the PPUs and is only 8 bits wide, how can a value as high as $213F be addressed?

I've looked at the PPU registers section of the Nintendo development manual and anomie's docs but if the answer's there, I'm not understanding it.

I suppose the short version is: what values on Bus B do I need to be looking for before trying to trigger an override?

I was also going to ask how you can override the value of bit 4 on the data bus with the PPU still attached. That one's been answered here - viewtopic.php?t=5676&hilit=213F&start=75 - but if anyone has any further advice I'd be very grateful. Clearly the most certain way is to desolder the pins but I'd like to avoid this if possible.

Thanks!
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Advice wanted on manipulating $213F for region unlocking

Post by lidnariq »

meepowl wrote: Sat Oct 22, 2022 8:46 am So, my first question is quite basic and clearly I'm missing something obvious: if Bus B is the one attached to (amongst other things) the PPUs and is only 8 bits wide, how can a value as high as $213F be addressed?
The peripheral address bus ("B" or "PA") is automatically enabled by the CPU and/or DMA unit when needed - i.e. when the CPU is addressing banks 00-3F or 80-BF and page 21, the CPU drives one of the /PARD and /PAWR signals low. When DMA is happening, the same is true.

When it's not being used, the PA bus does its own random thing, but the /PARD and /PAWR signals stay high.
I suppose the short version is: what values on Bus B do I need to be looking for before trying to trigger an override?
Not only checking for 3F but also checking for /PARD
I was also going to ask how you can override the value of bit 4 on the data bus with the PPU still attached. That one's been answered here - viewtopic.php?t=5676&hilit=213F&start=75 - but if anyone has any further advice I'd be very grateful. Clearly the most certain way is to desolder the pins but I'd like to avoid this if possible.
Desoldering is not sufficient, because other PPU functions need that pin to stay connected. So either you have extra hardware that relays the signal most of the time, or you induce a big ol' bus conflict and win and hope it doesn't damage the PPU.

Suffice to say, most people use ROM hacks to remove the region protection instead. UCON64 seems to be capable of this.
meepowl
Posts: 11
Joined: Sat Oct 22, 2022 7:14 am

Re: Advice wanted on manipulating $213F for region unlocking

Post by meepowl »

Thank you, that's really helpful.

So I would need to look for /PAWD being pulled low. I'm still not quite following how the various peripherals (their registers) map to addresses on the PA bus.

You said 'checking for 3F', so that means (as well as /PAWD low) the CPU reads from $213F by setting the PA bus to 0011 1111, or am I taking 'checking for 3F' too literally?

Thanks also for the advice on the bus conflict stuff. It's tempting to try some sort of pass through but I'm already using both available interrupts on the Arduino to read the state of the controller, so I'd need a bit of a rethink.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Advice wanted on manipulating $213F for region unlocking

Post by lidnariq »

meepowl wrote: Sat Oct 22, 2022 4:05 pm So I would need to look for /PAWD being pulled low. I'm still not quite following how the various peripherals (their registers) map to addresses on the PA bus.
/PARD - "peripheral address read".
You said 'checking for 3F', so that means (as well as /PAWD low) the CPU reads from $213F by setting the PA bus to 0011 1111, or am I taking 'checking for 3F' too literally?
That was the correct amount of literalness.
Thanks also for the advice on the bus conflict stuff. It's tempting to try some sort of pass through but I'm already using both available interrupts on the Arduino to read the state of the controller, so I'd need a bit of a rethink.
Microcontrollers are usually the wrong thing here - this is usually something you need to do with programmable or discrete logic.

Particularly fast and lightweight microcontrollers may be up to it. Normal "fast" microcontrollers have too much state for an interrupt and too much jitter for polling, but the RP2040 is promising.
meepowl
Posts: 11
Joined: Sat Oct 22, 2022 7:14 am

Re: Advice wanted on manipulating $213F for region unlocking

Post by meepowl »

Thank you for all the help.

I still need to better understand how the various peripheral registers are allocated addresses on the PA bus but what I'm looking for to get at the region bit is clear.

Does 'too much state for an interrupt' mean (in effect) that they're too slow switching from whatever they happen to be doing to executing the interrupt code?

I'd started looking at the RPi Pico last night after I'd realised I was probably running out of pins on the Nano. The next thing is finding a physically small way of level shifting a lot of pins, as I'm stuck with through-hole soldering and I'm not massively confident in the little level-shiting modules aimed at Arduino/RPi. Opinions seem to differ a lot on whether they're any good. But in general a Pico would open up a lot of possibilities.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Advice wanted on manipulating $213F for region unlocking

Post by lidnariq »

meepowl wrote: Sun Oct 23, 2022 1:20 pm Does 'too much state for an interrupt' mean (in effect) that they're too slow switching from whatever they happen to be doing to executing the interrupt code?
Yup. Too much interrupt latency because they need to store too much state.
meepowl
Posts: 11
Joined: Sat Oct 22, 2022 7:14 am

Re: Advice wanted on manipulating $213F for region unlocking

Post by meepowl »

Hi - Thanks again for all the help. I've been exploring the Raspberry Pi Pico option and was hoping to get some advice on level shifting.

If the SNES clock runs at 21Mhz, the peripheral bus is fast and fast buses take 6 master clock cycles to read/write, that comes out at 3.5Mhz.

That works out at 286ns per read/write operation on this bus.

I have several TXS0180-based 8-channel level shifters (datasheet: https://www.ti.com/lit/ds/symlink/txs01 ... e.com%252F).

These have a 60Mbps 'data rate' which I am assuming is per channel, rather than for all 8 in parallel, as it quotes a 16.7ns pulse duration (page 8).

In any case, the propagation delay (high-to-low/low-to-high cycle) is in the region of 1.6ns - 8.6ns depending on the direction, at 5V on the high side and 1.8V on the low side (there's no value for 3V to 5V/vice-versa) (page 9).

I can't help feeling this is all too easy but it appears these should be suitable for passing through the value of the region bit (most of the time) and intercepting/spoofing it when the CPU tries to read from $213F.

What do you think?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Advice wanted on manipulating $213F for region unlocking

Post by lidnariq »

Yeah, that would work...

The equivalent circuit you're implementing is basically this:
Attachments
snes-213fd4-region-override.png
snes-213fd4-region-override.png (4.64 KiB) Viewed 650 times
Post Reply