Split from here
Oops again! I wasn't thinking about Codemasters at all - I was thinking about Tengen (and possibly other US-based unlicensed developers) whose CIC clones/defeaters could possibly screw up in famiclones.
As I understand it, CIC defeaters screw up in Famiclones only if they screw up in the top-loading NES. Codemasters games published by Camerica allow switching off the CIC defeater, right?
I have Micro Machines and Bee 52, and each cart has a switch that has something to do with defeating the CIC, but I don't know what each position means. What I know is that neither game works on my NES. I can see the Codemasters logo forming, but then it resets and this repeats forever. They only seem to defeat my CIC momentarily.
Actually, that means it's not defeating the CIC at all. From what I understand (my own experiences bear this out,) a failed authentication just causes everything to be reset after 1/2 second.
Well, this is it then. Those carts can not defeat my CIC no matter the position of the switches.
Do the Color Dreams carts work, especially the later Wisdom Tree releases based on the Crystal Mines engine (Exodus, Joshua, Spiritual Warfare)?
Splitting...
I don't have any Color Dreams carts...
Most of the lockout defeaters just put -5 volts onto the CIC with a charge pump. Camerica carts had only one sequence, handled entirely by circuitry on the cart. But Nintendo locked out the Camerica carts by putting some passive elements around the CIC in later NES board revisions. Color Dreams carts adapted by using about nine different software-defined sequences to attempt to bypass the passive elements and freeze the CIC without overheating it, changing sequences after every reset.
Are there any known problems with Color Dreams' later method? (besides having to wait thru lots of screen flashes before the game boots)
With all cic crashing defeaters, the reset button on the front of the console will no longer work. This isnt a problem for almost everything, but could have problems for battery backed games that want the reset button held down when you turn off power.
tepples wrote:
But Nintendo locked out the Camerica carts by putting some passive elements around the CIC in later NES board revisions.
That's probably my problem. My NES is one of the modified NTSC NES's officially sold here in Brazil by Playtronic. Since these started selling in 1994 (the year printed in the extra board it contains to convert the NTSC signal to PAL-M - wich I tried to remove without success!!!), I'd guess they are pretty late revisions.
bunnyboy wrote:
With all cic crashing defeaters, the reset button on the front of the console will no longer work. This isnt a problem for almost everything, but could have problems for battery backed games that want the reset button held down when you turn off power.
Did any North American unlicensed boards with a charge pump have SRAM at CPU $6000, let alone battery backed SRAM? All I can see are Color Dreams (GNROM clone), AVE (NINA series), and Camerica (UNROM clone).
I don't think there were any with SRAM at all. Unless someone can prove me wrong with some obscure title. I wonder if there were even any pirate NES carts of games that used batteries. Due to the expense, I doubt it.
I dont know of any boards that have it, I was mainly thinking about homebrew carts where they wouldnt be using a mapper chip with sram write protection. Or with special hardware that requires a reset signal to initialize registers....
bunnyboy wrote:
Or with special hardware that requires a reset signal to initialize registers....
Any cart can get a reset signal by comparing the CPU address bus to $FFFC.
tepples wrote:
bunnyboy wrote:
Or with special hardware that requires a reset signal to initialize registers....
Any cart can get a reset signal by comparing the CPU address bus to $FFFC.
But that requires monitoring a lot of address lines. Almost all of them. So it'd have to be pretty important to warrant that kind of treatment, heheh.
tokumaru wrote:
tepples wrote:
But Nintendo locked out the Camerica carts by putting some passive elements around the CIC in later NES board revisions.
That's probably my problem. My NES is one of the modified NTSC NES's officially sold here in Brazil by Playtronic. Since these started selling in 1994 (the year printed in the extra board it contains to convert the NTSC signal to PAL-M - wich I tried to remove without success!!!), I'd guess they are pretty late revisions.
I'd say your best bet is probably to just cut pin 4 on the CIC. It's not that hard if you go slowly and carefully; I did it with a razor blade in about half an hour and I've had no problems with it since.
tepples wrote:
bunnyboy wrote:
With all cic crashing defeaters, the reset button on the front of the console will no longer work. This isnt a problem for almost everything, but could have problems for battery backed games that want the reset button held down when you turn off power.
Did any North American unlicensed boards with a charge pump have SRAM at CPU $6000, let alone battery backed SRAM? All I can see are Color Dreams (GNROM clone), AVE (NINA series), and Camerica (UNROM clone).
The NINA-001 board has WRAM according to
the wiki - is this right, or are the bankswitch registers r/w for some other reason?
Memblers wrote:
tepples wrote:
Any cart can get a reset signal by comparing the CPU address bus to $FFFC.
But that requires monitoring a lot of address lines. Almost all of them.
You mean like the 13-input NAND plus a decoder on NINA-001? And is there any other way to get a reset signal on, say, the 60-pin Famicom connector?
85cocoa wrote:
tepples wrote:
bunnyboy wrote:
With all cic crashing defeaters, the reset button on the front of the console will no longer work. This isnt a problem for almost everything, but could have problems for battery backed games that want the reset button held down when you turn off power.
Did any North American unlicensed boards with a charge pump have SRAM at CPU $6000, let alone battery backed SRAM?
The NINA-001 board has WRAM according to
the wiki
I stand corrected in part, but is there a battery?
I read once about a board design that used A0 to detect a reset. It turns out that, during normal operation, A0 never stays the same for longer than one 6502 instruction, since the CPU always fetches two consecutive bytes at the start of each instruction (the opcode and the byte following the opcode, even if that byte isn't needed). Of cour,se, this detection method may yield a false positive if faulty code should cause one of those undocumented CPU-killing opcodes.