What happened with SNES CIC reverse engineering?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
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!
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!
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.bunnyboy wrote:Basically the NES CIC internals are still unknown, so the Ciclone does not help in creating an SNES version.
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.
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.
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).
The ROM was indeed "dumped", as it could be read easily from the images. (Without it, those Tengen program "disassemblies" would not be possible.)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 '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.
Could this be of any help in reverse-engineering the SNES CIC?
I found this link on Acmlm Board 2...
I found this link on Acmlm Board 2...
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.
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.
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.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.
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 :-(
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 :-(
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 wrote:No, it's not.In other words, an LFSR program counter.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.
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.
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.
Dear god why, why would anyone design hardware like this? ;_;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.
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.