nesdev.org

Yes. It will be switchable between "force 50Hz", "force 60Hz" and "auto".

This is the planned behavior. "PIC" is the user setting, "game" is the detected CIC region.

ikari_01 wrote: The PIC mod will also allow the user to set a preferred region. e.g. it can stay in 60Hz mode whenever possible except when a PAL game is detected. In that case it will set 50Hz mode for ~10 seconds to trick the software region detection, then switch to 60Hz.

Some protected games do their check during the game, not only at the beginning. So, you can play about 10 minutes and then get the "this game pack is not designed" message.

PICs don't come with crystal balls, so you'll have to switch manually in that case. And there's always the auto option.

I would give a hold-reset based override option.

That's exactly what's planned. Current setting is indicated by a dual LED. Inspired by seb's switchless mod. I just heard about the rainbow mod for the first time here

Hi there. These new findings are quite exciting.

Zonomi wrote:Some protected games do their check during the game, not only at the beginning.

ikari_01 wrote:PICs don't come with crystal balls, so you'll have to switch manually in that case.

One doesn't need a crystal ball ^ ^
AFAIK, a majority of games detect the region on runtime by checking the fourth bit of register $213f.

I don't know if you can address this register from the PIC though. See Anomie's register doc for the details.

--
edit: link

Marcel wrote:I don't know if you can address this register from the PIC though. See Anomie's register doc for the details.

--

romhacking.net does NOT allow hotlinking to any of its documents. Even copy/pasting the link does NOT work. You instead have to link here.

just so the ideas out in the open.. i'm using the delay at the beginning of the SNES lock to detect the system because the NES doesn't have it

Marcel wrote:One doesn't need a crystal ball ^ ^
AFAIK, a majority of games detect the region on runtime by checking the fourth bit of register $213f.

I don't know if you can address this register from the PIC though. See Anomie's register doc for the details.

most adapters use a chip such as the TIBPAL16L8-25CN or some other programmable array logic... if i remember correctly i saw a AVR or PIC MCU with a PGA on board. i don't know if it has enough pins and it could also be over kill..

caitsith2 wrote:romhacking.net does NOT allow hotlinking to any of its documents. Even copy/pasting the link does NOT work. You instead have to link here.

blargg came up with a better solution last time this came up:

http://web.archive.org/web/200806040318 ... 5Dregs.txt =)

Microcontrollers don't make very good address decoders..

How to inject a bit? I can decode the B Bus address + /PARD and drive an output connected to D4 but the PPU will still drive its own, won't it?
Does it come down to just hoping that the logic gate's output driver is strong enough to override the PPU output? Or is there a way to tell the PPU to tristate its data lines?

Not that I'm planning to implement this right now, just curious. Won't have time for the next couple of days. And of course it cannot be done with a PIC alone.

I don't think overriding the line is a good idea...

Seems a little extreme to add hardware to do what can probably be done by changing one instruction into a NOP in the program.

Memblers wrote:Seems a little extreme to add hardware to do what can probably be done by changing one instruction into a NOP in the program

this is fine if you have a flash cart or some flash roms and you don't care if you deface your game. game genie could patch a game but it probably doesn't work on most of them... the chip is only about $2.50

ikari_01 wrote:How to inject a bit? I can decode the B Bus address + /PARD and drive an output connected to D4 but the PPU will still drive its own, won't it?
Does it come down to just hoping that the logic gate's output driver is strong enough to override the PPU output? Or is there a way to tell the PPU to tristate its data lines?

the logic gate's output driver is strong enough to override the PPU output.. this is how most of them work but it would be safer if you lift the pin. B Bus is a good idea (less address lines) you really only need to listen on the address lines for the $213f register then override D4.

EDIT: $213F seems to originate from S-PPU2 (U3, 5C78) pin 55 and 73 are both D4, these pins would be lifted and connected together.. the other soldering point could be U4 pin 16.. the PAL could then make D4 one or zero without bus conflicts

Hi
I've tested the lock version with a PAL snes (50/60 Hz switch already installed).
It works with all games besides SA-1 games.

Star Ocean works without graphic glitches, but the only SA-1 game I own (PGA Tour 96) doesn't star. It does work on a mint PAL SNES, so the cartidge isn't faulty.