nesdev.parodius.com

[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]

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.

[naI]

[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]

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]

[magno]

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

I found this link on Acmlm Board 2...

[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]

[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]

[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]

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]

[byuu]