nesdev.org

I know what I have done wrong now...and it sucks bigtime...Im almost embarassed to say it...

I always bend pin one down and solder to the chip beneath on pal snes. I also did that on the ntsc...and soldered 5v from another place...christ.. I fried my goddamn sram on two of my consoles... how insanely clumsy isn't that........

There. Finally. Thank you. Works.. <3

I've just installed the great super-cic chip mod and have just one question.
I installed into a pal snes and it works very well. Except that if I start a pal game in 50hz then switch to 60hz it will play for a few minutes then I get the 'wrong region' message. The same happens if I start an NTSC game in 60hz then change to 50hz (although I don't know why anyone would want to do that)
It works fine if played native or if the super-cic is set to auto mode. Do you think I have a short circuit somewhere?

Why would you change region at all? I think all games for the SNES had to have a region screen. Games probably won't utilize it if they play in both regions. But if the software sees a region change, it'll just error to avoide poblems. That's the only thing I can think of.

Sorry about my earlier post. I've gathered that the chip works flawlessly it just seems to be the region checks that some cartridges do are more frequent than others. (DKC for example checks all the time. Legend of Zelda never checks) Now all I need to do is modify the slot on my SNES to use US carts.

Sadly that's in-built protection in games, especially capcom games. I think there are tools that will remove the check, or you might find out some articles or somthing so you can hex-edit them out yourself.

gaijinsan wrote:DKC for example checks all the time

Really makes you want to ask the developers why. Were they afraid some clever person was going to hotswap the PPU while the system was running? So much time and effort into screwing over paying customers (for no fiscal advantage!!), and we just keep lining up to give them our money.

Unless it's some sort of raster timing thing where a kernel timed for one frequency will freeze on the other frequency.

gaijinsan wrote:DKC for example checks all the time.

Odd. I know there is a check right at boot, but if I start my PAL copy @ 50Hz and then flick to 60 when I see the Rare logo it will work happily @ 60 with no problem.

Now, Super Street Fighter 2. Thats another story...

AfaIk, according to the SNES dev manual states that there is a PPU register that states whether the console is operating in PAL or NTSC mode. I dare say there are other methods of detection but just polling that register would be a simple way of implementing region protection and just as easily patched out or bypassed. Datel produced a programmable import adapter that could do just that. Nothing a carefully crafted Game Genie couldn't do either.

A game could measure the length of vblank in CPU cycles. (Compare NES code to do just this.)

Or a game could measure vcount (OPVCT, $00213D) and crash if it gets or doesn't get a value in 263-311.

Or a game could make a DMA transfer schedule that works on the correct frequency but fails on the wrong frequency. Games that turn rendering off early/on late for more blanking time (I've read that Street Fighter II series is among them) might be more sensitive to such changes.

edit: any possibility you could release a version that can disable pair mode...with like..pushing reset twice or somthing?

powerpak and your mod gets out of sync

The PowerPak's version of the SuperCIC key does not support pair mode so it should never trigger it. Are you observing rapid switching between 50Hz and 60Hz?

Did you mod your PowerPak with your own SuperCIC key? Then be sure to tie pin 4 of the 12F629 high.

Hi ikari_01,

Maybe you're interest to look at it
http://www.emutalk.net/threads/53217-N6 ... y-Reversed

-Tomy

Hello,

I am looking at ways to emulate the CIC Roms for all cartridge regions for custom Cartridge. A potential project down the road would be an SNES cartridge similar to the MMC64 or other cartridge modules for C64. The idea of using an MMC/SD flash module like a disk cartridge or ROM image cart that loads into SNES RAM, a quasi-BIOS for handling the communication to the MMC/SD module and a custom CIC module for any region.

The idea is for some sort of auto-dectection mechanism for the internal console CIC and then respond with the proper code sequence and handle the proper handshake.

The SuperCIC seems like a clever solution but on the console side but I am looking at how to deal with it from the "cartridge" side for the custom cartridge.

Ikari, if you have an idea on how to work that solution, GREAT. Like to hear it and a possible solution.

An idea that I have is the cartridge would load a customized version of Contiki (a modified version of Contiki for SNES) which is a small OS system off of an MMC/SD card. When it is loaded into the SNES, I can then look to use RR-NET module I have via an interface module via the Expansion port on the bottom of the SNES.

The expansion port from a signal line by signal line practically identical to the Amiga "clock port".

I decided that the SNES PowerPak might be a good option for what I am looking at and has the whole setup already done. Only thing might be the potential option for IDE connection and possibly MMC/SD cards but I like the option currently as 4 GB should be amply sufficient for the job and we can reasonably emulate this unit on emulators for cross-development testing prior to hardware implementation.

This is exactly the kind of unit I would want to use to put an SNES version of a modified version of Contiki and focus my effort of dealing with SNES Expansion Port / Clock Port interfacing and emulation of my ethernet module I have over an SNES emulator via clockport for alpha-testing.