MMC1 clone with CIC "stun" support?

[Fisher]

Hello.
I have found an old cartridge board on a very dirty deposit.
It was a real mess, and smelling really bad!!
I disassembled, cleaned, dumped the ROMs and scanned the board before reassembling.
The game is Dragon Fighter, an MMC1 game.
I got sad when I created a .nes file and no emulator ran it, but when I reassembled, it worked!!
I just say WOW!! The circuit board and components have taken a lot of abuse, and still work!!
What got my curiosity, is that the board has some connections from the MMC1's clone to something that should be some kind of CIC "stun" circuit.
The actual components are lost and I'm not sure what they should be, but seems to have been composed of a transistor, 2 or 3 resistors and 2 capacitors (my guess).
I think it would be interesting to share both the ROMs and the board's scan, so someone may be able to understand it better than me, or even have a complete board and can tell what are the missing components.
Another question is: can I make it work without the ls32? It seems to be decoding /CE and /OE to the 28 pin CHR ROM. Can I just wire the ROM to GND and make it always enabled or I may have problems?
Thanks in advance!!

PS:
Warning! 600dpi images!!
Board component side: https://drive.google.com/file/d/0B0OtMD ... sp=sharing
Board solder side: https://drive.google.com/file/d/0B0OtMD ... sp=sharing

[lidnariq]

Another question is: can I make it work without the ls32? It seems to be decoding /CE and /OE to the 28 pin CHR ROM. Can I just wire the ROM to GND and make it always enabled or I may have problems?

On some famiclones you could get away without it. On an actual NES, the CHR ROM must only emit data when both PPU A13 (/CE) and PPU /RD (/OE) are low. So you need a 74'32 ... or at least a single OR gate. Why do you want to remove it? (Space? If so, you could buy a 74'1g32, or use a two-BJT OR gate like SROM does. )

The NES PPU uses a "multiplexed" data bus, where half the time it's actually got the contents of the lower 8 bits of the address bus. This is why it's a problem: if the ROM always emitted data when PPU A13 were low it would be driving this multiplexed data bus at the same time that the PPU is trying to latch the lower 8 bits of the address bus.

Several famiclones got rid of this multiplexing, and some games that were explicitly released for those famiclones rely on their lack of multiplexing.

-----

The CRC32 of the CHR is identical to the commercial release: http://bootgod.dyndns.org:7777/profile.php?id=3590

[Fisher]

Nice!!
Gotta try this circuit.
I would like to get a ls32 to try to implement a UxROM on a NROM board.
I already have a ls161!!

Thanks!!

[Quietust]

I just took a look at the two files you posted, and both of them consist entirely of CHR data. Without any PRG, it's not surprising that it didn't work in an emulator...

[lidnariq]

Oh, yeah. http://bootgod.dyndns.org:7777/search.p ... h=f3b41c18 returns the CHR for Batman.

---

Anyway, having traced the board: the pinout of the 9121 (which is probably actually a date stamp, 21st week of 1991) is identical to the standard MMC1. http://wiki.nesdev.com/w/index.php/MMC1_pinout

The supposed stun circuit uses MMC1 CHR A16 and PPU A10 ... not clear how that's supposed to work.

[zxbdragon]

PRG bad dump?

[Joe]

PRG bad dump?

Yes.

[Fisher]

Damm... and I thought the process now should be error free
I'm really not sure if it's really a CIC defeat circuit, just guessing...
It's really weird to have something connected to it.
Maybe some famiclone expect something coming from this pin?

Edit: maybe I should try this: http://www.chrismcovell.com/TapeDump_Controls.html

[zxbdragon]

init 32k,I can analyze MAPPER
In China, this time, at night! sleep!!!!

[lidnariq]

Damm... and I thought the process now should be error free

It's a perfectly correct dump. It's just of the wrong physical ROM. (From the wrong physical game)

I'm really not sure if it's really a CIC defeat circuit, just guessing...

No, it does seem likely. There's no other plausible reason for this pile of stuff connected to CIC DATA toMainboard and/or CIC DATA toPak.

That said, charge pump CIC defeats are not really the best choice; I'd recommend using one of the microcontroller-based clones instead now.

[Fisher]

Sooo... looks like I messed up on the file naming...
Took a look on all CRC32 on the files of the directory... Found it!!
It has the same CRC32 as the Japanese original PRG.
So the chip really is a MMC1 clone, nothing special.
And looks like my dumping process is fine too !!
Can someone try to explain how the CIC defeat circuit should work and why was it connected to the data bus??

Other thing I really want to learn is how do I identify if I dumped the ROM correctly?
It seems pretty easy to you guys!! What should I start reading to learn?

I'm posting the dumped rom, renamed, just in case.
Many thanks!!

[zxbdragon]

Sooo... looks like I messed up on the file naming...
Took a look on all CRC32 on the files of the directory... Found it!!
It has the same CRC32 as the Japanese original PRG.
So the chip really is a MMC1 clone, nothing special.
And looks like my dumping process is fine too !!
Can someone try to explain how the CIC defeat circuit should work and why was it connected to the data bus??

Other thing I really want to learn is how do I identify if I dumped the ROM correctly?
It seems pretty easy to you guys!! What should I start reading to learn?

I'm posting the dumped rom, renamed, just in case.
Many thanks!!

Original Japanese version ROM...

[Quietust]

If it's been established that the ROMs are identical to the original licensed versions, then you should probably remove them from your posts since we don't exactly want to be hosting that kind of stuff here...

[Fisher]

Fine.
Removed the ROMs to avoid problems.
Thanks for the advice!!