nesdev.org

Posted: **Wed Apr 28, 2010 4:42 am**

Yes, in the meantime I got the same feedback from another guy via mail.
Thought a bit about it but that's it so far.

Did you remove the CIC (+added the pulldown) or did you just lift the pins? I seriously need to get an SA-1 game...

I made a minor timing change in the meantime (I was one cycle late with sending the data pulses). Can you redownload the zip file and test it again?

Posted: **Wed Apr 28, 2010 7:22 am**

Very strange. I tested the lock version (with the older code dating from April 11, 19:59) just minutes ago. And ... Everything works great, including SA-1 games!

ikari_01, you're a genius!!! 8)

I used a 1-chip PAL SNES, removed the original CIC (F413B) completely, and added the pulldown resistor. I programmed the 12F629 using a Willem programmer and leaving all of the custom settings alone. When asked what OSCCAL value to use, I read and wrote back the original value, not the one in the hex file.

Here's a list of special chip games I then threw at the SNES. All did start, though some of them soon prompted me with a 50/60 Hz error message (I haven't added a frequency switch to the console yet).

Kirby's Dreamland 3 (US, which wouldn't run on anything but an original US SNES or Super Famicom before; if I've ever loved seeing a "This game is not designed ..." message in my life, I can honestly say this was the time! )
Kirby Super Star (US; "This game is not designed ...")
Marvelous (Japanese)
PGA Tour '96 (PAL)
Star Ocean (Japanese, two different cartridges tested)
Street Fighter Alpha 2 (PAL)
Street Fighter Alpha 2 (US; "This game is not designed ...")
Super Mario RPG (Japanese, two different cartridges tested, one of which wouldn't run on anything but an original Super Famicom or US SNES before)

What I haven't tried yet is to play one of the SA-1 games for a longer period of time to see whether the SA-1 reliably and permanently accepts the PIC as its fake CIC counterpart.

Hura, you might want to check your S-CLK (if applicable - but I guess your SNES has this chip as you've already a 50/60 Hz switch installed and thus, your console is probably a 2-PPU revision one). If one of its pins has been lifted (as shown on the picture at the bottom of this page), then you might try and reattach it to the mainboard to see whether this has any impact on PGA Tour '96. Good luck!

ikari_01, I'm going to try your new code, too. Maybe I can observe any difference (but I hope not) ...

Posted: **Wed Apr 28, 2010 10:38 am**

Well, that's good to hear.

So maybe the original CIC has to be removed after all? I'm looking forward to more reports.

The OSCCAL value doesn't matter btw, the internal oscillator is not used.

I recommend using the newer firmware anyway since its timing is more accurate. Might be more reliable under circumstances yet unknown.

Posted: **Wed Apr 28, 2010 11:17 am**

i meant to point out that the nes cic has some timing difference between 319x and 611x

if i remember correctly
lock 319x and key 611x (normal mode) works
lock 319x and key 319x (lock testing lock) works
lock 611x and key 611x (key testing key) works
lock 611x and key 319x doesn't work

if you look at the copyright records
for nes TX0001945426, V2182P102 and TX0003812529, TX0003812530 for snes
the second record for both systems are code updates

for perfect timing you could hook up two keys or locks and compare the outputs
parallel port is good enough you just need to slow it down a little
my circuit divides the clock 2 to 4096 times so i can test

not sure about PIC's but my AVR's runs 0-16mhz and i've run a nes cic at about 245hz

just encase anyone is interested n64
TX0004448359 (N64 security program NTSC version)

and these might be related.. they have part numbers but are custom chips
V3415D609, V3388P134, V3353P347, V3166P259, V3166P258, V3159P533, V3159P530

i'm slowly getting done while trying to optimize and arrange the code.. same problem with the reset pin being backwards. using interrupt 0.. basically doing one function rewrite at a time.. originally i was translating... tho it's possible to translate it would of turned out ugly and i wouldn't learn a thing. it needs to work for snes and nes anyway

Posted: **Wed Apr 28, 2010 11:53 am**

jims cool wrote: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

What you seem to be referring to is D4 of the VRAM data bus. However I need to connect to the CPU data bus, which is connected to both PPUs, the S-CPU, S-WRAM, S-SMP, the cartridge slot, and the EXT port. As the verification code is executed by S-CPU, its D4 pin would have to be isolated whenever $3f is read on the B bus. Gonna look into that later though.

Posted: **Wed Apr 28, 2010 1:50 pm**

orwannon wrote:ikari_01, I'm going to try your new code, too. Maybe I can observe any difference (but I hope not) ...

For the record, the new revision works just as great as the old one. Thank you so much, ikari_01!

Posted: **Wed Apr 28, 2010 2:27 pm**

ikari_01 wrote:What you seem to be referring to is D4 of the VRAM data bus. However I need to connect to the CPU data bus, which is connected to both PPUs, the S-CPU, S-WRAM, S-SMP, the cartridge slot, and the EXT port. As the verification code is executed by S-CPU, its D4 pin would have to be isolated whenever $3f is read on the B bus. Gonna look into that later though.

oops i read the schematic wrong

D4 is pin 11 sorry lol
but that's assuming that the register gets it's value from ppu2
so you could lift that pin and all the other connections could be on the port
including the other D4 connection

with one pin the PIC could select D4 1 or 0 (for that register)

i don't know if you need to check for read/write it's a read only register.. unless is has something to do with the B bus?

Posted: **Wed Apr 28, 2010 11:01 pm**

I doubt that $213f is the only register that enables PPU2. If you just lift D4 of PPU2 then all reads and writes to all registers that concern PPU2 will be "missing" bit 4.

The A and B buses are address buses. There is only one shared data bus. And /PARD has to be taken into concern. The address can stay on the bus for much longer than the actual read pulse (as long as no further B bus access takes place) so before and after the actual read you'd be hogging the data bus. Instant crash

Posted: **Fri Apr 30, 2010 12:00 pm**

we keep misunderstanding each other
my idea is lift D4 on PPU2
connect a wire to D4 on the cart slot (a simple connection spot)

the PAL could then connect the two points for everything but the one register.. now every time the address bus points to that register it's gonna read it.. i don't know much about the B-bus but i'm assuming it works the same way (only 8-bit). a third pin could be used to tell the PAL if we want D4 to be a 1 or 0..

on the cart adapter they have 12 address lines and 1 data (D4)
when the address it pointing to the register they put the signal they want on D4 and that's all

also i didn't say $213f enable/disable PPU2...
i said the register and it's value seem to come from it..
if you disconnect D4 on PPU2 when the address is right
set/clear D4 on the CPU
then reconnect D4 when the address changes it should work

PALs switch very fast and this is the kind of thing they are made for
inverting or not inverting D4 is an idea that might make it faster (instead of disconnecting/reconnecting)
so the input from the PIC/AVR

Posted: **Fri Apr 30, 2010 12:57 pm**

Interesting

Seems like we're talking about the same thing while thinking we're talking about completely different things

so:

Code: Select all

              ,-----.
 < CPU_D4 >---|     |
  | /PARD >---| e.g.|---< PPU2_D4 >
  | /PAWR >---| PAL |
| PA[7:0] >===|     |
 | PIC_D4 >---|     |
              `-----'

wire IS_213F = PA[7:0]==8'h3f;
assign CPU_D4 = !PARD ? (IS_213F ? PIC_D4 : PPU2_D4) : 1'bZ;
assign PPU2_D4 = !PAWR ? CPU_D4 : 1'bZ;

like this, right?

Posted: **Mon May 03, 2010 5:45 pm**

yup exactly!

still not sure about /PARD and /PAWR
i'll need to look into it more but i know they don't check R/W on the Bus - A
if it's truly a read only register we don't need them because every time the register pops up on the address bus it's read

my guess is 1st the cpu clears R/W, then sets the address, then sets a R/W
so after a read or write is set it's already to go (or going)
like this

cpu clear read/write
set address to something ; CPU D4 = PPU2 D4
cpu set read

cpu clear read/write
set address to $213f ; CPU D4 = PIC/AVR BIT
cpu set read

cpu clear read/write
set address to something ; CPU D4 = PPU2 D4
cpu set write

so...
CPU_D4=(address==register)?MCU_D4:PPU2_D4

CPU_D4 from cart slot
MCU_D4 from AVR/PIC
PPU_D4 from lifted pin on ppu2

unless read and write are set at the same time as the address even then it's just another two bits to check if it's read only

EDIT:

Segher wrote:Only “sc” and “rc” modify the carry flag, no other instructions do.

i just want to confirm what i've read about the carry bit. 'sc' sets the carry bit and 'rc' clears the carry bit but no other instructions modify its value? i just rewrote the mangle loop... for parts with the carry flag set i just added one

Code: Select all

	lds REGC, Y			; A = A + M(x0001) + C
	add REGA, REGC
	inc REGA

EDIT2: alright i was being dumb.. lol

ikari_01 wrote: Some hints:
http://hackmii.com/2010/01/the-weird-an ... mment-6000
I was not aware of the carry flag behavior and expected it to be changed on any arithmetic operation. Not so.

i checked out your (ikari's) d411 scramble too. segher should note that on his hardware description...
the avr has more then enough time for the mangle loop.. i'm trying for a load seed loop now.
got a little more then 9 cycles per nibble/byte and i might load two bytes in parallel i donno lol

Posted: **Sun May 09, 2010 3:24 pm**

Ah, that source code has a little flaw actually.

Lines 97-103 suggest that the streams are swapped but in reality the CIC just swaps its i/o pins. So sometimes the lock stream is output on pin 1 while the key stream is expected on pin 2, and vice versa. When monitoring one fixed pin sometimes you'll see the output of the key (going into the input of the lock) and sometimes the output of the lock (going into the input of the key).

The program outputs the correct streams but you can easily get the impression that the first line of a line pair is always the key stream and the second line is always the lock stream, which is not correct. The two lines of data actually correspond to one of the i/o pins each, with no indication of the direction.

Anyway, enter SuperCIC:

lock allows the region to be set+saved by holding the reset button.
region can be set to 50Hz, 60Hz, or autodetect based on key CIC.
selected region is indicated by LED color (uses a dual LED).
has a ~9s timeout before switching from detected to forced region to trick most games. This feature can be enabled/disabled using a configuration pin on the lock.
"D4" output that reflects the detected key CIC region, or selected user mode if no key detected. Can be used for patching the $213f register using additional hardware.
with a corresponding SuperCIC key allows 50/60Hz and D4 to be set from the cartridge slot (e.g. by an additional MCU) using CIC data i/o pins ("SuperCIC pair mode"). This mode can be enabled/disabled using a configuration pin on the key.
documentation has become quite massive (see supercic-lock.asm)

The lock uses a PIC 16F630 while the key remains a 12F629.
Enjoy.

Posted: **Mon May 10, 2010 7:04 am**

Wow, thats really fantastic ikari_01

Thanks so much for all your hard work.

Out of curiousity, are you still considering making a NES/N64 CIC clone? Hope you dont mind me asking

Posted: **Mon May 10, 2010 7:26 am**

Not really atm. I think jims cool will have the NES covered.

N64 is out of reach at the moment as the data looks completely different from what the NES+SNES CICs do, and I think it would certainly be more complicated given the fact that the CIC status can somehow be queried by software.

Posted: **Mon May 10, 2010 1:39 pm**

Klaus Wolf of Wolfsoft wrote up a blog post with some instructions and nice macro photos of his mod: http://blog.wolfsoft.de/?p=603

He chose to remove the CIC but I can confirm it works with the original CIC in place and pins 1,2,10 and 11 lifted as well. 8)

nesdev.org

What happened with SNES CIC reverse engineering?