What happened with SNES CIC reverse engineering?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

What happened with SNES CIC reverse engineering?

Post by magno »

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!
bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy »

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.
ailI
Posts: 113
Joined: Fri Jun 26, 2009 4:58 pm

Post by ailI »

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.
neviksti
Posts: 203
Joined: Thu Jun 22, 2006 11:39 pm

Post by neviksti »

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.
bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy »

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).
neviksti
Posts: 203
Joined: Thu Jun 22, 2006 11:39 pm

Post by neviksti »

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.
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Post by magno »

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

I found this link on Acmlm Board 2...
caitsith2
Posts: 74
Joined: Mon May 26, 2008 11:41 pm

Post by caitsith2 »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
segher
Posts: 8
Joined: Sat Jan 16, 2010 9:54 am

Post by segher »

> 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 :-(
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

segher wrote:
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"?
segher
Posts: 8
Joined: Sat Jan 16, 2010 9:54 am

Post by segher »

> 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".
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
caitsith2
Posts: 74
Joined: Mon May 26, 2008 11:41 pm

Post by caitsith2 »

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.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Post by Near »

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.
Post Reply