Page 10 of 17
Posted: Sun Mar 13, 2011 2:55 pm
by Jeroen
^^I think he removed that.
Posted: Sun Mar 13, 2011 4:09 pm
by Link83
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.
Posted: Mon Mar 14, 2011 8:55 am
by thefox
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.
Posted: Mon Mar 14, 2011 10:07 am
by kevtris
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.
Posted: Tue Mar 15, 2011 7:58 am
by Link83
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

Posted: Mon Apr 11, 2011 6:29 pm
by jims cool
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 
Posted: Tue Apr 26, 2011 10:15 am
by Hilmarf
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?
Posted: Tue Apr 26, 2011 11:41 am
by Hilmarf
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.
Posted: Tue Apr 26, 2011 1:02 pm
by ikari_01
Can you take photos of your mods?
Also, does this happen with all games or just with carts equipped with a SuperCIC key?
Posted: Tue Apr 26, 2011 1:30 pm
by Hilmarf
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.
Posted: Tue Apr 26, 2011 1:47 pm
by ikari_01
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?
Posted: Tue Apr 26, 2011 1:54 pm
by Hilmarf
"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 ^^)
Posted: Tue Apr 26, 2011 2:08 pm
by ikari_01
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.
Posted: Tue Apr 26, 2011 2:16 pm
by Hilmarf
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.
Posted: Tue Apr 26, 2011 2:17 pm
by ikari_01
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.