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!
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.
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.
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.
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).
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.
Could
this be of any help in reverse-engineering the SNES CIC?
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.
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.
> 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 :-(
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"?
> 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".
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.
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.
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.
caitsith2 wrote:
All of this was figured out by segher, one of the few that hangs out on IRC.
Did he reproduce this himself by looking at the IC chip, or is this just based on my circuit tracing here (and other circuit tracing comments in other threads)?
http://nesdev.com/bbs/viewtopi ... 3119#43119It sounds like he traced out the first three PC cells? (And possibly the "reset" state?) Both of which I did not get around to doing yet. That would be great.
Breaking the rom into 'quadrants' instead of just the usual row address / column address are high/low (or vice versa) was discussed as well. But I'd have to reread all the threads and/or find the rest of my notes to see if I got the same exact address decoding as you wrote there.
As an aside, the earlier CICs had 12 "columns" instead of just 8.
segher wrote:
> 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".
I have to agree with Tepples here.
We've been calling this a LFSR from the beginning of that revelation about the PC, and while I feel the term is correct, even if you do not it should be clear what was meant by it. We're all friendly here.
If there is some information we are lacking by all means point it out, but please don't create semantic barriers and then not provide clarifying information when dismissing what others say. OK? Let's all work together. The atmosphere was much more congenial when everyone worked on the Tengen chip.
segher wrote:
It is neither Harvard architecture nor Von Neumann architecture.
Quoting wackypedia doesn't make you look smart, btw; quite the opposite.
How is it not Harvard?
The program code is even a different bit width than the ram, and the ROM addressing can come ONLY from the PC. Those two facts seem to require it to be Harvard to me.
Again, please don't be dismissive without explaining why. Just disagreeing and then taking a crack at tepples is not helpful.
> Did he reproduce this himself by looking at the IC chip,
I couldn't get any good photos of the chip, I would love to see some.
I reverse engineered this all from just the bits in the rom, and a lot of
datasheet/patent archeology. Couldn't find the exact cpu fwiw.
> or is this just based on my circuit tracing here (and other circuit tracing
> comments in other threads)?
>
http://nesdev.com/bbs/viewtopi ... 3119#43119
No, interesting though. For some reason I totally missed that thread.
> It sounds like he traced out the first three PC cells? (And possibly the
> "reset" state?) Both of which I did not get around to doing yet.
> That would be great.
I messed around with permuting and inverting the address bits until I
got something that looked resonable. Then I figured out the jump/call/ret
opcodes, which then allowed me to fine-tune the address decoding (jumps
have to go somewhere reasonable).
Figuring out the rest of the opcodes is harder: I did not even know what
registers there are! So reversing the opcodes and reversing the cpu has
to be done in parallel.
Right now I have one opcode left to do. It is used only in the "nescic"
rom, and only once.
> As an aside, the earlier CICs had 12 "columns" instead of just 8.
Those are _earlier_?! The code in the "12-bit cic" is much nicer, smaller
code, which does pretty much the same thing.
It does make sense though: it has a few opcodes swapped, while "nescic"
and "d411" are the same.
> I have to agree with Tepples here.
> We've been calling this a LFSR from the beginning
That doesn't make it right though ;-)
An LFSR is a _linear feedback_ shift register. XNOR isn't linear.
It matters a lot mathematically, and e.g. when you try to brute-force
this stuff by trying out all LFSRs and giving each a score. I ended
up with the rom backwards, since the complement of the PC counter
_is_ an LFSR of course (there is an even number of taps).
> We're all friendly here.
I hope so, so am I, I hope.
> If there is some information we are lacking
As I said already, I'll post about this later, just not yet, give me some
more time. It's much more efficient for everyone if I simply explain
this stuff, rather than you having to pry it from me with a
question-and-answer game.
> How is it not Harvard?
It can read data from insn rom.
Segher
byuu wrote:
Dear god why, why would anyone design hardware like this? ;_;
Today NovaYoshi was making a really simple CPU in KLogic as an experiment. I told him how the CIC's program counter was a polynomial counter, much like the noise generator in the 2A03 and the POKEY.
His first question: "Wait, what? That's a CPU? Why would Nintendo include a CPU in every Game Pak for lockout and not for DSP?" I told him the 4-bit microcontroller was cheap enough for Nintendo to have made that it was worth avoiding the pile of total crap released for a certain Atari console around the mid-1980s video game recession.
His second question was like yours: "Why does it use a polynomial counter?" I told him my guess: a row of latches and an XNOR gate save a few gates off the row of half adders that make a up a linear program counter.
Quote:
Is there a place one can obtain the SNES CIC ROM, and some logs of observed output from a real CIC?
We could try with the (well-known) NES data, provided it actually is the same CPU.
segher wrote:
It can read data from insn rom.
Then it's a modified Harvard architecture. But if the instructions for reading from data memory and from instruction memory are separate, and there's no mechanism for writing to instruction memory or executing from data memory, it's still a lot closer to Harvard than von Neumann. But my point was it'd still be a pain to squeeze a linearly indexed array into the program space if the program itself is not linearly indexed.
I just got uncomfortable when you started disrespecting the work of Wikipedia contributors. Nevertheless, I
raised the issue of "XNOR polynomial counters are not strictly linear" on the LFSR article's talk page.
I have posted an article at
http://hackmii.com/2010/01/the-weird-and-wonderful-cic/ .
It describes the architecture and instruction set of the CIC. I also posted disassemblies of the NES and SNES ROMs, and the source code for the disassembler (which is at
http://git.infradead.org/users/segher/dis-cic.git ).
Have fun! Questions welcome, of course.
Segher
> His second question was like yours: "Why does it use a polynomial
> counter?" I told him my guess: a row of latches and an XNOR gate save
> a few gates off the row of half adders that make a up a linear program
> counter.
Yes, it is actually only about half the area, which is worthwhile given that
this chip is so simple that _anything_ is big :-)
>> It can read data from insn rom.
> Then it's a modified Harvard architecture.
Sure, it is closer to Harvard arch than to Von Neumann arch.
> But my point was it'd still be a pain to squeeze a linearly indexed array
> into the program space if the program itself is not linearly indexed.
Not really; the table lookup insns use a different bank of ROM anyway.
> I just got uncomfortable when you started disrespecting the work of
> Wikipedia contributors.
I don't disrespect their work, or the contributors; I don't find wikipedia
a trustworthy source of information though.
> Nevertheless, I raised the issue
Thank you.
Thanks for taking the time to write that up.
segher wrote:
I reverse engineered this all from just the bits in the rom, and a lot of datasheet/patent archeology. Couldn't find the exact cpu fwiw.
Did you compare with the Tengen code, ala 'rosetta' style? Otherwise I don't understand how you are gleaning information on opcodes.
And stuff like "there is a four entry stack for the PC; it’s not in RAM, it is separate". As I mentioned, I could see that when I traced out the circuit, but I don't understand how you can see that just from the ROM dump and with no knowledge of which cpu is used.
Basically, it is important for my learning process to know what assumptions went into creating this ... where intuition and guesses are separated from derivations. This is important to me. I would like to understand the process better, so I can understand the current state of knowledge better.
segher wrote:
> How is it not Harvard?
It can read data from insn rom.
...
Not really; the table lookup insns use a different bank of ROM anyway.
Since I've traced out the PC and stack myself, I don't see how a lookup physically is possible (unless there are complicated multi-cycle instructions involving the stack). It looks to me like you can only have data from the ROM in the sense that an "immediate" address mode opcode contains data in the opcode itself.
Scanning your opcode list, I don't see any table lookup instructions. So it still looks like Harvard architecture to me. If I'm missing something material here, please let me know. (If you feel I'm misusing terminology again, I guess it can only help to clear that up as well.)
While this line of questions may seem silly, since I approached this rev-engineering mostly from bottom->up from the IC circuitry itself, it is important to me to reconcile this information with what I have learning from studying the circuitry myself.
---
EDIT:
You wrote:
"that third ROM is 768 bytes, which I don’t handle in my little conversion script, so you’ll need to remove the extra columns (they are empty anyway)"
Actually, there is one byte in there that is not empty. I wonder if this corresponds with your 'mystery' opcode in some way. I'm tired right now, so I'm going to bed. I'll re-read all this stuff tomorrow after some rest.
neviksti wrote:
---
EDIT:
You wrote:
"that third ROM is 768 bytes, which I don’t handle in my little conversion script, so you’ll need to remove the extra columns (they are empty anyway)"
Actually, there is one byte in there that is not empty. I wonder if this corresponds with your 'mystery' opcode in some way. I'm tired right now, so I'm going to bed. I'll re-read all this stuff tomorrow after some rest.
That not-empty byte is only a "t 400" instruction. (machine code 0x80.)
> Thanks for taking the time to write that up.
My pleasure, it was a wonderful ride. I hope this info is useful in some way.
> Did you compare with the Tengen code, ala 'rosetta' style?
Yes I did. The Tengen code isn't a 1-1 translation, it does some things
in a different order, and it doesn't do most of the work at all.
It certainly helped though, esp. the timing info.
> Otherwise I don't understand how you are gleaning information on opcodes.
You take a frequent opcode, see in what patterns it is used, and go
from there. Lots of trial and error.
> And stuff like "there is a four entry stack for the PC; it’s not in RAM, it is
> separate". As I mentioned, I could see that when I traced out the
> circuit, but I don't understand how you can see that just from the ROM
> dump and with no knowledge of which cpu is used.
A big part of the work was finding and reading as much documentation
on this chip as possible. None is there that I could find, but some family
members have a bit of info hidden in various patents. Also, some newer
family members have actual datasheets available.
I think the actual chip is a Sharp SM4 (or some very old SM5).
Gleaning the PC stack from the best die photographs i could find
(
https://netfiles.uiuc.edu/mantey/www/D4 ... erview.jpg ) was easy. It is not so easy to find registers on there etc., and I cannot read
out the insn decoder PLA on that resolution/quality ;-)
> Basically, it is important for my learning process to know what
> assumptions went into creating this ... where intuition and guesses are
> separated from derivations. This is important to me. I would like to
> understand the process better, so I can understand the current state of
> knowledge better.
Find me on IRC, it is hard to explain in a forum. You can write it up if you
want to, it's not like I want to keep it a secret or something, I just don't
know where to start.
> > > How is it not Harvard?
> > It can read data from insn rom.
> > Not really; the table lookup insns use a different bank of ROM anyway.
> Since I've traced out the PC and stack myself, I don't see how a lookup
> physically is possible (unless there are complicated multi-cycle
> instructions involving the stack). It looks to me like you can only have
> data from the ROM in the sense that an "immediate" address mode
> opcode contains data in the opcode itself.
It indeed does a push to stack, then it fetches a byte (from a special bank, offset X and A), to X and A, and finally it pops PC again. That is how it is
described for different SM5 anyway.
> Scanning your opcode list, I don't see any table lookup instructions.
Yes, I have only insns that are _used_ in there, I have no way of figuring
out the rest without a much better die photograph, or some ancient docs
showing up magically. There might not _be_ a table insn on this even, I
thought there was though.
> So it still looks like Harvard architecture to me. If I'm missing
> something material here, please let me know. (If you feel I'm misusing
> terminology again, I guess it can only help to clear that up as well.)
Many opcodes have immediate operands in the opcode; that isn't "pure
Harvard". But almost nothing is, heh. It is pretty silly to want to divide
all CPU designs into these two groups; some CPUs are *very* much not like
either Harvard or Von Neumann arch!
I agree now that the CIC CPU is quite like Harvard though.
> While this line of questions may seem silly, since I approached this
> rev-engineering mostly from bottom->up from the IC circuitry itself, it is
> important to me to reconcile this information with what I have learning
> from studying the circuitry myself.
Yeah, it is great to hear (and see) how other people approach the problem,
in my experience everyone has a very different way of working.
> > "that third ROM is 768 bytes, which I don’t handle in my little conversion
> > script, so you’ll need to remove the extra columns (they are empty
> > anyway)"
> Actually, there is one byte in there that is not empty.
It's a "t 0" at offset 7f, you have that in every bank. Doesn't do anything
useful, probably an artifact of the assembler?
> I wonder if this corresponds with your 'mystery' opcode in some way.
Not as far as I can see, sorry :-(
I think the mystery 5e sets some internal flag or I/O something, btw.
Segher
OK, so this is kind of groundbreaking and also great news for people who would like to build small series of SNES dev carts or the likes.
So, do any ROM dumps or die photographs exist of the D413A (PAL CIC)?
^^I could be wrong but I don't think they've actually cracked it yet. They're getting closer though.
The progress is amazing. AFAICS there are only two mysteries left:
- Instruction $5e (which is not used in the currently dumped SNES CIC ROMs)
- multiple consecutive ldi instructions.
AFAICS the latter are used in seed initialization so it might actually help to have another ROM dump.
I do have a spare D413A but I seriously have no idea how to go about decapping it and taking pictures. I'm afraid I don't have access to the necessary equipment.
Oh wow thats awesome. Wonder how long it'll take till we have a working clone then
> OK, so this is kind of groundbreaking and also great news for people who
> would like to build small series of SNES dev carts or the likes. ;)
> So, do any ROM dumps or die photographs exist of the D413A (PAL CIC)?
I haven't seen any ROM dumps or die shots for those.
They aren't needed though (assuming the PAL versions etc. use the same
algorithm, just different initial values / "keys"). The easiest way to create
a "sciclone" would be to sniff the data stream on a D411, and verify that we
understand the algorithm from that; also, you can derive the timings from
that (much easier than counting cycles in the disassembly; well, much less
tedious and error-prone anyway).
Then, take a D413 etc., and sniff the streams on that; then, write some
simple program that derives the initial values from that (it isn't exactly
a cryptographically secure cipher).
The algorithm for the SNES CIC is almost identical to the one on the NES
CIC: the main (only?) difference is that it runs the "mangle" function three
times in a row where the NES CIC does it only once.
Someone _could_ have figured that out from the data alone even. It's
hard to speculate how much of a long shot that would have been.
> The progress is amazing. AFAICS there are only two mysteries left:
Depends what you think is the goal of all of this. If the goal is to actually
figure out the instruction set, there probably are some more opcodes that
aren't used in the CIC code. If the goal is to figure out the algorithm used
on the SNES CIC, then we have plenty of information (together with
stream dumps) to figure it all out.
I am also not claiming there are no mistakes in my interpretation of what
the instruction set and CPU architecture is.
> [*]Instruction $5e (which is not used in the currently dumped SNES CIC ROMs)
Yeah, I have no real clue what this does.
> [*]multiple consecutive ldi instructions.
> AFAICS the latter are used in seed initialization so it might actually help
> to have another ROM dump.
They are used in a few other places. It isn't necessary to really understand
those to create a clone, it is almost trivial to reconstruct the initial state
from a few dumps of the actual data streams.
Not sure if this has been posted yet, but a while ago I made a logic analyzer dump of the D411 when stream 1111 is picked.
http://nesmuseum.com/10nes/snes1111.png
The idea is similar to the NES cic where the console sends the 4 bit stream to use (shown before the -400uS line) then its sparse bits from console and cart. I can make more accurate picts if needed but there should be a couple people with manual logging equipment to large cycle accurate tables.
Great!
I will do the same with a pair of D413 when I get around to it.
segher wrote:
> [*]multiple consecutive ldi instructions.
> AFAICS the latter are used in seed initialization so it might actually help
> to have another ROM dump.
They are used in a few other places. It isn't necessary to really understand
those to create a clone, it is almost trivial to reconstruct the initial state
from a few dumps of the actual data streams.
It seems the latter ldis just override the former as one would expect. A brief inspection of the initial key exchange (before the first scrambling) supports this.
So the seeds for a D411 are:
Code:
KEY: b14f4b57fd61e98
LCK: _9a185f11e10dec
with _ being the "stream select" bits from the lock in order 3-0-1-2 as usual.
AFAICS the scrambling algorithm itself is unchanged from the NES CIC (aside from being called three times).
Another change appears to be that, after scrambling, the D411 replaces the lock seed's third nibble with its seventh nibble ([0x13] <= [0x17]).
It also does lots of redundant stuff to P3.0, which changes some details of how the 'temp' nibbles (0x00, 0x10) are generated and interpreted, but the changes cancel each other out.
EDIT: This was wrong. I'm still not sure what exactly it is that P3.0 does, but with the D411, key and lock streams are swapped when [0x17].0 is 1 after the triple scrambling runs.
Here's a quick hack in C that generates a D411's input and output streams. Confirmed for the first 40 or so block transfers sampled with an LA.
http://pastebin.com/aGyMWbKF
Here are the seeds for the D413 - compare them to the D411. They really put lots of effort into it.
Code:
key seed: b14f4b57fd61e98
lck seed: _6a185f11e10dec
BTW, are there any SNES CICs other than D411 and D413?
Great work! Too bad they don't spell out anything
I do not know of other CIC's, possibly in the Super Famicombox? Will assume the D413A etc are just process variations.
Additionally it might be interesting to use the instruction set info to disasm the ROB chip once a ROM dump is made. Supposedly it is the same CPU.
---
If anyone knows someone who is awesome at PIC programming, I will offer a significant pile o cash for a Super Ciclone. Please PM/email to not derail the thread.
I would also be very interested in a C implementation of the lock+key CICs. While they don't help emulation, I would like to include them for the sake of hardware documentation.
ikari_01 wrote:
BTW, are there any SNES CICs other than D411 and D413?
I have personally seen the following:
D411 (NTSC carts)
D411A (NTSC carts)
D411B (NTSC carts)
D413 (PAL carts)
D413A (PAL carts)
D413B (PAL carts)
F411A (NTSC carts with SuperFX, OBC1, maybe others)
F413A (PAL carts with SuperFX, OBC1, maybe others)
i don't like pic micros.. how about an open source AVR?
wouldn't mind doing the time for a universal nes / snes chip
..
edit: removed dumb question
Here's a
PIC implementation for the SNES CIC. Key mode only, auto region fallback (requires user reset)
Doing a combined NES/SNES CIC clone is a cool idea, especially since there is no open source NES CIC clone yet.
Awesome a snes ciclone
Quote:
Here's a PIC implementation for the SNES CIC. Key mode only, auto region fallback (requires user reset)
Doing a combined NES/SNES CIC clone is a cool idea, especially since there is no open source NES CIC clone yet.
nice job! guess i'm starting with the nes cic.. then i'll make it universal
i only have 3193/6113 and D411A/F411B so i cant test everything
3197 apparently burns five extra cycles before initialization and first seed transmission is fifteen bits..
heres the seeds if you want to add them to your chip
3193 - USA/Canada
LOCK: 3952F20F9109997
KEY: x952129F910DF97
3195 - Europe
LOCK: $17BEF0AF5706617
KEY: $x7BD309F6EF2F97
3196 - Asia
LOCK: 06AD70AF6EF666C
KEY: x6ADCF606EF2F97
3197 - UK/Italy/Australia
LOCK: 558937A00E0D66D
KEY: x79AA1E0D019D99
ikari_01 wrote:
Here's a
PIC implementation for the SNES CIC. Key mode only, auto region fallback (requires user reset)
Great!
What type of PIC would I need to try this out?
If you download the source, you'll see at the beginning: "processor p12f629"
blargg wrote:
If you download the source, you'll see at the beginning: "processor p12f629"
Argh! How could I miss this? Thanks, blargg.
Edit: Hmmm ... ikari_01, would this work on a 12C508 as well?
orwannon wrote:
Edit: Hmmm ... ikari_01, would this work on a 12C508 as well?
Unfortunately not. Three problems:
- The 12[C/F]508 has a fixed power on reset delay of 18ms which is too slow.
- The lock CIC resets the key CIC using an active high reset signal - however the reset pin on the PICs is active low. Therefore the "reset" is simulated using the external interrupt pin of the 12F629, a feature not available on the 508.
- This is really a matter of convenience, but: The 508 has no EEPROM to store the last valid region, meaning the clone would not be able to permanently adjust to the type of lock (411/413).
So if you have external components like another uC to monitor the clone function and change/store the region, and an inverter for the reset pin, it might work - except in cases where the lock CIC would expect the key CIC to respond before 18ms after power on.
It's probably not worth it
If you don't need automatic region switching, you can go for the 12F609 which has no EEPROM but is cheaper and is available in smaller packages (MSOP8).
Nice work, that's pretty cool to see. Please pardon my cynicism, but I hope people will use this for something other than selling lame bootleg carts..
Memblers: guess we have to get cracking on some snes homebrew huh?
@Memblers & Jeroen:
Yeah.. Because for now, the only use for the CIC is quite obvious. It will surely spur a lot of wannabe cart makers. But still, if we look at the bright side, maybe someone, someday, can make is own home brew cart more easily.
I doubt this will be used for bootlegs. Bootlegs still need a PCB, which generally come with a CIC anyway. I don't think anyone is going to manufacture new PCBs to produce bootlegs. Not unless they were going all out making tons of them. I doubt that would be profitable though.
Good point, MottZilla. I guess those counterfeit cart sellers are up to a quick buck without much of a production hassle. Not being one of them, I can but speculate about their motivations, though.
Anyway, the SNES CIC clone is quite possibly the best solution for homebrewn cart projects intended to run on all hardware without restrictions, such as the PowerPak, the Neo Myth cart or the multi-region hardware test cart I'm working on.
So, once I get my hands on a 12F629, I'll try this out. Thanks again, ikari_01!
For the home brew part, yep, I hope I can get one of those on a dev cart someday.
MottZilla wrote:
I doubt this will be used for bootlegs. Bootlegs still need a PCB, which generally come with a CIC anyway.
That's like what I was thinking, except that you need cart cases as well. Anyone could afford PCBs, just the setup cost alone for making cart cases requires selling an unrealistic amount of a single homebrew game to break even.
With this PIC code you could make new boards of any design you want, use this PIC, and recycle any surplus common carts for their shells. If you want to collect those games as boards, it's free.
It would be cool too if the Powerpak cart shell could be re-purposed for this. If it comes with a big hole for a CF card though, that might be a little odd.
I had kind of wondered about making an SNES port of the Garage Cart series, but I don't think I want to bother with the PPU emulation myself anytime soon and it requires enough reprogramming as it is.
I know bunny mills the nes powerpaks out so the cf card wil fit...and I cant imagine him not having the foresight of possible snes homebrews.
Is there also a lock mode PIC implementation available for use on an SNES mainboard? This would be perfect for a multi-region console allowing playback of games of any region (even SA1 and SDD1 games like Super Mario RPG would work, which doesn't work with most available Lockout-Mods).
How would the current key mode implementation have to be changed to turn it into a lock mode implementation? I have no knowledge about PIC programming, I'm just asking out of curiosity.
From what I can tell, the key is NOT able to tell which lock region it is running on. On the other hand, the lock IS able to tell which CIC key region is currently being used, if programmed right.
When the Lock/Key have initialized their seeds, the Lock sends the lower bits of ALL of its side to the key, and nothing in that changes between regions, so the key is not able to tell, other than by incorrect bits sent.
The Lock sends its 4 bit random value to the key. Bit 0 of that random value is going to already be known when the key sends it back. Next, Bit 0 of the next value, also sent by the key, effectively specifies the region.
Now, a modded console could have the cic clock source removed, and the lock in console sends the clock to the key cic, in effect, controlling the timing.
I plan to write some test code to try this out, which will happen once my PIC chips arrive. (one to be programmed with the key, the other to try and communicate with said key.)
Exactly. The lock can autodetect the key region even of an original CIC. Manipulating the clock is not really necessary though, there is still plenty of time between the bit transfers to check the key region and do other things.
The only part that was a little tight is the hash calculation, though there are still 18-20 cycles left per iteration.
OK, I've updated
the archive with a lock implementation.
This implementation autodetects the key region and switches behavior accordingly.
There is no status pin anymore because all 6 I/O pins of the 8-pin package are now used for actual CIC signals.
Note that it never disables the console, even if the key CIC is missing, except when the RESET button is pressed on the console. That way CIC-less cartridges can be supported while maintaining compatibility with cartridges that demand a working lock CIC, such as S-DD1 or SA-1 enabled games.
The lock code can also be reassembled to run on a 12F609 as no EEPROM is required. Maybe some register has to be renamed or removed.
That's awesome. Have you been able to test the lock version with a SA-1 and SDD-1 cartridge yet?
I don't have an SA1 cartridge but I'll test with Star Ocean shortly. It does work with plain key CICs.
Uhh, what was the S-DD1 failure mode for missing CIC again?
Right now it seems to run perfectly on my modded SNES without the PIC.
So any chance you could maybe make a write up on the basic functions of the code? I mean we technicly have your code...but deciphering someone elses code isnt always the most efficient way to find out (imo). No biggie if you have no time/don't want to though.
ikari_01 wrote:
I don't have an SA1 cartridge but I'll test with Star Ocean shortly. It does work with plain key CICs.
Uhh, what was the S-DD1 failure mode for missing CIC again?
Right now it seems to run perfectly on my modded SNES without the PIC.
I'm not sure what the deal is with the SDD1. The SA-1 games are what I recall being impossible to run without the proper NTSC or PAL system with working CIC.
The S-DD1 will not decompress graphics by hooking DMA if the cic does not authenticate against the main unit; it will just dma the compressed data directly to vram, the same behavior many emulators did before the compression was figured out.
LN
ikari_01 wrote:
OK, I've updated
the archive with a lock implementation.
Awesome work. However, in your lock source code, you may wish to make a correction.
Currently, it says.
Code:
; ---------------------------------------------------------------------
;
; pin configuration: (cartridge slot pin) [original 18-pin SMD lock CIC pin]
;
; ,---_---.
; +5V (27,58) [18] |1 8| GND (5,36) [9]
; CIC clk (56) [7] |2 7| CIC data i/o 0 (55) [1]
; host reset out [10] |3 6| CIC data i/o 1 (24) [2]
; CIC lock reset in [8] |4 5| CIC slave reset out (25) [11]
; `-------'
;
; pin 3 connected to PPU2 reset in
; pin 4 connected to reset button
; pin 5 connected to key CIC pin 7 (or clone CIC pin 5)
; pin 6 connected to key CIC pin 1 (or clone CIC pin 7)
; pin 7 connected to key CIC pin 2 (or clone CIC pin 6)
Change that to
Code:
; ---------------------------------------------------------------------
;
; pin configuration: (cartridge slot pin) [original 18-pin SMD lock CIC pin]
;
; ,---_---.
; +5V (27,58) [18] |1 8| GND (5,36) [9]
; CIC clk (56) [7] |2 7| CIC data i/o 0 (55) [1]
; host reset out [10] |3 6| CIC data i/o 1 (24) [2]
; CIC lock reset in [8] |4 5| CIC slave reset out (25) [11]
; `-------'
;
; pin 3 connected to PPU2 reset in
; pin 4 connected to reset button
; pin 5 connected to key CIC pin 7 (or clone CIC pin 5)
; pin 6 connected to key CIC pin 1 (or clone CIC pin 6)
; pin 7 connected to key CIC pin 2 (or clone CIC pin 7)
.
I checked things out, comparing lock/key source, and given that the chips are in perfect sync with each other, what you had before will cause input to be hooked up to input, and output to be hooked up to output, 100% of the time. Needless to say, both chips would hit their die routines very shortly after seed transmission, if hooked up as suggested in source.
Really fantastic work ikari_01
I was just curious about the key implimentation - from what I gather it starts as one region, and if its incorrect it automatically switches to the other region when you reset/power cycle the console. My question is does it 'remember' the correct lock region setting, or do you need to reset/power cycle the console everytime you want to use it?
Also, would it be possible to make the key auto-detect the lock region (Like the lock implimentation) or is that not possible?
Lastly, now that we have a working SNES CIC clone how much harder would it be to make an N64 CIC clone? I guess a clone of the 6102/7101 would be most desirable, or the 6105/7105 if it could be used in conjuction with a 'universal boot emulator'.
EDIT: confirmed working with Star Ocean! Don't have any other sensitive games to test.
caitsith2 wrote:
ikari_01 wrote:
OK, I've updated
the archive with a lock implementation.
Awesome work. However, in your lock source code, you may wish to make a correction.
Oops.
Corrected. Along with a small timing correction (begin seed transmission 1 cycle earlier). It did work before but now it's closer to the original.
Link83 wrote:
My question is does it 'remember' the correct lock region setting
Yes.
Sadly it's not possible to have the key autodetect the lock region. There's no difference in how the lock appears to the key.
About the N64 stuff, I don't have the slightest.
I did not do the actual reverse engineering of the SNES CIC either.
Jeroen wrote:
So any chance you could maybe make a write up on the basic functions of the code?
Um... Uhh... When I get around to it
(I know I should.)
Star Ocean shots:
Before:
After:
Thanks for the reply ikari_01
Great to see it running Star Ocean.
If I wanted to use the lock implimentation in my SNES console would it be best to completely remove the original CIC chip and connect the clone to the correct pads? Or should I just disable the original CIC (By turning it into a key) and then 'piggyback' the connections? Or would it work either way?
Also, you mentioned 'reverse engineering' would be required to make an N64 CIC clone, and I just wondered what information is actually needed? I only ask as I have already seen some pictures of a decapped N64 CIC chip a while ago, and there is also a dump available of the PIF ROM (The PIF-NUS chip is the 'lock' chip inside the N64 console, although it also handles the controllers, memory cards, etc as well which is why it can't just be disabled like the SNES lock chip) Although I am unsure if this is a dump of the CIC part, of the boot part of the PIF-NUS chip.
...I just thought it might be easier to make an N64 CIC clone now, especially since we now have a better understanding of how the CIC CPU works, and a working clone thanks to yourself.
Thanks again for your help
I
think it should be enough to do the usual mod (Pin 4 -> GND) and additionally disconnect pin 8 from the PCB and tie it to GND, too. (And then connect the PIC to the PCB "pin 8", not the CIC pin 8.)
I didn't do this yet, just the usual Pin 4 mod with the PIC soldered on top. With this the SNES refuses to boot directly after power up - I have to push reset once. I think the additional pin 8 mod should fix this but I haven't tried yet.
Note that this does NOT work! I just tested it. It just shows the same behavior or does not come out of reset at all.
What I do know now is that
if you remove the original CIC completely you'll need a pull-down resistor between CIC pin 8 / PIC pin 4 and GND. 10kΩ will do. There's a debouncing capacitor connected to the reset button that seems to take forever to discharge when the PIC is used instead of the CIC.
I'll try to watch an N64 do its CIC stuff. Can you point me at the ROM dump?
The die photos I found at
http://retroactive.be/mirror/n64/cic_die/ are nice but the ROMs are unreadable. Are there any others?
I will probably just remove the original CIC entirely, as it seems like there would be less complications/wires that way
For the 10kΩ resistor does it matter if I use metal film or carbon film, or if its 1/4W or 1/2W etc? Also, is it possible the PIC code can be changed to remove the need for a resistor? (I'm guessing no, but just wanted to check)
Regarding the N64 CIC, those are the only pictures I know of showing a decapped N64 CIC chip. I know someone called 'MooglyGuy' was planning to send all the N64 CIC's off to be decapped in June 2008:-
http://moogle-tech.com/blog/?p=62
But I have not heard anything about it since
The PIF-NUS dump is called 'pifdata.bin' and I believe it was decapped/dumped from an Aleck64 board (Aleck64 is an arcade system that was based on the Nintendo 64 and used the same PIF-NUS chip and a CIC chip) I am not sure if its ok to post a download link here, so I have sent you a PM with a link to download the file, hope thats ok. Please note though that I dont know if its a dump of the CIC part or the boot part of the PIF-NUS chip.
The properties of the resistor don't really matter. Sadly the code cannot be modified so no resistor would be needed. The PIC only has internal pull-ups, no pull-downs.
I'm planning to modify the code further. As we established the lock PIC can detect the key CIC's (== game cartridge's) region. The lock PIC is also located inside the SNES. What else is located inside the SNES?
Right, the 50/60Hz pins of the PPUs.
(this will require a larger PIC though, presumably a 16F630)
ikari_01 wrote:
I'll try to watch an N64 do its CIC stuff. Can you point me at the ROM dump?
The die photos I found at
http://retroactive.be/mirror/n64/cic_die/ are nice but the ROMs are unreadable. Are there any others?
i have two disks marked "N64 CIC" i don't have a drive plugged in tho..
definitely have more... i'll check them in awhile when i reboot my computer.
EDIT: I checked the photos and they aren't good enough i'm only just getting started really....
first i started noting the 'nescic' correct me if i'm wrong but i think it's 6193?
but i switched to noting the '3195' file when i ran into a problem (when i get time i'll try it again)
also working on notes for the snes d411 file
should be simple enough to map out the differences in timing
Some hints:
http://hackmii.com/2010/01/the-weird-an ... mment-6000
I was not aware of the carry flag behavior and expected it to be changed on any arithmetic operation. Not so.
http://hackmii.com/2010/01/the-weird-an ... mment-6016
This guy had the instruction set mapped out on an excel sheet and made a screenshot of it. However the image server seems to be down.
I remember the mystery instruction being described as "XXL" in that screenshot, "exchange X and BL". May or may not be correct.
ikari_01 wrote:
I think it should be enough to do the usual mod (Pin 4 -> GND) and additionally disconnect pin 8 from the PCB and tie it to GND, too. (And then connect the PIC to the PCB "pin 8", not the CIC pin 8.)
I didn't do this yet, just the usual Pin 4 mod with the PIC soldered on top. With this the SNES refuses to boot directly after power up - I have to push reset once. I think the additional pin 8 mod should fix this but I haven't tried yet. Note that this does NOT work! I just tested it. It just shows the same behavior or does not come out of reset at all.
ok, about that:
If you want to leave the original CIC in place:
- separate pins 1, 2, 10, and 11 from the mainboard. They are pretty easy to reach as they are located at the edges of the chip and are direct neighbors.
An existing pin 4 mod can be left unchanged. A non-existing pin 4 mod can be left unchanged.
If you unsolder the original CIC:
- place a 10kΩ resistor from former CIC pin 8 to GND.
caitsith2 wrote:
The Lock sends its 4 bit random value to the key. Bit 0 of that random value is going to already be known when the key sends it back. Next, Bit 0 of the next value, also sent by the key, effectively specifies the region.
so the 8th bit coming from the key should tell the region for the snes key?
ikari_01 wrote:
I'm planning to modify the code further. As we established the lock PIC can detect the key CIC's (== game cartridge's) region. The lock PIC is also located inside the SNES. What else is located inside the SNES?
Right, the 50/60Hz pins of the PPUs. Very Happy
(this will require a larger PIC though, presumably a 16F630)
the snes
'rainbow mod' got me thinking about doing this.
No, actually the 2nd bit: The CICs operate on 4-bit values and only the LSBs of each are transceived anyway.
The rainbow mod is cool! Didn't know something like that existed.
The PIC mod will also allow the user to set a preferred region. e.g. it can stay in 60Hz mode whenever possible except when a PAL game is detected. In that case it will set 50Hz mode for ~10 seconds to trick the software region detection, then switch to 60Hz.
If a replacement lock CIC autoswitches to 60 Hz after booting a PAL cartridge, can this be made an option?
Autoswitch to 60 Hz might leave some games' cut scenes out of sync with the music unless the music player puts the current song position on the APU ports. A few games do region detection more often because their engines depend on the region, though this is less common on the Super NES due to its scanline-counting interrupts and blast processing, but I imagine there are still a few games that need all the vblank time.
Yes. It will be switchable between "force 50Hz", "force 60Hz" and "auto".
This is the planned behavior. "PIC" is the user setting, "game" is the detected CIC region.
Code:
PIC game behavior
------------------------------------------------------
50Hz 50Hz 50Hz constantly
50Hz 60Hz 60Hz for x sec, then switch to 50Hz
50Hz no CIC 50Hz constantly
60Hz 50Hz 50Hz for x sec, then switch to 60Hz
60Hz 60Hz 60Hz constantly
60Hz no CIC 60Hz constantly
Auto 50Hz 50Hz constantly
Auto 60Hz 60Hz constantly
Auto no CIC 50Hz or 60Hz (tbd)
ikari_01 wrote:
The PIC mod will also allow the user to set a preferred region. e.g. it can stay in 60Hz mode whenever possible except when a PAL game is detected. In that case it will set 50Hz mode for ~10 seconds to trick the software region detection, then switch to 60Hz.
Some protected games do their check during the game, not only at the beginning. So, you can play about 10 minutes and then get the "this game pack is not designed" message.
PICs don't come with crystal balls, so you'll have to switch manually in that case. And there's always the auto option.
I would give a hold-reset based override option.
That's exactly what's planned. Current setting is indicated by a dual LED. Inspired by
seb's switchless mod. I just heard about the rainbow mod for the first time here
Hi there. These new findings are quite exciting.
Zonomi wrote:
Some protected games do their check during the game, not only at the beginning.
ikari_01 wrote:
PICs don't come with crystal balls, so you'll have to switch manually in that case.
One doesn't need a crystal ball ^ ^
AFAIK, a majority of games detect the region on runtime by checking the fourth bit of register $213f.
I don't know if you can address this register from the PIC though. See
Anomie's register doc for the details.
--
edit: link
Marcel wrote:
I don't know if you can address this register from the PIC though. See
Anomie's register doc for the details.
--
romhacking.net does NOT allow hotlinking to any of its documents. Even copy/pasting the link does NOT work. You instead have to link
here.
just so the ideas out in the open.. i'm using the delay at the beginning of the SNES lock to detect the system because the NES doesn't have it
Marcel wrote:
One doesn't need a crystal ball ^ ^
AFAIK, a majority of games detect the region on runtime by checking the fourth bit of register $213f.
I don't know if you can address this register from the PIC though. See
Anomie's register doc for the details.
most adapters use a chip such as the
TIBPAL16L8-25CN or some other programmable array logic... if i remember correctly i saw a AVR or PIC MCU with a PGA on board. i don't know if it has enough pins and it could also be over kill..
caitsith2 wrote:
romhacking.net does NOT allow hotlinking to any of its documents. Even copy/pasting the link does NOT work. You instead have to link
here.
blargg came up with a better solution last time this came up:
http://web.archive.org/web/200806040318 ... 5Dregs.txt =)
Microcontrollers don't make very good address decoders..
How to inject a bit? I can decode the B Bus address + /PARD and drive an output connected to D4 but the PPU will still drive its own, won't it?
Does it come down to just hoping that the logic gate's output driver is strong enough to override the PPU output? Or is there a way to tell the PPU to tristate its data lines?
Not that I'm planning to implement this right now, just curious. Won't have time for the next couple of days. And of course it cannot be done with a PIC alone.
I don't think overriding the line is a good idea...
Seems a little extreme to add hardware to do what can probably be done by changing one instruction into a NOP in the program.
Memblers wrote:
Seems a little extreme to add hardware to do what can probably be done by changing one instruction into a NOP in the program
this is fine if you have a flash cart or some flash roms and you don't care if you deface your game. game genie could patch a game but it probably doesn't work on most of them... the chip is only about $2.50
ikari_01 wrote:
How to inject a bit? I can decode the B Bus address + /PARD and drive an output connected to D4 but the PPU will still drive its own, won't it?
Does it come down to just hoping that the logic gate's output driver is strong enough to override the PPU output? Or is there a way to tell the PPU to tristate its data lines?
the logic gate's output driver is strong enough to override the PPU output.. this is how most of them work but it would be safer if you lift the pin. B Bus is a good idea (less address lines) you really only need to listen on the address lines for the $213f register then override D4.
EDIT: $213F seems to originate from S-PPU2 (U3, 5C78) pin 55 and 73 are both D4, these pins would be lifted and connected together.. the other soldering point could be U4 pin 16.. the PAL could then make D4 one or zero without bus conflicts
Hi
I've tested the lock version with a PAL snes (50/60 Hz switch already installed).
It works with all games besides SA-1 games.
Star Ocean works without graphic glitches, but the only SA-1 game I own (PGA Tour 96) doesn't star. It does work on a mint PAL SNES, so the cartidge isn't faulty.
Yes, in the meantime I got the same feedback from another guy via mail.
Thought a bit about it but that's it so far.
Did you remove the CIC (+added the pulldown) or did you just lift the pins? I seriously need to get an SA-1 game...
I made a minor timing change in the meantime (I was one cycle late with sending the data pulses). Can you redownload the zip file and test it again?
Very strange. I tested the lock version (with the older code dating from April 11, 19:59) just minutes ago. And ...
Everything works great, including SA-1 games! ikari_01, you're a genius!!!
I used a 1-chip PAL SNES, removed the original CIC (F413B) completely, and added the pulldown resistor. I programmed the 12F629 using a Willem programmer and leaving all of the custom settings alone. When asked what OSCCAL value to use, I read and wrote back the original value, not the one in the hex file.
Here's a list of special chip games I then threw at the SNES. All did start, though some of them soon prompted me with a 50/60 Hz error message (I haven't added a
frequency switch to the console yet).
- Kirby's Dreamland 3 (US, which wouldn't run on anything but an original US SNES or Super Famicom before; if I've ever loved seeing a "This game is not designed ..." message in my life, I can honestly say this was the time! )
- Kirby Super Star (US; "This game is not designed ...")
- Marvelous (Japanese)
- PGA Tour '96 (PAL)
- Star Ocean (Japanese, two different cartridges tested)
- Street Fighter Alpha 2 (PAL)
- Street Fighter Alpha 2 (US; "This game is not designed ...")
- Super Mario RPG (Japanese, two different cartridges tested, one of which wouldn't run on anything but an original Super Famicom or US SNES before)
What I haven't tried yet is to play one of the SA-1 games for a longer period of time to see whether the SA-1 reliably and permanently accepts the PIC as its fake CIC counterpart.
Hura, you might want to check your S-CLK (if applicable - but I guess your SNES has this chip as you've already a 50/60 Hz switch installed and thus, your console is probably a 2-PPU revision one). If one of its pins has been lifted (as shown on the picture at the bottom of
this page), then you might try and reattach it to the mainboard to see whether this has any impact on PGA Tour '96. Good luck!
ikari_01, I'm going to try your new code, too. Maybe I can observe any difference (but I hope not) ...
Well, that's good to hear.
So maybe the original CIC has to be removed after all? I'm looking forward to more reports.
The OSCCAL value doesn't matter btw, the internal oscillator is not used.
I recommend using the newer firmware anyway since its timing is more accurate. Might be more reliable under circumstances yet unknown.
i meant to point out that the nes cic has some timing difference between 319x and 611x
if i remember correctly
lock 319x and key 611x (normal mode) works
lock 319x and key 319x (lock testing lock) works
lock 611x and key 611x (key testing key) works
lock 611x and key 319x doesn't work
if you look at the copyright records
for nes TX0001945426, V2182P102 and TX0003812529, TX0003812530 for snes
the second record for both systems are code updates
for perfect timing you could hook up two keys or locks and compare the outputs
parallel port is good enough you just need to slow it down a little
my circuit divides the clock 2 to 4096 times so i can test
not sure about PIC's but my AVR's runs 0-16mhz and i've run a nes cic at about 245hz
just encase anyone is interested n64
TX0004448359 (N64 security program NTSC version)
and these might be related.. they have part numbers but are custom chips
V3415D609, V3388P134, V3353P347, V3166P259, V3166P258, V3159P533, V3159P530
i'm slowly getting done while trying to optimize and arrange the code.. same problem with the reset pin being backwards. using interrupt 0.. basically doing one function rewrite at a time.. originally i was translating... tho it's possible to translate it would of turned out ugly and i wouldn't learn a thing. it needs to work for snes and nes anyway
jims cool wrote:
EDIT: $213F seems to originate from S-PPU2 (U3, 5C78) pin 55 and 73 are both D4, these pins would be lifted and connected together.. the other soldering point could be U4 pin 16.. the PAL could then make D4 one or zero without bus conflicts
What you seem to be referring to is D4 of the VRAM data bus. However I need to connect to the CPU data bus, which is connected to both PPUs, the S-CPU, S-WRAM, S-SMP, the cartridge slot, and the EXT port. As the verification code is executed by S-CPU, its D4 pin would have to be isolated whenever $3f is read on the B bus. Gonna look into that later though.
orwannon wrote:
ikari_01, I'm going to try your new code, too. Maybe I can observe any difference (but I hope not) ...
For the record, the new revision works just as great as the old one. Thank you so much, ikari_01!
ikari_01 wrote:
What you seem to be referring to is D4 of the VRAM data bus. However I need to connect to the CPU data bus, which is connected to both PPUs, the S-CPU, S-WRAM, S-SMP, the cartridge slot, and the EXT port. As the verification code is executed by S-CPU, its D4 pin would have to be isolated whenever $3f is read on the B bus. Gonna look into that later though.
oops i read the schematic wrong
D4 is pin 11 sorry lol
but that's assuming that the register gets it's value from ppu2
so you could lift that pin and all the other connections could be on the port
including the other D4 connection
with one pin the PIC could select D4 1 or 0 (for that register)
i don't know if you need to check for read/write it's a read only register.. unless is has something to do with the B bus?
I doubt that $213f is the only register that enables PPU2. If you just lift D4 of PPU2 then all reads and writes to all registers that concern PPU2 will be "missing" bit 4.
The A and B buses are address buses. There is only one shared data bus. And /PARD has to be taken into concern. The address can stay on the bus for much longer than the actual read pulse (as long as no further B bus access takes place) so before and after the actual read you'd be hogging the data bus. Instant crash
we keep misunderstanding each other
my idea is lift D4 on PPU2
connect a wire to D4 on the cart slot (a simple connection spot)
the PAL could then connect the two points for everything but the one register.. now every time the address bus points to that register it's gonna read it.. i don't know much about the B-bus but i'm assuming it works the same way (only 8-bit). a third pin could be used to tell the PAL if we want D4 to be a 1 or 0..
on the cart adapter they have 12 address lines and 1 data (D4)
when the address it pointing to the register they put the signal they want on D4 and that's all
also i didn't say $213f enable/disable PPU2...
i said the register and it's value seem to come from it..
if you disconnect D4 on PPU2 when the address is right
set/clear D4 on the CPU
then reconnect D4 when the address changes it should work
PALs switch very fast and this is the kind of thing they are made for
inverting or not inverting D4 is an idea that might make it faster (instead of disconnecting/reconnecting)
so the input from the PIC/AVR
Interesting
Seems like we're talking about the same thing while thinking we're talking about completely different things
so:
Code:
,-----.
< CPU_D4 >---| |
| /PARD >---| e.g.|---< PPU2_D4 >
| /PAWR >---| PAL |
| PA[7:0] >===| |
| PIC_D4 >---| |
`-----'
wire IS_213F = PA[7:0]==8'h3f;
assign CPU_D4 = !PARD ? (IS_213F ? PIC_D4 : PPU2_D4) : 1'bZ;
assign PPU2_D4 = !PAWR ? CPU_D4 : 1'bZ;
like this, right?
yup exactly!
still not sure about /PARD and /PAWR
i'll need to look into it more but i know they don't check R/W on the Bus - A
if it's truly a read only register we don't need them because every time the register pops up on the address bus it's read
my guess is 1st the cpu clears R/W, then sets the address, then sets a R/W
so after a read or write is set it's already to go (or going)
like this
cpu clear read/write
set address to something ; CPU D4 = PPU2 D4
cpu set read
cpu clear read/write
set address to $213f ; CPU D4 = PIC/AVR BIT
cpu set read
cpu clear read/write
set address to something ; CPU D4 = PPU2 D4
cpu set write
so...
CPU_D4=(address==register)?MCU_D4:PPU2_D4
CPU_D4 from cart slot
MCU_D4 from AVR/PIC
PPU_D4 from lifted pin on ppu2
unless read and write are set at the same time as the address even then it's just another two bits to check if it's read only
EDIT:
Segher wrote:
Only “sc” and “rc” modify the carry flag, no other instructions do.
i just want to confirm what i've read about the carry bit. 'sc' sets the carry bit and 'rc' clears the carry bit but no other instructions modify its value? i just rewrote the mangle loop... for parts with the carry flag set i just added oneCode:
lds REGC, Y ; A = A + M(x0001) + C
add REGA, REGC
inc REGA
EDIT2: alright i was being dumb.. lolikari_01 wrote:
Some hints:
http://hackmii.com/2010/01/the-weird-an ... mment-6000I was not aware of the carry flag behavior and expected it to be changed on any arithmetic operation. Not so.
i checked out your (ikari's) d411 scramble too. segher should note that on his hardware description...
the avr has more then enough time for the mangle loop.. i'm trying for a load seed loop now.
got a little more then 9 cycles per nibble/byte and i might load two bytes in parallel i donno lol
Ah, that source code has a little flaw actually.
Lines 97-103 suggest that the streams are swapped but in reality the CIC just swaps its i/o pins. So sometimes the lock stream is output on pin 1 while the key stream is expected on pin 2, and vice versa. When monitoring one fixed pin sometimes you'll see the output of the key (going into the input of the lock) and sometimes the output of the lock (going into the input of the key).
The program outputs the correct streams but you can easily get the impression that the first line of a line pair is always the key stream and the second line is always the lock stream, which is not correct. The two lines of data actually correspond to one of the i/o pins each, with no indication of the direction.
Anyway,
enter SuperCIC:
- lock allows the region to be set+saved by holding the reset button.
- region can be set to 50Hz, 60Hz, or autodetect based on key CIC.
- selected region is indicated by LED color (uses a dual LED).
- has a ~9s timeout before switching from detected to forced region to trick most games. This feature can be enabled/disabled using a configuration pin on the lock.
- "D4" output that reflects the detected key CIC region, or selected user mode if no key detected. Can be used for patching the $213f register using additional hardware.
- with a corresponding SuperCIC key allows 50/60Hz and D4 to be set from the cartridge slot (e.g. by an additional MCU) using CIC data i/o pins ("SuperCIC pair mode"). This mode can be enabled/disabled using a configuration pin on the key.
- documentation has become quite massive (see supercic-lock.asm)
The lock uses a PIC 16F630 while the key remains a 12F629.
Enjoy.
Wow, thats really fantastic ikari_01
Thanks so much for all your hard work.
Out of curiousity, are you still considering making a NES/N64 CIC clone? Hope you dont mind me asking
Not really atm. I think jims cool will have the NES covered.
N64 is out of reach at the moment as the data looks completely different from what the NES+SNES CICs do, and I think it would certainly be more complicated given the fact that the CIC status can somehow be queried by software.
Klaus Wolf of Wolfsoft wrote up a blog post with some instructions and nice macro photos of his mod:
http://blog.wolfsoft.de/?p=603
He chose to remove the CIC but I can confirm it works with the original CIC in place and pins 1,2,10 and 11 lifted as well.
WOW!!!
It's amazing what you have avhieved!!!!! CONGRATULATIONS TO EVERYBODY, SPECIALLY YOU, IKARI_01!!
I hope I could have spare time to do that code into a little CPLD...
why do you want to have it in a PLD when you can have it in a PIC?
PICs are less expensive and easier to program than most PLDs
hyarion wrote:
why do you want to have it in a PLD when you can have it in a PIC?
PICs are less expensive and easier to program than most PLDs
Because is the first step to have a full system-on-chip; that 's one of the projects I would like to finish before I die
Emulating SuperFX chip via programmable logic is the other one XD
nice job ikari_01!
does anyone have a 3197 / 6117 laying around they don't need or could donate?
it's for the UK/Italy/Australia regions. need one for testing..
apparently the timing is a little different...
i'll send the person a copy of my chip when it's finished as a thank you
i also don't have 3195/Europe and 3196/Asia but they should work the same as the 3193.
for the snes i have F411/D411 but the PAL chip is the same
guess i'll offer the same deal with the other chip numbers
don't think i need them but they would be good for testing..
so if you send me a cic i don't have i'll send you a programmed atmega8-16pu
about my last post for the load seed from table loop i decided to load two bytes in parallel and interweave the seeds..
the seed is selected with a 0-7 and i still have an extra 56 cycles to play with
i'll be testing the nes lock/key today
working on the snes part i noticed lots of change in code
the port3 pins could have something to do with disabling the game??
haven't looked much into that yet
hope implementing both the snes and nes cic's doesn't ugly up my code lol
Port 3 is the "tristate register", it is used to set the pin directions of port 0. It does not appear to be connected to any physical pins.
Going from snes to nes should be as easy as
- calling the mangle routine once instead of three times
- not changing pin directions on the fly
- replacing the seeds
- spending an hour readjusting the timing
thanks ikari!
EDIT: if anyone has a AVR they think it should compile for let me know
i'm writing it for atmega8 but it will compile for attiny's
it's taking a little longer then i thought it would.. not that i'm racing lol
for the nes/snes only parts i'm just using a flag and it's working out perfect
as an option the delay at the start of the snes cic code can trigger snes mode
this will allow us to use 6 pin attiny4 and 9 as a universal key!
pin connections would be P0.0, P0.1, 4 Mhz, RST IN, VCC, GND
some of the code can be made smaller by putting it into loops and arranged for better flow
it would be something if i could make it fit into 512 bytes
i'm going to look in to copyright a little more just encase lol
not too worried about it.. my code is different but i wan't to know what they call different
Hi
My first post here
I have just tried a couple of the PICs from ikari_01 on a PAL SNES, the first one on a 12f629 works - except doesn't start my only SA-1 game (Kirby 3) - not a problem - there's people in here with mixed success stories on SA-1 games and this mod.
The second - the SuperCIC, first of all - it works with my Kirby 3
- that's very impressive!!
There are two problems I'm having though:
If I have it on Auto ORANGE, it remembers it this setting, but after switching the console off and back on again, the LED doesn't light at all, it's still operating in Auto mode, just no LED. If I reset the console the LED stays ORANGE, but the screen goes very bright, black is now grey it's so bright.
If I have it on 60hz RED, it remembers the video mode after switching the console off, but the LED will be GREEN.
50hz mode works fine.
Have I done something wrong?
Oh, I removed the original lock chip and put the 10k resistor in there. And I have pin 4 of SuperCIC at 5v. I am using a 3 leg LED.
Many thanks
Pete
(edited to make corrections)
Currently I have no clue about the bright screen issue, it never happened to me so far.
The LED color problem may be related to pin 7 of the PIC. Pin 7 selects LED polarity. Connect it to 5V for common anode LEDs or GND for common cathode LEDs. If it is left unconnected the input will sometimes read 1 and sometimes 0, resulting in confusion of the LED color.
See also:
http://www.circuit-board.de/forum/viewt ... 572#p35572
Heheh
I just realised I forgot about Pin 7 on the SuperCIC
. I just grounded it and all is now working properly. Including the grey screen issue.
Ikari_01, thank you so much for releasing the BEST snes mod. And as I said in my message the other day - I will add a guide to my site and give all credit to you
Thanks again
Pete
Hi, just registered so that I could say thanks to ikari_01 and anyone else that helped bring SuperCIC to release.
I tried it our using a PIC16F630 on a Pal SNES and it works great. I removed the CIC chip and used the resistor.
jims cool: Are you still after a 3197? If so, I have one here that I can send you, '3197A' from a Pal NES.
Jon
It was brought to my attention that PowerPak users cannot enter the save menu anymore when using the SuperCIC lock because it hogs the reset button.
Here's a test firmware that will reset the console for ~6 seconds when the reset button is tapped twice within 586ms. (Of course it's also still a full-featured SuperCIC lock.)
I'd like somebody to try it out as I don't have a PowerPak myself and was only able to observe the behavior of the SNES itself.
Hello ikari_01 and all!
It's ok for this test firmware with PowerPak 1.05b2.
After pressed twice on reset, and after few second, Powerpak Menu appears on the screen.
Thank you !!!
Hi ikari_01 and all!
Any chance you could tell me how to put the hex files into the PIC16F630 and the PIC12F629 correctly?
I came across the files on wolfsoft blog website.
In the zip file contains A LEGAL DISCLAIMER FILE x2 hex files and x2 .asm files.
As I understand it .asm is the source files for people that understands PIC chip assemby.
How do you write supercic-key.hex + supercic-lock.hex to the appropriate PIC chips?
The supercic-lock.hex is the code for a PIC16F630 which goes in the snes console and the supercic-key.hex is PIC12F629 to be used in a snes cartridge?
If you use a PIC16F630 with the hex file supercic-lock.hex The fuse setting on the chip id or what ever your programmer calls it set to 34C4 Am I correct?
Sorry to ask questions like this but from the start of this supercic project it appears to of changed from its initial release.
Many Thanks
caketin
Awesome mod ikari_01 !
I've got just one question;
The supercic lock works without any problem.
I've tried the supercic Key with a 12f629, programmed successfully without problem (on my wellon vp 280). Soldered with your instructions on the asm file.
On my PAL snes console, without any mod/modification the game refuse to start...with another SNES (old switching mod, pal/ntsc and 50/60hz) the game run only with ntsc and 50 or 60 hz, in pal its never starts...
Did you have any idea ?
Thanks and respect again for this incredible mod ^^
SNES games can check wether the PPU is running in NTSC or PAL (or 60hz or 50hz) mode and can refuse to run if the mode is incorrect. Game Genie or Action Replay is needed to play these games unless you modify your console. This is all separate from the CIC. The CIC is just the first block against playing imports. With the wrong CIC the SNES will stay in a Reset state. With a region free type CIC this won't happen but the software can check if the system is running in NTSC or PAL mode and refuse to run or just show a message warning you that you are in the wrong region.
Thanks Mottzilla
The problem you explain is like when I'm putting a ntsc game on a Pal console or vice versa, no problem to understand this.
I've just miss a thing, i've put the 12f629 on a "simple" original Pal game (Dragon Ball Z -the game is in french-, only 1 rom and a D413 CIC (originally) on board).
The strange things for me, is that the game start in ntsc but not in pal, its original region. That why i would like to change the code in the asm file (I've seen some 09 for NTSC and 06 for PAL) but impossible to compile it for me (i've tried with Mplab..but errors appears) maybe can Ikari01 tell me which software i should use to make a proper hex file ?
Put the game with the 12F629 in an unmodded PAL console and switch it on.
The CIC clone on the cartridge will switch to PAL. The game will probably not boot before you push reset but that's irrelevant.
Afterwards the SuperCIC will detect the clone as a PAL CIC and switch to PAL accordingly.
btw I'm using Piklab with GPUTILS
Hi, ikari_01 !
So I've tested this and I've added the led on the 12f629 (pin 3 of the 12f629).
Again, the key seems to works only in my switched snes and only in NTSC. I tested with two 12f629 (just in case) but the games refuse to start in pal on my original PAL SNES or with my "switched" SNES forced in pal...
In ntsc the led is OFF when I put the game in a PAL snes (or switched in PAL) the led turn "ON". When I press RESET nothing seems to happen...always this fuc**** black screen.
I 'm sure that I wire it correctly (very very simple soldering mod) so I don't understand why
I don't see hwo pal vs ntsc would effect the operation of the chip though....thats kinda odd. (unless I missed something here)
So to clarify: It does not run at all on a non-modified console?
Then there's a communication problem between the Host CIC and the cartridge CIC. The most likely causes are:
- wiring problem (maybe Data0 and Data1 are swapped?)
- fuses setting on the 12F629 (especially clock source)
The hex file contains fuse settings. You might have to force your programming tool to set them on the PIC.
So, I've checked the connections one more time, they are exactly as in your ASM file (supercic-key.asm)
Maybe the fuse settings, I'll look at my programming software...
Thanks ikari_01
Edit. Awesome Ikari, it was fuses settings ^^
So if anyone have a Wellon, change Oscillator Type in Config panel as a RC(GP4:CLKOUT) to make it working (by default set on "EC") !
Interesting... EC (external clock) should be the correct setting.
Quick question, was the NES CIC clone finished? If not is someone still working on it? It just seems a shame if there is still no open source NES CIC clone
Someone made it, then bunnyboy bought it, so somebody will have to make the program again for the PIC for it to be released.
3gengames wrote:
Someone made it, then bunnyboy bought it, so somebody will have to make the program again for the PIC for it to be released.
Or AVR.
That someone was kevtris and the CIClone was based on the reverse engineered Tengen CIC. Now we also know the instruction set and the behaviour of the actual Nintendo CIC since segher reverse engineered it. A clone could be based on either one of those.
Okay, someone needs to get on this, I don't want to be buying lockouts for $4 each for a 10 cent pic. Not that I don't appreciate the work, it's just....markup is over 100%.
I'z cheap.
3gengames wrote:
Okay, someone needs to get on this, I don't want to be buying lockouts for $4 each for a 10 cent pic. Not that I don't appreciate the work, it's just....markup is over 100%.
I'z cheap.
Seems like jims cool was on it... but then he disappeared. Anyone got his contact info? Moderators?
atarimike wrote:
Seems like jims cool was on it... but then he disappeared. Anyone got his contact info? Moderators?
I sent jims cool some CIC chips (NES and SNES) way back in July last year. Was supposed to be helping him test his work but haven't heard from him since.
Thank you for the supercic Ikari_01! Love it
3gengames wrote:
Someone made it, then bunnyboy bought it, so somebody will have to make the program again for the PIC for it to be released.
kevtris developed it, we have the code from the Tengen clone. The algorithm was posted in C and assembly. kevtris already released the PIC code for it at the time, it works by manually clocking the CIC. Mostly it's only the timing in the program that needs to be changed for it to work synchronized at full speed. So all the info is out there.
^^I think he removed that.
Sad to hear jims cool has disappeared, his combined NES/SNES CIC clone for AVR sounded really promising
So was the Tengen CIC clone by kevtris released? There seems to be conflicting info and googling just bought me right back here.
Link83 wrote:
So was the Tengen CIC clone by kevtris released? There seems to be conflicting info and googling just bought me right back here.
No, the source code of kevtris' CIC wasn't released (except for an early version which Memblers mentioned, which might have been removed by now). If you meant hardware, RetroZone is selling exactly that CIC.
Here's the C source that has all the info needed to write a clone (if you can decipher it
). In addition you'd need the different initialization bytes for different regions, those should be available in the Tengen CIC RE thread here in the forums.
Link83 wrote:
Sad to hear jims cool has disappeared, his combined NES/SNES CIC clone for AVR sounded really promising
So was the Tengen CIC clone by kevtris released? There seems to be conflicting info and googling just bought me right back here.
Yeah sorry I don't have any CIC code posted any more. I sold the project so I had to yank it all.
There's plenty of info out there to make a new one though, and the SNES code that Ikari posted should be directly applicable to the NES CIC.
Also I am unsure if an AVR would work due to cycle uncertainty on startup. The PIC has an exactly known startup so it worked. I am not sure if the AVR does. Just a small think that'd need checking.
kevtris wrote:
Yeah sorry I don't have any CIC code posted any more. I sold the project so I had to yank it all.
There's plenty of info out there to make a new one though, and the SNES code that Ikari posted should be directly applicable to the NES CIC.
Also I am unsure if an AVR would work due to cycle uncertainty on startup. The PIC has an exactly known startup so it worked. I am not sure if the AVR does. Just a small think that'd need checking.
I understand
Unfortunately I am not that knowledgeable about programming, so i'll just have to hope someone will take up the challenge.
I would have considered just buying a CIClone from retrozone - $4.00 for the PIC seems fine, its the $14.00 for international shipping that ruins the deal for me
consolingmyself wrote:
atarimike wrote:
Seems like jims cool was on it... but then he disappeared. Anyone got his contact info? Moderators?
I sent jims cool some CIC chips (NES and SNES) way back in July last year. Was supposed to be helping him test his work but haven't heard from him since.
hey guys sorry that I vanished.. atarimike contacted me
one of my good friends was struck and killed by a train then I found out my dad had cancer and he passed away shortly after
anyway..
kevtris wrote:
Also I am unsure if an AVR would work due to cycle uncertainty on startup. The PIC has an exactly known startup so it worked. I am not sure if the AVR does. Just a small think that'd need checking.
oh no!!!..... just kidding they work fine
lol
I'm going to touch up the debug version a little then send it out to consolingmyself for testing..
UPDATE: ATtiny's only have 32 bytes of SRAM so I needed to swap nibbles leaving 16 bytes for the stack.. it's a newer chip so I didn't know of this memory limit.. this will make my code 8-bit and I wont need to interweave the table anymore.. should use about the same in flash and half the SRAM .. maybe 2/3 the cycles... I'm using both v1 and V2 assemblers with the configuration.. thinking I'll add 32bit support.. only instructions that change are rjmp and rcall everything else is already one cycle other then skips.. the other limit is 1k flash memory
I got a strange problem....
I maodded a PAL snes with supercic, no problem.
Then I burned the chip the exact same way.
I get graphical errors. No worries I thought after lots of troubleshooting,
then I did another one. Then I get the exact same graphical glitches!
Now I have two non-working NTSC snes'es (I think..)
Could it be my 500ma china power supply? The SNES'es worked fine without the mod... Could it be that the mod draws just enough amount of extra power that the SNES'es have trouble working?
I have been using the latest beta build... might be that?
I guess it's the powerpak beta cic. No way I could screw up the same way twice without noticing...Would be gratefull if someone could confirm that the newest supercic hex works on a us snes.
Edit: Got a 5A power supply now...and of course a microchip more or less wouldn't matter... Guess I will burn the old version of supercic and try that.
Can you take photos of your mods?
Also, does this happen with all games or just with carts equipped with a SuperCIC key?
NTSC and PAL games boot fine, but they are glitchy, so the mod "works". Official unaltered games.
Some games have a non glitchy logo, or some animation working but other issues. Most of the time 90% of the screen is garbled.
Mods are exact as the pictures on wolfsoft.de. I use duo led with grounded pin 7. The LED is also broken. It only lights red and nothing. If I keep reset pushed it switches between red on and off.
I guess I will wait and see if you fix it, as I have a Powerpak on the way.
The SuperCIC firmware is not capable of pulling such a feat
You either have:
- serious mistakes in the wiring
- corrupted/wrong hex files
- wrong fuse settings (they are included in the hex file)
- defective PICs (unlikely because there are two mods with the same errors)
However none of the above, except wiring errors, can cause graphical glitches. Are they colorful and blocky/pixeled or do they rather look like a loss of synchronization?
"good" to hear
..
edit:
ok so I've checksum tested the hex vs the one you posted.. identical
...that narrows it down to wiring...
Could I be using to thin wire any place that would cause such a problem?
See any mistakes here?
http://wolfsoft.de/wordpress/?p=686
Edit: They look like loss of syncronization..yes
Ahhh.. I really want to get to the bottom of this
This makes me depressed.
Really appriciate if you help me troubleshoot Ikari! (like you already do ^^)
Nope, the Wolfsoft mods are 100% correct. Klaus confirmed correct operation to me personally.
(and he shows in the videos that they work even with a US SNES)
You shouldn't use terribly thin wire for the power supply pins (1 and 14), otherwise it does not matter much. Also keep all the wiring as short as possible.
They are terrible thin.....Bought a terribly thing spindle of wire from china. Last mod I did I used thicker gauge on power. Maybe that indeed is the problem. Thank you sir for helping.
OK, loss of sync might mean the SuperCIC has switched to "pair mode". It's a special mode that can (usually) be entered when there is a SuperCIC key present on the cartridge, with its pair mode configuration pin enabled. In pair mode, 50/60Hz can be remote controlled from the cartridge.
The SuperCIC lock can sometimes enter unsolicited pair mode when it doesn't run synchronously with the CIC key on the cartridge, i.e. when its clock source fuse (FOSC) is set to internal clock. It should be set to "EC" (external clock, 0x0003).
If pair mode is entered without an aware counterpart (=SuperCIC key) then pulses on the data lines, sent by the CIC key, can cause rapid switching between 50Hz and 60Hz.
To see if the SuperCIC is really in pair mode, push reset. If the console resets immediately (as it would without a SuperCIC present) pair mode is engaged.
Pair mode does not explain the strange LED behaviour though.
Also triple-check for ever so tiny solder bridges on the PPU pins.
I know what I have done wrong now...and it sucks bigtime...Im almost embarassed to say it...
I always bend pin one down and solder to the chip beneath on pal snes. I also did that on the ntsc...and soldered 5v from another place...christ.. I fried my goddamn sram on two of my consoles... how insanely clumsy isn't that........
There. Finally. Thank you. Works.. <3
I've just installed the great super-cic chip mod and have just one question.
I installed into a pal snes and it works very well. Except that if I start a pal game in 50hz then switch to 60hz it will play for a few minutes then I get the 'wrong region' message. The same happens if I start an NTSC game in 60hz then change to 50hz (although I don't know why anyone would want to do that)
It works fine if played native or if the super-cic is set to auto mode. Do you think I have a short circuit somewhere?
Why would you change region at all? I think all games for the SNES had to have a region screen. Games probably won't utilize it if they play in both regions. But if the software sees a region change, it'll just error to avoide poblems. That's the only thing I can think of.
Sorry about my earlier post. I've gathered that the chip works flawlessly it just seems to be the region checks that some cartridges do are more frequent than others. (DKC for example checks all the time. Legend of Zelda never checks) Now all I need to do is modify the slot on my SNES to use US carts.
Sadly that's in-built protection in games, especially capcom games. I think there are tools that will remove the check, or you might find out some articles or somthing so you can hex-edit them out yourself.
gaijinsan wrote:
DKC for example checks all the time
Really makes you want to ask the developers why. Were they afraid some clever person was going to hotswap the PPU while the system was running? So much time and effort into screwing over paying customers (for no fiscal advantage!!), and we just keep lining up to give them our money.
Unless it's some sort of raster timing thing where a kernel timed for one frequency will freeze on the other frequency.
gaijinsan wrote:
DKC for example checks all the time.
Odd. I know there is a check right at boot, but if I start my PAL copy @ 50Hz and then flick to 60 when I see the Rare logo it will work happily @ 60 with no problem.
Now, Super Street Fighter 2. Thats another story...
AfaIk, according to the SNES dev manual states that there is a PPU register that states whether the console is operating in PAL or NTSC mode. I dare say there are other methods of detection but just polling that register would be a simple way of implementing region protection and just as easily patched out or bypassed. Datel produced a programmable import adapter that could do just that. Nothing a carefully crafted Game Genie couldn't do either.
A game could measure the length of vblank in CPU cycles. (Compare
NES code to do just this.)
Or a game could measure vcount (OPVCT, $00213D) and crash if it gets or doesn't get a value in 263-311.
Or a game could make a DMA transfer schedule that works on the correct frequency but fails on the wrong frequency. Games that turn rendering off early/on late for more blanking time (I've read that Street Fighter II series is among them) might be more sensitive to such changes.
edit: any possibility you could release a version that can disable pair mode...with like..pushing reset twice or somthing?
powerpak and your mod gets out of sync
The PowerPak's version of the SuperCIC key does not support pair mode so it should never trigger it. Are you observing rapid switching between 50Hz and 60Hz?
Did you mod your PowerPak with your own SuperCIC key? Then be sure to tie pin 4 of the 12F629 high.
Hi ikari_01,
Maybe you're interest to look at it
http://www.emutalk.net/threads/53217-N6 ... y-Reversed
-Tomy
Hello,
I am looking at ways to emulate the CIC Roms for all cartridge regions for custom Cartridge. A potential project down the road would be an SNES cartridge similar to the MMC64 or other cartridge modules for C64. The idea of using an MMC/SD flash module like a disk cartridge or ROM image cart that loads into SNES RAM, a quasi-BIOS for handling the communication to the MMC/SD module and a custom CIC module for any region.
The idea is for some sort of auto-dectection mechanism for the internal console CIC and then respond with the proper code sequence and handle the proper handshake.
The SuperCIC seems like a clever solution but on the console side but I am looking at how to deal with it from the "cartridge" side for the custom cartridge.
Ikari, if you have an idea on how to work that solution, GREAT. Like to hear it and a possible solution.
An idea that I have is the cartridge would load a customized version of Contiki (a modified version of Contiki for SNES) which is a small OS system off of an MMC/SD card. When it is loaded into the SNES, I can then look to use RR-NET module I have via an interface module via the Expansion port on the bottom of the SNES.
The expansion port from a signal line by signal line practically identical to the Amiga "clock port".
I decided that the SNES PowerPak might be a good option for what I am looking at and has the whole setup already done. Only thing might be the potential option for IDE connection and possibly MMC/SD cards but I like the option currently as 4 GB should be amply sufficient for the job and we can reasonably emulate this unit on emulators for cross-development testing prior to hardware implementation.
This is exactly the kind of unit I would want to use to put an SNES version of a modified version of Contiki and focus my effort of dealing with SNES Expansion Port / Clock Port interfacing and emulation of my ethernet module I have over an SNES emulator via clockport for alpha-testing.
RickB-OR wrote:
I decided that the SNES PowerPak might be a good option for what I am looking at and has the whole setup already done. Only thing might be the potential option for IDE connection
In a way, that's already there. CF is just parallel ATA with a different connector.
tepples wrote:
RickB-OR wrote:
I decided that the SNES PowerPak might be a good option for what I am looking at and has the whole setup already done. Only thing might be the potential option for IDE connection
In a way, that's already there. CF is just parallel ATA with a different connector.
I just want to make sure I can have access to necessary registers to write or store files to the memory card like a little hard drive when I want to. I like to use it for both as a device to run many game roms but also like a hard drive where if I throw in some sort of PDF file and was lucky to make a PDF reader program (speaking hypothetically) for the SNES and load it from the memory card and view it accordingly.
I also see the Super Everdrive which I am also interested in. I may get both, (might not be both at once) but still.
I would want some level of support for that and not be absolutely locked to specific file extensions (of course certain spots like the menus will look for .smc files or .spc files or such but if i place my own FAT file manager/explorer to open & close files within an "OS" like Contiki - that there is no hw barrier in the way of doing that.
I would like to be able to see read, write, erase, modify files and directories on the memory card within whatever OS/app. Of course with the obvious of - if you erase a file, you may lose it or for example, I have Contiki and a web browser running on the SNES and dl game ROMs from the internet from websites through an ethernet module connected via the Expansion connector. From the technical specs that I have read including the SNES Developer's Manual, it would be nice to get that worked out. It does look nice. Would be nice is that one could download the game roms and store it. Including creating directories and dl them to the spot on the CF or SD.
This does not all have to be built into the menu system of the PowerPak or Super Everdrive but the hw features (such as HW registers) necessary to control the CF or SD/MMC microcontroller - when needed or wanted.
Yes, it would be expanding the SNES beyond just a Game Console. But then the Japanese SNES called Super Famicom (shorten for Family Computer) was its intent.
Factor in keyboard and Mouse and voila and lightpen....
Through the networking side, features such as IRC and other stuff would be possible and Contiki already provides that and also FTP support which in turn is giving SNES users the ability to access files from other computers and devices over the network.
Contiki is lightweight enough so it seems to be doable for an SNES. It is for a C64. Just tweak out the GUI front-end with SNES quality gfx.
Emulation in my perspective is for cross-platform prototyping and emulating these carts and an RR-NET ethernet module via the expansion port (which is virtually identical to an Amiga clock port.). The rest is "dumb" circuitry and providing second power and some some sort of means to stand up the SNES about 2"-3" (stable of course) so the module can be plugged in and not interfere with anything from a "mechanical" standpoint. Nothing super crazy.
I'll probably start with Super Everdrive with the Contiki project and then tackle the solution with the Super PowerPak. I see both as great tools.
Dear Friends! Sorry for my bad english cauz i'm french!
I want to make my Snes PAL switchless mode!
I try to find information but its hard about what to put inside the 16F630.
Please could someone be clear about this and just give me the file to put inside??
Thanks again
jims cool wrote:
Quote:
Here's a PIC implementation for the SNES CIC. Key mode only, auto region fallback (requires user reset)
Doing a combined NES/SNES CIC clone is a cool idea, especially since there is no open source NES CIC clone yet.
nice job! guess i'm starting with the nes cic.. then i'll make it universal
i only have 3193/6113 and D411A/F411B so i cant test everything
3197 apparently burns five extra cycles before initialization and first seed transmission is fifteen bits..
heres the seeds if you want to add them to your chip
3193 - USA/Canada
LOCK: $3952F20F9109997
KEY: $x952129F910DF97
3195 - Europe
LOCK: $17BEF0AF5706617
KEY: $x7BD309F6EF2F97
3196 - Asia
LOCK: $06AD70AF6EF666C
KEY: $x6ADCF606EF2F97
3197 - UK/Italy/Australia
LOCK: $558937A00E0D66D
KEY: $x79AA1E0D019D99
Hey,
jims cool, i'm looking
here(3195a-dis.txt) and see SEED for 3195A is:
3195A
LOCK: $f7bef827d78ee15
KEY: $x7bd1217e67a715
but you wrote:
3195 - Europe
LOCK: $17BEF0AF5706617
KEY: $x7BD309F6EF2F97
nescic-dis.txt and here seed is:
NESCIC
LOCK: $1952f8271981115
KEY: $x95212171985715
and:
3193 - USA/Canada
LOCK: $3952F20F9109997
KEY: $x952129F910DF97
and I'm confused, who is wrong?
for some reason I didn't get any email notification sorry
I've been talking with infiniteneslives sent him the pinout so figured I'd post a small info update
this is the pinout I'm using
attiny13 is key only (S/NES)
attiny20/24/44/84 diagram is showing the pinout for "NES mode"
the _FCB and SEL0-3 pins change when the _NES pin is pulled high
I'll post the SNES side of things in the next couple days
uploading some dev photos later.. anyone interested should check back. it's been developed on the atmega8/88 AVR
test carts and/or chips will be sent out to consolingmyself and infiniteneslives. someone who owns a FCB is still needed for testing on the real thing
EDIT: strange I got a "Topic Reply Notification" email but when I clicked the link it said "The topic or post you requested does not exist" never had that happen.. came from this thread
hey what format are these bitstreams in?
http://segher.ircgeeks.net/cic-roms/bitstreams/my guess is it's just the output from the key but thought i should ask just encase i end up needing them
anyway i'm just finishing up now hoping to have the next video of it running uploaded tonight or in the morning.. it will be publicly available early next month
a video of my chip syncing and the random stream getting picked up is in the post above.. didn't want to bump the thread
Awesome news
I got really excited when you first mentioned an AVR solution, then you dropped off the map for several months. I have several attiny13's sitting around that I have no use for currently (accidentally ordered 13's for a project that needed 85's), so this should be interesting. Can't wait to see the final results!
qwertymodo wrote:
Awesome news
I got really excited when you first mentioned an AVR solution, then you dropped off the map for several months. I have several attiny13's sitting around that I have no use for currently (accidentally ordered 13's for a project that needed 85's), so this should be interesting. Can't wait to see the final results!
well i'm back for good now
i didn't think many people cared .. thought maybe two or three
anyway should have another video up today i'm not the best camera man but i'll do my best .. and i'll edit this message so i don't bump the thread or double post
Welcome back, looking forward to seeing this thing in action
consolingmyself wrote:
Welcome back, looking forward to seeing this thing in action
hey thanks for the warm welcome
i was going to email you soon as that video was up!
hope no one thought I gave up.. or worse that the AVR couldn't handle the job.. they are wild animals that need to be domesticated!
I rediscovered something interesting about the SNES CIC
the seed pin (3) is also an output that tells you the direction of the data stream I/O's (pins 1&2)
it could of been a debug out.. maybe for checking the I/O bias of the seed or a friendly programmer hinting at us.. i donno thought i found a problem in my code for second
had a funny/strange setback lastnight someone might get a kick out of... my cat got out and i found then lost him again so i got a flashlight (it's 2:30am) i'm shining it all over the place going up and down the street and the canine unit (police with a dog) show up!. i don't know why someone called them but it was funny.. he's like code 302 just a guy looking for a cat!.. my cat is home now though
anyway as long as i keep injecting caffeine directly into my system and don't blink to often should have that video up sometime today just like i said
EDIT: found my problem.. "X=A" nope I was right the first time
While many users whine about programmers not sharing enough update and information about the development of their anticipated project, you my friend, might be the first one guilty of over-sharing
In any case, I'm eager to see the result of your project and be careful or you might end up having your own reality show
Yeah, it's nice to hear you're still working on this. I've been working on again/off again on a from-scratch repro board, and this will save me the trouble of having to buy a PICKit (I already have an AVR ISP).
i'm kinda p'd off atm.. i'm working out a bug not in my code now but the atmel assembler.. it's giving none existent errors!!!
invalid character '
if the code isn't in the main source it just skips over the include without warning then tells me the labels aren't defined..
i know all the characters are valid i even retyped the whole file to be 100%
.. i have about 20 windows open on three screens. i'm going to close everything restart and hopefully it's a memory leak in atmels software or a windows glitch or something like that.
i've had problems with amel software before..long story short.. they use microsofts xml engine for the emulator..
the problem started last night but i just figured i need some more sleep.. turns out i needed more coffee... next time i'm going to grab the coffee and make sure i need sleep
jims cool wrote:
the problem started last night but i just figured i need some more sleep.. turns out i needed more coffee... next time i'm going to grab the coffee and make sure i need sleep
Hang in there!
I suggest just putting the coffee machine on a high point at your desk. Then simply run an IV drip straight into your arm. When you pass out at your desk you'll know it's time to get sleep.
infiniteneslives wrote:
jims cool wrote:
the problem started last night but i just figured i need some more sleep.. turns out i needed more coffee... next time i'm going to grab the coffee and make sure i need sleep
Hang in there!
I suggest just putting the coffee machine on a high point at your desk. Then simply run an IV drip straight into your arm. When you pass out at your desk you'll know it's time to get sleep.
thanks i needed a good joke
i'm going to uninstall studio 4 and 5 then try the avrasm2 by itself (maybe they are linked).. if that doesn't work i'll write some code that strips invalid characters.
i thought i passed all the technical stuff then this happens..
i'll get past it just a small speed bump on the way i guess
infiniteneslives wrote:
Then simply run an IV drip straight into your arm.
I used to joke that IV (intravenous) stood for the Roman numeral for the number of components: water, salt, sugar, and some drug.
i'm back in business and over the hurtle!
avr studio copies invalid characters.. my guess is one got introduced and caused it to replace all of them because in "notepad" the format was all messed up.. so i used an old trick.. opened it up in "word pad" clicked save.. clicked build and bam! I'm back in business!
glad i finally got to the bottom of it.. think i'll code a preprocessor for future projects.. that was such a waste of my time.. oh well its all over
now i can get back to my project!! awesomeness!!.. step #1 put on the coffee!!
I'm not a big coffee fan myself, but I find that short of coffee, Mountain Dew provides the best caffeine bang for your buck, so that's my preferred method of ingestion
i'm personally more of a tea man.. sometimes i'll grab a couple 2L bottles of pespi
but i'm trying to keep myself away from pop though because of the amount of sugar
I wonder if the assembler has issues with Windows' newline format...
jims cool wrote:
funny how something so simple can waste so much time..
VERY TRUE. I had a problem kicking my butt over the past week. It was even worse too because looking back I was bitterly close to realizing the problem a few times. It was right under my nose...
infiniteneslives wrote:
jims cool wrote:
funny how something so simple can waste so much time..
VERY TRUE. I had a problem kicking my butt over the past week. It was even worse too because looking back I was bitterly close to realizing the problem a few times. It was right under my nose...
i tried fixing the format and it didn't work
atmel basically wasted a lot of my time because they market with atmel studio and think if they open their code someone will make a way better one.. i'm so mad at them i could write an emulator!
i mean that is kinda messed up if you think about it.. i could of had that fixed in 5 min. if i could see the studio code.. it took maybe five six hours. they basically made money from me working.. and i think AVR's are awesome! but i lost all my respect for atmel today.. after this i'm done with studio.. i'm not mad at them just cant read their software so i'll fined or make something open source
qwertymodo wrote:
I wonder if the assembler has issues with Windows' newline format...
some of my older files ended up on my servers.. maybe i had the ftp in text-mode or something.
i'm on xp it's not very fun getting avr studio working on wine i hear..didn't even attempt it because of the xml engine troubles i had on xp..
again shame on atmel for wasting peoples time
Code:
<?php
define('YourTime','none');
define('Marketing','AtmelStudio');
$BS = 'AtmelStudio';
if(Marketing == $BS && YourTime){
for(;;)echo '$';
}
?>
i just came up with that.. feel free to spread it around
just popped into my head when i was looking for any hint at what was going on .. they make awesome AVR's though!!
i like them anyway
EDIT: ... i could of wrote that code better..
alright here is another debug video showing a couple of things
test-video-2.wmvgreen leds from left to right starting at
blinking led = locked out.. the stream from the lock didn't match
the next 4 lights are binary debug codes.. it's only showing two
1000 = high bit came early
1100 = bit didn't match #1 (went low before being read)
not shown
0100 = snes backward I/O bit high too early
0010 = bit didn't match #0
the next led is the AVR's POR lets us know it's running.. when it switches to the next led it's showing we have sync with the lock chip
the 4 red leds show the random 4-bit stream
i just wanted to post a video of some progress.. i'll post more update videos today hopefully of a fully functioning chip
this is way more fun then fixing atmel studio propagated errors
EDIT: i'm working on toggling the AVR's data direction registers .. i'm 99.9% sure the timing is 100% accurate now... if i go of by even 1 cycle (1 quarter of a cic cycle) the whole thing will crash in just a handful of main loops (maybe 5).. wonder why avrs don't have a flag or something for bi-directional I/O's.. lol guess it makes the coding part more fun anyway it's 11:45pm here.. i'm thinking that i'll make another video and upload in the next two hours or so
Your problem reminds my of one of my software professors whose freshman C++ labs basically consist of being given broken code that you have to fix (usually simple logic and syntax errors), then once you check it off, he or his TA's get to break it again. One of his favorite dirty tricks is to replace a single space with an invalid, non-printable character that renders as a space in the IDE. The man is diabolical, but he's an awesome teacher (if you can survive his class...).
found a typo in my seed and wasn't sure how i pulled it off.. thought i double checked... anyway turns out a little typo in the side notes of the seghers dis-assembly was the culprit.. 1952f8271961115 is wrong.. the 0x6 (0b0110) should be 0x8 (0b1000) .. it's all good happens to the best of us .. surprised i didn't catch that though.. oh well
EDIT: after fixing that little gem i figured out the rest of the undocumented architectural stuff .. i'll have it running today for sure now! i spent a bunch of time cross referencing the avr datasheets.. so i know how to cross compile the code for them.. this week i will be exploiting the FCB.. beta binary's will be tested by infiniteneslives and consolingmyself
would of gone faster if my "donated" oscilloscope had wings.. unfortunately i got it in an unusable state from the university and it needs some TLC and i'm strapped for time and money.. i've been building all my tools.. takes a little longer but i learn more so i guess it's time well spent UPDATE: its tuesday already!!!.. infiniteneslives recorded some data streams for me last night turned out i was off by a whopping 1us.
i was "riding" the edge of the that data streams.. lol still haven't accounted for the cycles but measurements never lie.. part of what got me was i'm shifting the bit's in and out in a loop.. instead of one at a time. it saves some room used by delays and makes for an interesting block of code if i didn't have all the seeds in a table and that i'd be out of room already
. wont be satisfied until i know why though but at-least i can get on with it.. i've been looking forward to that 3198 since i got my hands on it! .. =)
UPDATE2: it's thursday working on borrowed time! found a bug in my seed pointer streams work now!.. much easier to debug with streams i know work... some time difference i'm working on that now
encase anyone is wondering about the stream files i asked about.. think they are 1 bit per machine cycle didn't double check that though.. don't need them...i got it working up to the recalculation with the real thing .. so it's sending at least 15 bits both ways and checking them both ways with a real cic in lock mode .. had to wait awhile before i had the chance to test it.. looking at the calc block now.. most likely time again =)
Any further progress on this?
just waiting on some data logs my digital scope needs a little "bling" before it's going to be reliable .. .. i have it looping and everything but the time is off seems to crash after three loops or so.. seems to be depend on the stream number.. logs should show the flaw.. algorithm seems alright going to check all the streams in C and compare them maybe it's a overflow flaw.. it could also couple another problem.. i have time today so while i'm waiting maybe i can figure it out.. i want this done very soon so infiniteneslives can keep his dev cart price down and maybe make an extra buck
EDIT:
Quote:
just waiting on some data logs my digital scope needs a little "bling" before it's going to be reliable
we found another atmel error effecting the attiny13!... i fixed now.. also got goodies i needed to get my scope running.. still needs some work TLC
Quote:
i have it looping and everything but the time is off seems to crash after three loops or so.. seems to be depend on the stream number.. logs should show the flaw..algorithm seems alright going to check all the streams in C and compare them maybe it's a overflow flaw..
typo in my C code was the problem
Quote:
i want this done very soon so infiniteneslives can keep his dev cart price down and maybe make an extra buck
i'm happy with the code but still a few loose ends.. the attiny13 should be full version (universal SNES/NES key only) and infiniteneslives is using it on his boards!
EDIT: tied up most of the loose ends last night.. console select regions switching force ntsc/pal.. eep configuration.. it will fits nice inside the attiny13 with snes and nes key mode support.. attiny2313 support got added by accident.. lots of extras coming to i don't want to get in to all the detail yet.. EDIT2: waiting for some logs.. in the meantime going to turn on the debug outputs and see if it spills the beans .. i have a few hours so if not i'm coding some other stuff =)EDIT4: just noticed the key (d411) doesn't need +5v on pin16 to run.. clock must be powering it.. haven't tested it with the 413 should do the same.. i'm going to play with the time this evening.. not sure how much it will take... code might end up very insane.. i've been trying to prevent that scenario EDIT:5
Quote:
EDIT3: got the logs i needed now! clock works differently on the snes.. should make for fun code!.. yay! code is confirmed on atiny13's now.. i only have mega's.. =)
turns out i heard wrong and the clock works the same and only some atiny13's worked
working on that now.. jumper free mode was added and any region can now be forced now
infiniteneslives hooked me up with some t13's and an extra logger he had to speed things up
Has somebody problems when using SuperCIC in a PAL SNES?
I built my own cartridge with my own homemade board with a PIC12F629 and the cartridge works fine on a Super Famicom but it doesn't in a PAL SNES. When playing on my PAL control deck, the console sometimes resets and keeps reset forever. Then I have to turn it off and turn it on again in order to play the game again (i.e., reset button doesn't work at all), but after a while, the same happens.
What could the problem be?
Your solderwork
Hias wrote:
Your solderwork
In 7 different boards? No, it is not my solderwork
Besides, it works in Super Famicom, so definitely, is not my soldering skills' fault.
Ok, I have solved the problem: one 100nF decoupling capacitor was needed for PIC12F629.
I tried with 10nF but it still didn't work; I also connected to Vcc pin 4 because I had this pin lifted without connection to anything. Pin 4 is /PAIR mode, but it was not clear to me in documentation which value to tie up the pin to. I tried connecting it to GND but didn't work either.
To summarize: 100 nF decoupling capacitor between pins 1 and 8 and pin 4 tied to Vcc made the chip work properly.
You know, I could make an MSP430 CIClone if I wanted. It would only be tested on the G2553, though.
fixed the bug late yesterday effecting atmel tiny13 JCIC's!
waiting to hear back on a larger scale test of t13s now..
i have 5 of them and they all work along with mega8's so things are moving along again
should have something ready for the new year
EDIT: JCIC has been confirmed on 35 tiny13 avrs
EDIT2: HAPPY NEW YEAR!
working on the famicom box/station and snes lock mode switching options now..
i have another fcb cart on it's way to speed things up on that end..
the JCIC is being used in
infiniteneslives.com game carts now! =)
sample chips will be available shortly for around a buck.. mainly so people working on carts will have access
after release in production runs it will cost about $50 for 100 chips!
i'm not setting a release date but it will be soon
So if I understand these posts, the PIC cic replacement works on PAL and NTSC cartridges? And that using this PIC in any cartridge type will enable the cartridge to run on any console and vice versa?
key chip is for homebrew projects.. supports both NTSC and PAL SNES regions
the lock goes in the system and lets you switch regions
my project is a little different but with the same idea...
main difference is the tiny20's will support FCB,NES,SNES in both lock and key modes
tiny13 supports NES/SNES in key only
both versions of the JCIC have eep setting and or jumper settings
jims cool wrote:
after release in production runs it will cost about $50 for 100 chips!
i'm not setting a release date but it will be soon
In other words, you are busting up bunnyboy's monopoly on his $4 a chip nes ciclone chips.
caitsith2 wrote:
jims cool wrote:
after release in production runs it will cost about $50 for 100 chips!
i'm not setting a release date but it will be soon
In other words, you are busting up bunnyboy's monopoly on his $4 a chip nes ciclone chips.
Not only that, but probably selling these AVR JCICs for less than they buy the CIClone's PICs
Is it possible once you're done, we could get a really, really detailed wiki page on the wiki to explain how it works, the algorithm, etc? I'm so curious in how this works and would love to learn how you did it, how the CIC works, and just all of that stuff.
3gengames wrote:
Is it possible once you're done, we could get a really, really detailed wiki page on the wiki to explain how it works, the algorithm, etc? I'm so curious in how this works and would love to learn how you did it, how the CIC works, and just all of that stuff.
never thought about making a wiki page for the project but that sound like a great idea!
caitsith2 wrote:
jims cool wrote:
after release in production runs it will cost about $50 for 100 chips!
i'm not setting a release date but it will be soon
In other words, you are busting up bunnyboy's monopoly on his $4 a chip nes ciclone chips.
even if he released his code now AVR's are more cost effective and the JCIC is universal and has more end user options
infiniteneslives wrote:
Not only that, but probably selling these AVR JCICs for less than they buy the CIClone's PICs
was also thinking about doing that for a pre-release so people can stop paying $4 a chip
if someone was using his boards in production it would be more cost effective to make a JCIC to ciclone adapter board then to buy a ciclone
infiniteneslives wrote:
Not only that, but probably selling these AVR JCICs for less than they buy the CIClone's PICs
jims cool wrote:
even if he released his code now AVR's are more cost effective […]
I know you guys are joking, but … the PIC used for the CIClone is the 12F609, which is basically the same cost as the cheapest ATTiny13. They could switch to the completely compatible 12F1501and it's a little cheaper. (They might even be able to switch to the even-cheaper 10F322, I don't know)
at this point people will save $3.50 a chip using the JCIC for nes
it also has a lot of extra settings
i don't want to start a pic vs. avr war.. they are both good
for my project i thought avr's would be the best option.. turned out well
lidnariq wrote:
infiniteneslives wrote:
Not only that, but probably selling these AVR JCICs for less than they buy the CIClone's PICs
I know you guys are joking, but … the PIC used for the CIClone is the 12F609, which is basically the same cost as the cheapest ATTiny13. They could switch to the completely compatible 12F1501and it's a little cheaper. (They might even be able to switch to the even-cheaper 10F322, I don't know)
No joke, I was just comparing the chip they are currently using for $0.88each on
Digikey, (EDIT: digikey pn: PIC12F629-I/P-ND) with the JCIC being sold for around $0.50 cents at the same cost of the unprogrammed t13a (which is $0.47-0.52 depending on package.) (EDIT: attiny13a: digkey pn: SOIC:ATTINY13A-SSU-ND DIP:ATTINY13A-PU-ND)
Even so, I really don't think they are concerned about pinching pennies to use cheaper PICs. If they were they'd have moved to a cheaper package at least...
It seems links to digikey parts can and do expire. You need to post an actual digikey part number, that can be searched for.
caitsith2 wrote:
It seems links to digikey parts can and do expire. You need to post an actual digikey part number, that can be searched for.
fixed
you still save $3.50 per chip..
if he released it you would save a couple cents and have more options with the JCIC
that and i think people would like a chip by a developer for developers
instead of something that contributed to the further destruction of nintendo carts
it was cheaper to destroy games.. you would get a cic+case for under eight bucks
now it's four bucks for a case
I totally agree that I'm not willing to pay 4$ for a CIClone; I was just being picky about your hyperbole
ya cart cases will be around $2 soon also.. they are $5 dollars now thought they were $4 the other day?
i'm still waiting on my 2nd famicom box cart first stream will run.. but could end up needing the other chip to make a log if i can't crack the seeds with the info i got.. plan B =)
EDIT: the 2nd "famicom box" (FCB) cart came today!
took me about 10 minutes to unpack the thing.. paper, tape, bubble wrap, screws, solder!
mario also gave me a hand with the "custom integrated circuit" (CIC)
Cic question. I have read the posts, downloaded the cic files, bought the 12f629 pics, my programmer has the capability to work this pic, so my question is this: there are 4 files in the cic folder "lock.asm and lock.hex. + key.asm and key.hex. I assumed that the key.hex was the file to program (for cartridge cic replacement) but when I try the hex file, it's wayyyyy too big. So is the asm file the one to use? Or does the file need to be assembled? And how to do that? The PIC has only 1k memory and the key file is much larger than that.
I guess I'm just looking for the right file to directly program. Can I get some direction? I see you plan to sell them. Will they be "locked" or readable? Will it come with jumper instructions for the different applications?
I plan to integrate this into some new cart designs I'm working on....
Thanks
Mark
Intel HEX files should be slightly more than twice the size of the capacity of the thing they're going into.
What are you using to program them? The programmer should tell you if the file's too big.
My programmer says I would need 8 devices (12F629) to program the hex file.
My programmer supports this part. ARlabs.com
Markfrizb wrote:
I see you plan to sell them. Will they be "locked" or readable? Will it come with jumper instructions for the different applications?
I plan to integrate this into some new cart designs I'm working on....
assuming you know the "JCIC" and "Super CIC" are different (implied)
they'll be locked but that's only until it's released and that will be soon.. i'll still offer them programed but not much of a market when people can flash JCIC's at home. the project goal isn't money though.. i'm not making money from infiniteneslives.com using them
think i'll be offering the JCIC and logic on a PCB for SNES consoles in-order to reduce the number of wires required to install
atm i'm working out the famicom box/station.. it works different but i made a bunch of progress on that front. just need to crack the seeds now (far as i know).. but that's the fun part
it will have instructions and pin-outs for sure
3gengames thought it would be a good idea to do a wiki
Hi
I don't plan to resell them but if I have the capability to burn my own, I'd like to be able too.
I'm wanting to make my own cartridges but until I can make one without a MAD chip and don't need to outsource the CIC, I'm hesitant to go forward. Too many times (in the arcade world) a source for ____ (fill in the blank for x part or info) something disappears and then you are stuck. I've learned to try to do as much as I can for myself. I totally understand the desire to recover some of your expenses for your time and trouble. I'd be happy to contribute to that. And it just bugs the heck out of me to not understand how and why something works. I guess I must have the super CIC files. I'm thinking that's why I'm not understanding this...
So you plan to have a pinout adapter for original cartridges? Good idea.
Mark
Markfrizb wrote:
My programmer says I would need 8 devices (12F629) to program the hex file.
My programmer supports this part. ARlabs.com
Are you by any chance importing the HEX file as a BINary file? I just reassembled the source and it uses 510 words of the 1KW in the '629.
If you are loading it correctly, then this sounds like a programmer problem, and something you should bring up with them.
This is where I get lost..... When you say assemble. I tell my programmer which file to load and that's as far as I get...... So another process has to take place before I can load it on the pic?
Mark
In computer programming, do you know what a "compiler" is?
Only in very basic terms. I have done zero programming and know no computer languages.
But a compiler if my understanding is correct, takes language instructions that humans can understand and converges it to machine code.
no i don't wanna make money back i just don't want to release a binary publicly until it has famicom box support.. but if i stop moving forward i'll release it anyway.. i don't want to be known as a data hoarder
when you go to open a fiile your software should have a drop down with .bin selected and it should give an option to select .hex
could also use ponyprog2000 to convert the file and skip leaning about assemblers
you can also get an assembler for the .asm files from
http://www.microchip.com/
Thanks! Ill check that out!
I hope that I can help you guys out if possible.
Mark
Forgive my ignorance, famicom box? Different than the nes I assume?
Is this the big one that was in stores?
I have the hotel version of the SFC if you ever need something tested on it.
famicom box is the japanese version of the m82 display unit
but it holds 15 black nes style carts, has a coin slot attachment and game menu
http://famicomworld.com/system/other/famicombox/i haven't seen much info on the SFCB but the game cart's aren't the normal shape and apparently it doesn't use CIC's... not that i wouldn't enjoy figuring out how to run code on them but i can't afford one.. kind of a deal breaker
Sounds a lot like the playchoice 10. Even coin operated! Are there a lot of those units around??
I don't know if the SFCB uses a cic or not, I can check. I WISH I had a translated English version -- the menu system. The game roms are same as regular Snes roms. I've already changed my roms to English versions. It is possible to add many more games per cart. The menu system is expandable. But I don't know anything about how to do do that .
Mark
its something like the SFCB but it uses CIC's and has the normal carts SFCB also had a coin slot attachment
i've seen photos of the game boards they have menu rom a GAL/PAL and some logic chips..
i don't think english menu patch's exist because the menu rom doesn't run inside an emulator.. i had to patch the FBC menu to get it going when i was figuring out how the menu works
Jim, thanks for pointing me in the right direction on the cic. Another learning moment.
I bought a cheap serial USB programmer off eBay and it was so easy, it's almost embarrassing. Thanks to all who made this possible. Question: does the super cic have a pal feature and how is it enabled if so?
Edit: The reason I had the confusion/problems early on was my programmer can only burn binary files.
Which brings me to my next question. Does the hex file send a read protect fuse command?
It appears it doesn't as I can rewrite a pic but I can't seem to get a binary read from a programmed pic.
Thanks again!
Mark
Don't suppose you have a mad1 replacement in the works???
they are configured using the hex file in the key asm file it looks like this
Code:
__CONFIG _EC_OSC & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _CPD_OFF
you need an external clock to dump the chip
code protect doesn't stop the chip from being flashed
you hit reset to switch the region
the only homebrew on SNES i've seen is N-Warp Daisakusen so mappers aren't high on my to do list.. not saying you would but most people would only use it for modifying carts for pirate/repro junk.. the only thing worse then a smart pirate is a stupid pirate ... mad-1 isn't complicated it would make a good project for someone getting into that sort of thing
Thanks for the reply. The boards I will want to make will be for personal use only. I don't think I'm smart enough to be a stupid pirate anyways.
Last question. If I want to lock it in NTSC mode, how please.
Thank you again!
Mark
lol that's cool.. we would all hate to see nesdev get shutdown for encouraging video game piracy
all you need to force NTSC is change 0x6 in this line to 0x9 reassemble and your good to go
Code:
movlw 0x6 ; died with NTSC, fall back to PAL
as a side note if someone wanted to force PAL you would change the 0x9 to 0x6 in the following lines
Code:
movlw 0x9 ; died with PAL, fall back to NTSC
Code:
de 0x09 ; D411 (NTSC)
jims cool wrote:
all you need to force NTSC is change 0x6 in this line to 0x9 reassemble and your good to go
Code:
movlw 0x6 ; died with NTSC, fall back to PAL
as a side note if someone wanted to force PAL you would change the 0x9 to 0x6 in the following lines
Code:
movlw 0x9 ; died with PAL, fall back to NTSC
Code:
de 0x09 ; D411 (NTSC)
I have tried reassembling the key.asm file to be forced to PAL, but I keep getting error "Illegal instruction" in my assembler (using flatassembler). It fails on the first line "#include <p12f629.inc>". Any ideas or a better assembler to recommend?
getafixx wrote:
I have tried reassembling the key.asm file to be forced to PAL, but I keep getting error "Illegal instruction" in my assembler (using flatassembler). It fails on the first line "#include <p12f629.inc>". Any ideas or a better assembler to recommend?
Flatassembler is
only for x86 code. You'll need either
gpasm (if you're using linux or maybe osx) or mpasm (bundled with
mplab)
jims cool, your pinout a few pages back is a dead link. Could you re-post the pinout? I'm mostly curious whether or not the SNES key connects all of the ISP pins (1, 5, 6, 7, for the SOIC-8 Attiny13) to cart-edge pins or not. If they are, I'll probably rework my project
here for your Attiny-based CIC and replace the PICkit header with an AVR-ISP one instead, which would be really nice...
Since this subject has popped up again, are there any easy replacements for the soic CIC's on the FX carts?
Side note: Jim, if you want to borrow my SFC hotel box, just let me know.
Mark
qwertymodo wrote:
jims cool, your pinout a few pages back is a dead link. Could you re-post the pinout?
qwertymodo wrote:
I'm mostly curious whether or not the SNES key connects all of the ISP pins
i believe infiniteneslives is using the side edge to connect a clip on the PCB and a SOIC socket to program them for another before soldering .. the reset pin is backward so int0 gets used instead
Did you have a pinout for the SNES version as well? I'm guessing it's basically the same, the only question being which is which between IO0 and IO1 (pins 24 and 55 on the cart edge). Hadn't thought of using a SOIC clip. In fact, I just bought myself a SOIC test socket, so I don't really have a need to program the chips in-circuit...
How's the release looking? Even a key-only implementation would be nice to have...
The MISO, MOSI, SCK, and CLK pins are all used for CIC communications so those are routed to the NES/SNES cart connector for you already. The only one that needs to be added is /RESET in order to ISP the chips. But then again I use a avrdoper programmer that provides a CLK signal for ISP. I don't think all programmers provide that so you'd want to make sure you're covered there with your programmer (CLK not SCK)
For NES I route the reset pin to the expansion port (EXP5) so the CIC can easily be programmed in circuit via the 72pin connector. SNES I didn't have a good pin available so I have an extra 10pin connector on the side which is where I routed /RESET it's also used for JTAG programming on the CPLD.
Using a socket works too though. I used a different solution for awhile when I didn't have the reset pin routed to a connector. I'd leave the reset pin lifted when soldering, then I could use a mini grabber clip to get the /RESET pin for ISP, and solder it down to the PCB after programming.
qwertymodo wrote:
Did you have a pinout for the SNES version as well? I'm guessing it's basically the same, the only question being which is which between IO0 and IO1 (pins 24 and 55 on the cart edge). Hadn't thought of using a SOIC clip. In fact, I just bought myself a SOIC test socket, so I don't really have a need to program the chips in-circuit...
How's the release looking? Even a key-only implementation would be nice to have...
i'll release the 8-pin attiny13 version binary within a week or so (maybe sooner) .. supports nes/snes all regions.. think we found a small bug in one of the new config options.. just got back from a two week trip.. the "pin #1/output" of the CIC is pin #5 on the JCIC.. i'll make another with the snes port pins later today.. i didn't want a bug in a release confusing people.. been playing around with the nes fcb also
if i got you right.. you want a lock mode ATiny13 to unlock the mapper?
No, I'm not looking for a lock-mode right now. I'm mostly interested in key-mode.
I've updated my pinout to cover both consoles
also relabeled the I/O's with more generic names to hopefully avoid confusion
the pins are bidirectional.. OIO starts as the output and IOI starts as the input
jims cool wrote:
i'll release the 8-pin attiny13 version binary within a week or so (maybe sooner) .. supports nes/snes all regions..
I found this project not that long ago, and it's sounding very interesting! I've always preferred working with AVR chips over PIC (not that there's anything wrong with them), so it's nice to see someone with a mod that's not PIC-based! Thanks!!
Am I right in thinking that the ATtiny13 version won't work in lock mode? I'm looking for a chip to go in a console, so I guess I'll have to wait for the lock version to be released. Any idea when that will be?
your are correct.. the ATtiny13 will function as a lock but for unlocking mappers on 3rd party snes hardware projects
the other chips will support console switching and has a gal that is used to over ride the region bit
i finally have time to work on this again this evening
Hi everyone
I'm writing this message to get a little help with Super CIC mods on SNES'.
I already performed two SuperCic mods : one on my Super Nes (PAL) and the other on my Super Famicom.
I programmed my PICs (16F630) with a small K150 Automatic Programming USB device and the lock.hex file provided at WolfSoft.de. I scrupulously followed the wiring method on this website.
On both cases, I used duo-leds (red-green-orange) and on both cases, I have 2 problems :
First, the region auto-detection doesn't seem to be working. When the led turns orange, PAL games always run at 60Hz.
Could someone tell me which of the PIC pin is responsible for the auto-detection mode so I can check what I did wrong ?
And second, all of my 40 games work just fine on both consoles, except for Super Mario RPG. (though it works on my unmodded Super Famicom)
Anyone had the same problems ?
Inbound linkThe description of the recently uploaded video
"Secrets of the Nintendo CIC Chip - Early Cartridge Anti-Piracy" by Modern Vintage Gamer links to this topic.
