nesdev.com
http://forums.nesdev.com/

What happened with SNES CIC reverse engineering?
http://forums.nesdev.com/viewtopic.php?f=12&t=5676
Page 1 of 17

Author:  magno [ Mon Oct 26, 2009 10:55 am ]
Post subject:  What happened with SNES CIC reverse engineering?

Hi!

Some years ago, the NES CIC reverse engineering project was succesful, and I thought it would be matter of days that its counterpart in the SNES was reversed-engineered too.

Has its ROM contents been dumped? Is it possible to simulate it? Is there any source code?

Thanks!

Author:  bunnyboy [ Mon Oct 26, 2009 1:53 pm ]
Post subject: 

Basically the NES CIC internals are still unknown, so the Ciclone does not help in creating an SNES version. There is no NES CIC source code, processor instruction set, or architecture. The Tengen clone is what gave up the secrets and they didn't make an SNES copy.

Author:  naI [ Mon Oct 26, 2009 4:46 pm ]
Post subject: 

bunnyboy wrote:
Basically the NES CIC internals are still unknown, so the Ciclone does not help in creating an SNES version.

Isn't it possible to analyze the behavior of the SNES CIC, so that it could be reproduced? I believe that would be called clean room reverse engineering. Otherwise, reproductions could always follow the pass-through design of Super Noah's Ark 3D to bypass the lockout.

Author:  neviksti [ Mon Oct 26, 2009 4:58 pm ]
Post subject: 

The NES and SNES CIC appear to use the same processor, and only the code was changed. The Tengen "version" of the NES CIC was easier to understand, and a couple dedicated people reverse engineered essentially all the transistor logic on the Tengen chip to figure out what it did... then they learned what the algorithm was from that.

We have "dumps" of the NES CIC roms, and SNES CIC roms. But since we don't know how the cpu works, this is not very useful.

HOWEVER, because we have the NES CIC rom, and the TENGEN rom + "instruction set". It may be possible for someone good with puzzles to figure out the NES instruction set just based on that. It is essentially a "rosetta stone" or "cryptogram" type puzzle.

If you want to tackle the "rosetta stone", all the info is already on these boards for that. Go for it! (please!)

What will probably help is the little of the NES CIC that I did trace out. It explains some details of the program counter in the chip (it uses a linear feedback shift register instead of just counting 0,1,2,3,4,5,etc.). That too is on the board here somewhere.

Author:  bunnyboy [ Mon Oct 26, 2009 5:47 pm ]
Post subject: 

The most important part was the Tengen chip had a debug (?) port that would show the internal status of the processor. No ROM was dumped. The Nintendo CIC doesn't have that so the same techniques don't apply. The behavior cannot be analyzed externally because it is a good cypher (if that is the right word).

Author:  neviksti [ Mon Oct 26, 2009 11:35 pm ]
Post subject: 

bunnyboy wrote:
The most important part was the Tengen chip had a debug (?) port that would show the internal status of the processor. No ROM was dumped.

The ROM was indeed "dumped", as it could be read easily from the images. (Without it, those Tengen program "disassemblies" would not be possible.)
The 'debug' port was useful for double checking, but ultimately it was the reverse engineering of the transistor logic (from IC images) that allowed the understanding of the instruction set.

The instruction set + the ROM gave us the whole program. This is what finally led to understanding of the algorithm, and the CIClone.

This same method can be applied to the SNES CIC (although it would take more work than the Tengen chip in my opinion), or the "rosetta stone" method could be used.

Author:  magno [ Sat Dec 19, 2009 4:25 am ]
Post subject: 

Could this be of any help in reverse-engineering the SNES CIC?

I found this link on Acmlm Board 2...

Author:  caitsith2 [ Sat Jan 16, 2010 4:27 am ]
Post subject: 

Any possibility we could get some clear zoomed-in shots of the rest of the CIC regions. As it turns out, some progress has been made on figuring things, out, including how the rom for the CIC is decoded. (Note, stained black areas of the rom, are actually 0 bits, and unstained areas are 1 bits.) Program counter is 7 bits long. Rom is 512 bytes, divided in 4 banks of 128 bytes.

Finally, the rom bits, both in the picture, and in the text, have to be vertically flipped. (If you don't vertically flip, then Row 0 is bottom row, Row 63 is top row.)

Each row, contains 8 bytes. These are ordered in the form of 8 x Bit 0, 8 x Bit 1, 8 x Bit 2 ... 8 x Bit 6, 8 x Bit 7. In each of the 8 x groups, refers to columns 0 to 7.

Now, Address 0 is row 0, column 0.
Address 1 is row 1 column 0.
Addrss 31 is row 31 column 0.
Address 32 is row 0 column 1.
Address 63 is row 31 column 1.
Address 127 is row 31 column 3.
Address 128 is row 32 column 0.
Address 255 is row 63 column 3.
Address 256 is row 0 column 4.
Address 383 is row 31 column 7.
Address 384 is row 32 column 4.
Address 511 is row 63 column 7.

This is how the 64 x 64 bit rom layout is decoded.

Now, program counter, is not linear. Instead, it goes 00, 40, 60, 70, 78, 7C, 7E, 3F, 5F... This happens in the form of high bit of Next PC is the xnor of the lower 2 bits of current PC, and the remaining bits of next PC is current PC >>= 1. PC of 7F has a next PC of 7F.

All of this was figured out by segher, one of the few that hangs out on IRC.

Author:  tepples [ Sat Jan 16, 2010 8:13 am ]
Post subject: 

caitsith2 wrote:
Now, program counter, is not linear. Instead, it goes 00, 40, 60, 70, 78, 7C, 7E, 3F, 5F... This happens in the form of high bit of Next PC is the xnor of the lower 2 bits of current PC, and the remaining bits of next PC is current PC >>= 1. PC of 7F has a next PC of 7F.

In other words, an LFSR program counter. But of course, this would work only in a pure Harvard architecture, not the von Neumann architecture seen in an NES or the overall von Neumann architecture with Harvard implementation (often as a separate instruction cache) seen in modern CPUs.

Author:  segher [ Sat Jan 16, 2010 10:01 am ]
Post subject: 

> In other words, an LFSR program counter.

No, it's not.

> But of course, this would work only in a pure Harvard architecture, not the von Neumann architecture seen in an NES or the overall von Neumann architecture with Harvard implementation (often as a separate instruction cache) seen in modern CPUs.

It is neither Harvard architecture nor Von Neumann architecture.

Quoting wackypedia doesn't make you look smart, btw; quite the opposite.


I'll post more when I'm ready for it; caitsith jumped the gun a bit there :-(

Author:  tepples [ Sat Jan 16, 2010 10:20 am ]
Post subject: 

segher wrote:
Quote:
Quote:
high bit of Next PC is the xnor of the lower 2 bits of current PC, and the remaining bits of next PC is current PC >>= 1.

In other words, an LFSR program counter.

No, it's not.

Then please enlighten me: What is the difference between "high bit of Next [value] is the xnor of the lower 2 bits of current value, and the remaining bits of next [value] is current [value] >>= 1" and "step to compute the next state of a linear feedback shift register"?

Author:  segher [ Sat Jan 16, 2010 11:14 am ]
Post subject: 

> Then please enlighten me

Hint: the fixed point of an LFSR is 0, and that is the start address here.

The correct name for this kind of thing is "polynomial counter".

Author:  tepples [ Sat Jan 16, 2010 12:19 pm ]
Post subject: 

Tomayto, tomahto. It appears we're hitting Layne's Law of Debate, and I'd like to get this point of terminology out of the way now, so that once you and caitsith have something to show, we know how to talk about it.

XOR polynomial counters have all 0's as their fixed point; XNOR polynomial counters have all 1's. They generate the same sequence, only inverted. I'd like to see a citation that distinguishes between the two and uses the term LFSR only for polynomial counters based on XOR.

Author:  caitsith2 [ Sat Jan 16, 2010 3:06 pm ]
Post subject: 

segher wrote:
I'll post more when I'm ready for it; caitsith jumped the gun a bit there :-(


Didn't mean to jump the gun there. Sorry about that.

Author:  byuu [ Sun Jan 17, 2010 1:43 am ]
Post subject: 

caitsith2 wrote:
Now, program counter, is not linear. Instead, it goes 00, 40, 60, 70, 78, 7C, 7E, 3F, 5F... This happens in the form of high bit of Next PC is the xnor of the lower 2 bits of current PC, and the remaining bits of next PC is current PC >>= 1. PC of 7F has a next PC of 7F.


Dear god why, why would anyone design hardware like this? ;_;

Is there a place one can obtain the SNES CIC ROM, and some logs of observed output from a real CIC? Perhaps we can start guessing the function of the various opcodes, now that the PC has been determined. A long shot, but worth a try.

Page 1 of 17 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/