Reverse Engineering the CIC

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Bregalad wrote:
tepples wrote:You could always open a Game Pak, cut pin 4 on the CIC, and then wire up two Game Paks' CICs in a lock/key configuration.
I think you'll need to wire the pin to VCC, not just cut it.
I intended that to be implicit in "wire up two CICs in lock/key". You cut pin 4 so that you can turn a key into a lock. Or you can just desolder the two CICs completely and put them in a breadboard.
And yeah, that is a great idea
Thanks.

Has anybody tried to photograph the insides of the Rabbit chip from Tengen games yet?
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

tepples wrote: I intended that to be implicit in "wire up two CICs in lock/key". You cut pin 4 so that you can turn a key into a lock. Or you can just desolder the two CICs completely and put them in a breadboard.
Disolver a 14 pin DIL chip on a PCB with solver on both sides without doing serious damage to the chip is nearly impossible.
Useless, lumbering half-wits don't scare us.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

Assuming "disolver" is supposed to be "desolder", you're wrong - you can most certainly desolder a 14-pin DIL chip from a double-sided board without damaging it IF you have the proper tools. With a decent desoldering iron, it's quite easy, though it's still doable with a spring-loaded solder-sucker (but slow) or even copper braid solder wick (though it'd take a LONG time).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
drk421
Posts: 329
Joined: Sun Nov 14, 2004 11:24 am
Contact:

Post by drk421 »

This works very well, I've done many carts:

http://www.radioshack.com/product/index ... Id=2062731
User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris »

Zack S wrote:I tried to get my parallel port to log the CIC in action but had no luck. Not sure what the problem is. I'm sure I'll get it right eventually. Or maybe I'll just do what Kevin suggested and break out a FPGA.
The problem is, you must reset the CIC for it to start working. If you don't, the CIC will get very hot! I dunno why this is, but it does. When working normally, the CIC does not get warm.
While messing with the CIC logger I was trying to make, I got an idea on another way to beat this system. When no cart is in the NES, the system isn't in reset the whole time. If we could disrupt the clock signal going to the Lock while the system is on, the lock won't be able to function and the NES will stay on. Ofcourse for this to work it would require messing the clock signal up enough to halt the MPU in the lock. But at the same time it can't damage the oscillator. Would this be possible?
That won't work. They use two separate inverters on the 74HCU04 to individually buffer CLK to each CIC.
I got it to work on the bread board pretty easily by just removing the clock signal wire. Anybody know a good way to stop the clock without damage? I have no problem with testing this on one of my nintendos, worst case scenario I have to remove the CIC altogether.
Just remove two CICs from two cartridges and use those... Though I am unclear if you can use the 6113 CICs back to back.

Speaking of this, I am kinda confused about why nintendo did this. The console *always* has a 3193 CIC in it (US console), while the carts have a 3193 (older) or 6113 (newer). I was wondering if the 6113 was a "key only" cost-reduced version or something... Even the very last versions of the front loader have the 3193 in it... So there must be some reason the 6113 is not usable as a lock.
/* this is a comment */
Zack S
Posts: 55
Joined: Mon Jan 02, 2006 12:45 am
Location: Orlando, FL

Post by Zack S »

kevtris wrote:The problem is, you must reset the CIC for it to start working. If you don't, the CIC will get very hot! I dunno why this is, but it does. When working normally, the CIC does not get warm.
I had a Reset signal going to the Lock and a Clock signal going to both CIC's. It's probably just something wrong with my code or I misswired something.
kevtris wrote:That won't work. They use two separate inverters on the 74HCU04 to individually buffer CLK to each CIC.
Guess it's back to trying to RE it.
kevtris wrote:Just remove two CICs from two cartridges and use those... Though I am unclear if you can use the 6113 CICs back to back.
That's excactlt what I did. Both of the CIC's are 6113's that I took out of game carts. They work fine back to back, at least they seem to. Without the key connected it produce the reset squarewave for the NES. With the key connected it kept the NES out of reset.
Bredalad wrote:Disolver a 14 pin DIL chip on a PCB with solver on both sides without doing serious damage to the chip is nearly impossible.
I used a 15$ desoldering iron to pull two CIC's off of PCB's, it took about a minute each. They worked fine in the breadboard so it didn't damage them. I usually do every 3rd pin or so, as opposed to just going down the line. That way each area of the chip has time to cool.
WhoaMan
Posts: 167
Joined: Sat Oct 02, 2004 12:07 pm

Post by WhoaMan »

has anyone logged what the lock and key do when they are not connected to each other? also... has anyone logged the response from the key when given only part of the sequence from the lock and vice versa?
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

The legal docs from the Nintendo vs Tengen case mentioned that Nintendo modified the lockout code in 1987 ("deleted some instructions"), maybe that's when they changed the part #s for the chip?
Zack S
Posts: 55
Joined: Mon Jan 02, 2006 12:45 am
Location: Orlando, FL

Post by Zack S »

WhoaMan wrote:has anyone logged what the lock and key do when they are not connected to each other? also... has anyone logged the response from the key when given only part of the sequence from the lock and vice versa?
I haven't yet but plan to as soon as I get my data logger working. I got an oscilliscope toady so that should help me figure out whats not working.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Zack S wrote:I got an oscilliscope toady so that should help me figure out whats not working.
Image
Oscilloscope toadies from Yoshi's Island 2: Reverse Engineering
Zack S
Posts: 55
Joined: Mon Jan 02, 2006 12:45 am
Location: Orlando, FL

Post by Zack S »

Quick update on my Parallel port data logger project. This will simply not work. I hooked up the O-scope and found that the parallel port can't go fast enough for the CIC. I'm guessing that the part of the chip depends on dynamic RAM, that isn't getting refreshed fast enough with the slow clock cycle I'm giving it.

I'm still learning to work with FPGA's so it could be some time before I make a data logger for it.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

I really doubt it has dynamic RAM in it. It could be some other asynchronous element in it like the older time-delay digital logic design that uses resistors and capacitor (RC) elements instead of clocked logic.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

Moved from NESdev to NES Hardware / CopyNES, as the CIC's functionality isn't really related to NES programming.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
teaguecl
Posts: 211
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl »

kevtris wrote:One interesting thing is that there are no runs shorter than 87 clocks I believe it was. In all my testing, one "clock" was made up of 4 clock cycles to the lockout chips.
I was thinking about this, comparing it to the patent document, and it doesn't make sense to me. According to the document there is the initial exchange, to seed the first random number (select the sequence) and then there is a transaction once per 4 clocks. I'll explain:
The 4Mhz clock is divided by 4 and split into four separate clocks in each of the four possible phases - and they are called phi1 through phi4. The patent suggests that on phi1 data is read in from the IO port. The next two cycles (phi2 and phi3) are used for "predetermined arithmetic operations". Then, on phi4 the data is output to IO. This sequence is repeated indefinately.
If I'm understanding this correctly, the data that is read in on phi1 as well as the data output in phi4 can't be anything other than 1 bit in size. It seems unlikely that the distribution would allow for runs of 87 cycles and longer without a single result of "1". Am I missing something here? Are the patent documents not quite accurate? I'm very suspicious of the explaination of the synchronization explained in there, it doesn't match the logic analyzer logs posted.

edit: I just realized that the "1" in the logs from Kev's tester are 3 clocks long.... which is a big clue. It indicates it's operating on the divided clocks and not on the original. I'm thinking there's some kind of "pipeline" going on here.
User avatar
teaguecl
Posts: 211
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl »

bunnyboy wrote:I put all my text files in a new directory at www.nesmuseum.com/10nes

nescicrom.txt - nes lockout rom dump, directly from rom array. Bits and bytes are interleaved, figuring out how it is actually arranged is part of the problem.
I had downloaded the photos taken by Nevitski with the microscope of the NES CIC, and started to decode them myself. I didn't make it all the way through - only 144 bytes in. However, comparing what I have against what you posted I found a discrepancy. Below I will paste the content of your nescicrom.txt, but will put an "X" in the location where I came up with a different value than you did. You have a "1" in that spot, and I read it as "0". In the 1152 bits that I decoded, we only differ by one bit... which means we're either reading it correctly, or at least consistantly incorrect.

1111100010111010001110100111111001111110010111000011101011101110
0110011110111111001101011111X11101100101011011010011010111011111

Unfortunately one bit difference out of over 1000 doesn't help us decode it at all. But it points out having several people decode it independently might help us reduce errors in it. If I get time, I'll try to keep decoding more.
Post Reply