nesdev.org

Posted: **Sun Apr 11, 2010 12:36 am**

The S-DD1 will not decompress graphics by hooking DMA if the cic does not authenticate against the main unit; it will just dma the compressed data directly to vram, the same behavior many emulators did before the compression was figured out.

LN

Posted: **Sun Apr 11, 2010 2:56 am**

ikari_01 wrote:OK, I've updated the archive with a lock implementation.

Awesome work. However, in your lock source code, you may wish to make a correction.

Currently, it says.

Code: Select all

; ---------------------------------------------------------------------
;
;   pin configuration: (cartridge slot pin) [original 18-pin SMD lock CIC pin]
;
;                       ,---_---.
;      +5V (27,58) [18] |1     8| GND (5,36) [9]
;      CIC clk (56) [7] |2     7| CIC data i/o 0 (55) [1]
;   host reset out [10] |3     6| CIC data i/o 1 (24) [2]
; CIC lock reset in [8] |4     5| CIC slave reset out (25) [11]
;                       `-------'
;
;   pin 3 connected to PPU2 reset in
;   pin 4 connected to reset button
;   pin 5 connected to key CIC pin 7 (or clone CIC pin 5)
;   pin 6 connected to key CIC pin 1 (or clone CIC pin 7)
;   pin 7 connected to key CIC pin 2 (or clone CIC pin 6)

Change that to

Code: Select all

; ---------------------------------------------------------------------
;
;   pin configuration: (cartridge slot pin) [original 18-pin SMD lock CIC pin]
;
;                       ,---_---.
;      +5V (27,58) [18] |1     8| GND (5,36) [9]
;      CIC clk (56) [7] |2     7| CIC data i/o 0 (55) [1]
;   host reset out [10] |3     6| CIC data i/o 1 (24) [2]
; CIC lock reset in [8] |4     5| CIC slave reset out (25) [11]
;                       `-------'
;
;   pin 3 connected to PPU2 reset in
;   pin 4 connected to reset button
;   pin 5 connected to key CIC pin 7 (or clone CIC pin 5)
;   pin 6 connected to key CIC pin 1 (or clone CIC pin 6)
;   pin 7 connected to key CIC pin 2 (or clone CIC pin 7)

.

I checked things out, comparing lock/key source, and given that the chips are in perfect sync with each other, what you had before will cause input to be hooked up to input, and output to be hooked up to output, 100% of the time. Needless to say, both chips would hit their die routines very shortly after seed transmission, if hooked up as suggested in source.

Posted: **Sun Apr 11, 2010 10:27 am**

Really fantastic work ikari_01

I was just curious about the key implimentation - from what I gather it starts as one region, and if its incorrect it automatically switches to the other region when you reset/power cycle the console. My question is does it 'remember' the correct lock region setting, or do you need to reset/power cycle the console everytime you want to use it?

Also, would it be possible to make the key auto-detect the lock region (Like the lock implimentation) or is that not possible?

Lastly, now that we have a working SNES CIC clone how much harder would it be to make an N64 CIC clone? I guess a clone of the 6102/7101 would be most desirable, or the 6105/7105 if it could be used in conjuction with a 'universal boot emulator'.

Posted: **Sun Apr 11, 2010 11:00 am**

EDIT: confirmed working with Star Ocean! Don't have any other sensitive games to test.

caitsith2 wrote:
ikari_01 wrote:OK, I've updated the archive with a lock implementation.
Awesome work. However, in your lock source code, you may wish to make a correction.

Oops.

Corrected. Along with a small timing correction (begin seed transmission 1 cycle earlier). It did work before but now it's closer to the original.

Link83 wrote:My question is does it 'remember' the correct lock region setting

Yes.
Sadly it's not possible to have the key autodetect the lock region. There's no difference in how the lock appears to the key.

About the N64 stuff, I don't have the slightest.

I did not do the actual reverse engineering of the SNES CIC either.

Jeroen wrote:So any chance you could maybe make a write up on the basic functions of the code?

Um... Uhh... When I get around to it

(I know I should.)

Posted: **Wed Apr 14, 2010 1:42 am**

Star Ocean shots:

Before:

After:

Posted: **Wed Apr 14, 2010 5:23 am**

Thanks for the reply ikari_01

Great to see it running Star Ocean.

If I wanted to use the lock implimentation in my SNES console would it be best to completely remove the original CIC chip and connect the clone to the correct pads? Or should I just disable the original CIC (By turning it into a key) and then 'piggyback' the connections? Or would it work either way?

Also, you mentioned 'reverse engineering' would be required to make an N64 CIC clone, and I just wondered what information is actually needed? I only ask as I have already seen some pictures of a decapped N64 CIC chip a while ago, and there is also a dump available of the PIF ROM (The PIF-NUS chip is the 'lock' chip inside the N64 console, although it also handles the controllers, memory cards, etc as well which is why it can't just be disabled like the SNES lock chip) Although I am unsure if this is a dump of the CIC part, of the boot part of the PIF-NUS chip.

...I just thought it might be easier to make an N64 CIC clone now, especially since we now have a better understanding of how the CIC CPU works, and a working clone thanks to yourself.

Thanks again for your help

Posted: **Wed Apr 14, 2010 6:15 am**

I think it should be enough to do the usual mod (Pin 4 -> GND) and additionally disconnect pin 8 from the PCB and tie it to GND, too. (And then connect the PIC to the PCB "pin 8", not the CIC pin 8.)
I didn't do this yet, just the usual Pin 4 mod with the PIC soldered on top. With this the SNES refuses to boot directly after power up - I have to push reset once. I think the additional pin 8 mod should fix this but I haven't tried yet. Note that this does NOT work! I just tested it. It just shows the same behavior or does not come out of reset at all.

What I do know now is that if you remove the original CIC completely you'll need a pull-down resistor between CIC pin 8 / PIC pin 4 and GND. 10kΩ will do. There's a debouncing capacitor connected to the reset button that seems to take forever to discharge when the PIC is used instead of the CIC.

I'll try to watch an N64 do its CIC stuff. Can you point me at the ROM dump?
The die photos I found at http://retroactive.be/mirror/n64/cic_die/ are nice but the ROMs are unreadable. Are there any others?

Posted: **Thu Apr 15, 2010 12:50 pm**

I will probably just remove the original CIC entirely, as it seems like there would be less complications/wires that way

For the 10kΩ resistor does it matter if I use metal film or carbon film, or if its 1/4W or 1/2W etc? Also, is it possible the PIC code can be changed to remove the need for a resistor? (I'm guessing no, but just wanted to check)

Regarding the N64 CIC, those are the only pictures I know of showing a decapped N64 CIC chip. I know someone called 'MooglyGuy' was planning to send all the N64 CIC's off to be decapped in June 2008:-
http://moogle-tech.com/blog/?p=62
But I have not heard anything about it since

The PIF-NUS dump is called 'pifdata.bin' and I believe it was decapped/dumped from an Aleck64 board (Aleck64 is an arcade system that was based on the Nintendo 64 and used the same PIF-NUS chip and a CIC chip) I am not sure if its ok to post a download link here, so I have sent you a PM with a link to download the file, hope thats ok. Please note though that I dont know if its a dump of the CIC part or the boot part of the PIF-NUS chip.

Posted: **Thu Apr 15, 2010 11:57 pm**

The properties of the resistor don't really matter. Sadly the code cannot be modified so no resistor would be needed. The PIC only has internal pull-ups, no pull-downs.

I'm planning to modify the code further. As we established the lock PIC can detect the key CIC's (== game cartridge's) region. The lock PIC is also located inside the SNES. What else is located inside the SNES?
Right, the 50/60Hz pins of the PPUs.

(this will require a larger PIC though, presumably a 16F630)

Posted: **Fri Apr 16, 2010 11:46 pm**

ikari_01 wrote:I'll try to watch an N64 do its CIC stuff. Can you point me at the ROM dump?
The die photos I found at http://retroactive.be/mirror/n64/cic_die/ are nice but the ROMs are unreadable. Are there any others?

i have two disks marked "N64 CIC" i don't have a drive plugged in tho..
definitely have more... i'll check them in awhile when i reboot my computer.

EDIT: I checked the photos and they aren't good enough

i'm only just getting started really....
first i started noting the 'nescic' correct me if i'm wrong but i think it's 6193?
but i switched to noting the '3195' file when i ran into a problem (when i get time i'll try it again)
also working on notes for the snes d411 file

should be simple enough to map out the differences in timing

Posted: **Sat Apr 17, 2010 2:10 am**

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.

http://hackmii.com/2010/01/the-weird-an ... mment-6016
This guy had the instruction set mapped out on an excel sheet and made a screenshot of it. However the image server seems to be down.
I remember the mystery instruction being described as "XXL" in that screenshot, "exchange X and BL". May or may not be correct.

Posted: **Sat Apr 17, 2010 2:14 am**

ikari_01 wrote:I think it should be enough to do the usual mod (Pin 4 -> GND) and additionally disconnect pin 8 from the PCB and tie it to GND, too. (And then connect the PIC to the PCB "pin 8", not the CIC pin 8.)
I didn't do this yet, just the usual Pin 4 mod with the PIC soldered on top. With this the SNES refuses to boot directly after power up - I have to push reset once. I think the additional pin 8 mod should fix this but I haven't tried yet. Note that this does NOT work! I just tested it. It just shows the same behavior or does not come out of reset at all.

ok, about that:

If you want to leave the original CIC in place:
- separate pins 1, 2, 10, and 11 from the mainboard. They are pretty easy to reach as they are located at the edges of the chip and are direct neighbors.
An existing pin 4 mod can be left unchanged. A non-existing pin 4 mod can be left unchanged.

If you unsolder the original CIC:
- place a 10kΩ resistor from former CIC pin 8 to GND.

Posted: **Sat Apr 17, 2010 1:36 pm**

caitsith2 wrote:The Lock sends its 4 bit random value to the key. Bit 0 of that random value is going to already be known when the key sends it back. Next, Bit 0 of the next value, also sent by the key, effectively specifies the region.

so the 8th bit coming from the key should tell the region for the snes key?

ikari_01 wrote:I'm planning to modify the code further. As we established the lock PIC can detect the key CIC's (== game cartridge's) region. The lock PIC is also located inside the SNES. What else is located inside the SNES?
Right, the 50/60Hz pins of the PPUs. Very Happy
(this will require a larger PIC though, presumably a 16F630)

the snes 'rainbow mod' got me thinking about doing this.

Posted: **Sat Apr 17, 2010 3:25 pm**

No, actually the 2nd bit: The CICs operate on 4-bit values and only the LSBs of each are transceived anyway.

The rainbow mod is cool! Didn't know something like that existed.

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.

Posted: **Sat Apr 17, 2010 3:48 pm**

If a replacement lock CIC autoswitches to 60 Hz after booting a PAL cartridge, can this be made an option?

Autoswitch to 60 Hz might leave some games' cut scenes out of sync with the music unless the music player puts the current song position on the APU ports. A few games do region detection more often because their engines depend on the region, though this is less common on the Super NES due to its scanline-counting interrupts and blast processing, but I imagine there are still a few games that need all the vblank time.

nesdev.org

What happened with SNES CIC reverse engineering?