Reverse Engineering the CIC

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

Moderators: B00daW, Moderators

User avatar
Bregalad
Posts: 7793
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sun Jan 07, 2007 2:21 am

That *could* work, because the message in question would just flicker on the screen since the game will boot for about 1 sec before reset. However, if the console has a defeated CIC or has no CIC at all (playing on a famiclone with 72-pins slot or a toploader NES), then the game will refuse to boot due to faliure when communicating with the NES CIC, so you're adding even more stupid copy protection instead of defeating it.

EDIT : I definitely think a power-on reset is a better idea, as long as it still work when no CIC is present in the console. The MMC1 should have an internal power-on reset, since it has a known initial state and it is not connected to the CIC reset line. I don't know about the other mappers, but I guess at least MMC1 and MMC5 aslo have an intenral power-on reset.
Life is complex: it has both real and imaginary components.

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

Post by tepples » Sun Jan 07, 2007 9:32 am

Then the key will need to indicate a CIC failure due to no communications (either a dirty connector or a toploader) the same way as as a CIC success and let the program on the CPU sort it out. A program can detect the lock-generated soft resets by seeing if resets have happened while the program's copyright screen is still displayed; at least Wisdom Tree games do this while searching for a reset pattern to check against. We'd need one pin for whether a reset button press would change the region.

dvdmth
Posts: 354
Joined: Wed Mar 22, 2006 8:00 am

Post by dvdmth » Sun Jan 07, 2007 1:05 pm

I take back my suggestion. I see a number of possible faults with the status reporting mechanism as I suggested (e.g. what happens if the CIC in the NES is disabled via pin 4?). I'm not sure if there's any reliable way to utilize these extra pins as outputs for any purpose, since there's no guarantee the chip will even be functional (in a top loader for instance).

Someone I talked to last night did not like the idea of a lockout clone that can work in any region. For one thing, there isn't much value in it since you have to travel from one part of the world to another with the same cartridge before it can have any value over a region-specific CIC. It also complicates usage (particularly for the many people out there who just stick in the cart and start playing without looking at any enclosed documentation). Finally, it requires the game code to detect NTSC vs. PAL and adjust timings of raster effects and/or sound code to match the region.

After having this discussion, I now believe that it is much better for the region select to be hardwired, through the two extra pins on the clone, as was suggested earlier. The region select could be controlled through switches of some kind on the board, if it is desirable to be able to change the region later with minimal effort, but the selection should be made prior to inserting the cart in the NES.

User avatar
Bregalad
Posts: 7793
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sun Jan 07, 2007 1:22 pm

I think it is possible to make games compatible with PAL and NTSC as long as their don't use any raster effect (just simple screen-split using sprite zero hit), and as long as noone cares too much about the music being played at a slightly different pitch and speed. And I don't see much issue for the user as long as the region is stored in EEPROM, he just haves to press reset a few times and I think he'll do it by himself without having to read any doccumentation.
I think it'd be a good idea to have the system being able to be either NTSC only or PAL only (either by using input pins or just by placing a different code inside the PIC). NTSC only means it just have to behave like any U.S. lockout chip (3193). PAL only means it have to alternate between A and B regions (3197 and 3195, possibly 3196).
Life is complex: it has both real and imaginary components.

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

Post by tepples » Sun Jan 07, 2007 1:30 pm

dvdmth wrote:Someone I talked to last night did not like the idea of a lockout clone that can work in any region. For one thing, there isn't much value in it since you have to travel from one part of the world to another with the same cartridge before it can have any value over a region-specific CIC.
That or your cartridge has to travel from the factory to the buyer's part of the world. Or the buyer has to travel to a different part of Europe, which was segmented into separate regions. UK and Italy were in Mattel's "A" market with Australia, and everywhere else in Europe was in the "B" market.
It also complicates usage (particularly for the many people out there who just stick in the cart and start playing without looking at any enclosed documentation).
That's why a lot of newer consumer products have a warning label taped over their edge connectors or power connectors.
Finally, it requires the game code to detect NTSC vs. PAL and adjust timings of raster effects and/or sound code to match the region.
Unless it's for the different NES regions in different parts of Europe. Besides, some games developed for NTSC could be made PAL tolerant with PPU-timed mappers (like MMC3) for raster effects. Speed is easy to fix: run two world updates in every fifth frame if it detects a PAL machine.

User avatar
Bregalad
Posts: 7793
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sun Jan 07, 2007 2:19 pm

There is even commercial games that have an identical PRG from the USA to PAL regions, not having even the music speed or title screen altered. Kid Icarus is an example, being the only cart I have discovered with the PRGROM marked "NES-KI-PRG" instead of "PAL-XX-PRG".
Life is complex: it has both real and imaginary components.

dvdmth
Posts: 354
Joined: Wed Mar 22, 2006 8:00 am

Post by dvdmth » Sun Jan 07, 2007 5:09 pm

Is it possible to program the PIC to initialize RAM during the first 15-bit seed transfer, as opposed to earlier? If it can be written that way, then it should be possible to make a lockout clone that works in all parts of Europe without any trial and error. The trick is to take advantage of the different timing between the two regions. The 3197 has an extra delay of 5 instruction cycles before the first 4-bit transfer takes place. For all 4-bit combinations except zero, this is enough to determine which region is appropriate long before the first transmission.

The catch is if the 4-bit transfer is all zero. In this situation, you must wait until the first bit is transferred for the 15-bit transaction. This bit is set to 1 from lock to key and 0 from key to lock. Thus, by seeing when the bit is set to 1, you can determine which region you're in before you need to send a 1 to the lock. However, you'll need to finish RAM initialization while this 15-bit transfer is underway, which might be tricky to pull off. If it can be done, however, then I see no reason why a clone can be set up to work in all parts of Europe without any special end-user operation.

It's not possible, however, to distinguish between the 3193 and 3195 with this technique. I still think the best way to handle this is to have the region selected in hardware (possibly through a switch the user can access) instead of requiring the user to train the chip by pressing Reset if the screen blinks. In an ideal world, user would've replaced their NES cart connectors and kept their cartridges clean, but in the real world this isn't the case, and it can be intimidating if a user has to deal with a blinking screen under circumstances not caused by a bad connection.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Mon Jan 08, 2007 6:55 am

And I don't see much issue for the user as long as the region is stored in EEPROM, he just haves to press reset a few times and I think he'll do it by himself without having to read any doccumentation.
Remember, the proposed design so far can have the current region changed without any rewiring, so if you're shipping something to region X, you can put the lockout chip into region X before sending it. If the user never uses it outside region X, then it is as if it were hard-wired all along. The automatic region scanning only occurs if the user tries to use it in another region; if there were no automatic, then it wouldn't work at all in this case.

dvdmth
Posts: 354
Joined: Wed Mar 22, 2006 8:00 am

Post by dvdmth » Mon Jan 08, 2007 8:47 am

blargg wrote:Remember, the proposed design so far can have the current region changed without any rewiring, so if you're shipping something to region X, you can put the lockout chip into region X before sending it. If the user never uses it outside region X, then it is as if it were hard-wired all along. The automatic region scanning only occurs if the user tries to use it in another region; if there were no automatic, then it wouldn't work at all in this case.
I suppose that's all right - if the distributor has access to every CIC region and can perform the initialization prior to shipping (this contradicts the earlier point of a cart going directly from a factory to the consumer, but ah well).

Since everyone here seems convinced that a universal, auto-scanning CIC is best, I'll concede. It still would be nice if both European regions can be combined transparently as I described earlier, if for no other reason to reduce the number of region candidates for scanning. It would be particularly nice if the 3196 can be similarly combined with the 3193, to reduce the candidates down to only two (so at most one Reset press would be necessary), but we'll have to wait for the 3196 data, obviously, before reaching any conclusions.

User avatar
Bregalad
Posts: 7793
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Mon Jan 08, 2007 8:48 am

I think it would be pretty well to have a NTSC 3193 clone, and a PAL 3195/3196/3197 clone that would detect the region from the first seed gived. Since 3197 has only a single seed possible I think that will keep things simpler and I don't know if it's needed to emulate the 3696 at all, since it's very not common (asian countries uses famiclones). So just 3195/3197 in a chip would already be a good work.
Life is complex: it has both real and imaginary components.

dvdmth
Posts: 354
Joined: Wed Mar 22, 2006 8:00 am

Post by dvdmth » Mon Jan 08, 2007 11:12 am

Bregalad wrote:I think it would be pretty well to have a NTSC 3193 clone, and a PAL 3195/3196/3197 clone that would detect the region from the first seed gived. Since 3197 has only a single seed possible I think that will keep things simpler and I don't know if it's needed to emulate the 3696 at all, since it's very not common (asian countries uses famiclones). So just 3195/3197 in a chip would already be a good work.
The 3197 has 16 initial seeds just like the others. The original dump kevtris made only had 1 seed because the 3197's timing was different and his dumper didn't correctly interpret the 4-bit seed transfer. The fact that the 3197's timing is offset is why I believe it should be possible to support both the 3195 and the 3197 transparently in one chip.

Depending on the 3196's timing, it may or may not be possible to integrate it with the other region(s) in a transparent fashion. I'm hopeful that it can be, but until data is available there's no way to know.

PDP-13
Posts: 21
Joined: Fri Nov 11, 2005 11:02 am

Post by PDP-13 » Tue Jan 09, 2007 5:24 pm

Can those 2 PIC pins be used as input?

Would there be enough time between resets for the NES CPU to be initialized enough to read the contoller status?

And send that to the PIC?

Instead of a 'auto-switch' method.

Just print:

For Region XYZ Hold A when powering up.
For Region ABC Hold B when powering up.
For Auto mode Hold Select

You could even put that text message in there
(1 second is not very long to read, anyhow)

dvdmth
Posts: 354
Joined: Wed Mar 22, 2006 8:00 am

Post by dvdmth » Tue Jan 09, 2007 6:08 pm

I don't think that would be possible. Bear in mind that the communication between the lock and key begins before the CPU's /RESET line is released, and once an error occurs the screen blinks on and off indefinitely until the Reset button is pressed (i.e. no second chances).

User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris » Tue Jan 16, 2007 7:42 pm

.
Last edited by kevtris on Sat Mar 06, 2010 12:26 pm, edited 1 time in total.
/* this is a comment */

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

Post by tepples » Tue Jan 16, 2007 7:53 pm

dvdmth wrote:I don't think that would be possible. Bear in mind that the communication between the lock and key begins before the CPU's /RESET line is released, and once an error occurs the screen blinks on and off indefinitely until the Reset button is pressed (i.e. no second chances).
But the CPU does run while the screen is blinking. It's long enough to detect the PPU speed, read the controllers, and pass on what region to try next time.

Autodetect 60 Hz timing: Ignore buttons and try NTSC
Autodetect 50 Hz timing, holding A: Try PAL-A
Autodetect 50 Hz timing, holding B: Try PAL-B

Post Reply