nesdev.org

zxbdragon wrote:ax5208。。rom

Sorry, i did not understand what this means.

Man, I really feel stupid!!
Felix, the cat uses PRG-RAM!!!
This should be the main reason it crashes!!
I have made some trial-error with an SRAM, but had no luck.
Could I somehow enable PRG-RAM manually, setting the bus bits with switches or wires?

I think setting the address bus to 1010000000000001 should give me access to the PRG RAM register.
Setting the data bus to 10000000 should enable PRG-RAM, so I would get /CE low and +CE high.
Setting the data bus to 11000000 should enable writes also, so, I would get R/W low.
The doubt I have, before building something to try this is if will I need to set the cartridge's R/W to low when I'm setting the addresses, when I'm putting data to data bus or in both times?
Since I finally got a protoboard, I think would be kind of easy to put a 72pin cart connector on it and do the tests. Hope this don't fry the mapper.

Should I try this or an easier way to figure this thing up already exists?
Maybe Holy Diver Batman! can help?

Fisher wrote:I have made some trial-error with an SRAM, but had no luck.

What have you tried so far? You need to figure out which pins on T1 control PRG RAM /CE, CE, and /WE and connect those pins to the SRAM. (The rest of the pins on the SRAM connect to power and the CPU bus.)

I just soldered it in paralel with PRG ROM, leaving unconnected /CE and /RW, /OE I connected to gnd.
The memory I'm trying is a 61256, it doesn't have +CE. I pulled up A13 and A14. I don't think swapped data and address buses would matter to a SRAM to work fine, will it?

Fisher wrote:leaving unconnected /CE and /RW

These two pins need to be connected to the T1.

Fisher wrote:I don't think swapped data and address buses would matter to a SRAM to work fine, will it?

As long as you don't swap an address pin with a data pin, it will work.

I forgot to say I alternatelly tried them on pins 4, 5, and 6 of T1.

Maybe I need to write a table and track what I have tried and don't, and also try pins 22 and 32 on the mix. I supposed they should be PRG A18 and CHR A18 respectivelly, but this can be wrong.

Also, before pulling up the SRAM address pins, the game started and Felix was killed. I thought It could be some kind of protection against piracy and connected the extra address pins to +5v, but then the game crashed again.

Fisher wrote:I forgot to say I alternatelly tried them on pins 4, 5, and 6 of T1.

Unfortunately, it is possible that the T1 doesn't properly implement the PRG RAM control. Not all clone chips are created equally.

Fisher wrote:Maybe I need to write a table and track what I have tried and don't, and also try pins 22 and 32 on the mix. I supposed they should be PRG A18 and CHR A18 respectivelly, but this can be wrong.

Pin 22 is probably PRG A18. There is no CHR A18 on a MMC3, so I can't imagine what pin 32 might be.

Fisher wrote:Also, before pulling up the SRAM address pins, the game started and Felix was killed. I thought It could be some kind of protection against piracy and connected the extra address pins to +5v, but then the game crashed again.

Holy Diver Batman will tell you when the SRAM is working properly. It might be a better test than Felix the Cat.

Could not find the SRAM control pins.
I have installed a simpler game in this board, Flintstones!!
My daughters loved it!! That was the main objective.
Many thanks for your help in more one modding!!

I hope to someday be able to patch MMC3 rev A or B games to work on rev C chip and vice-versa.
For now, I'll just stay reading docs on my free time and finishing my other projects.

zxbdragon wrote:Felix the Cat needs MMC3A.

[Citation needed]

No emulators implement MMC3A-style IRQs, and yet I can play Felix the Cat in almost any emulator.

Whatever Felix the Cat is objecting to in that hardware, it's not the IRQ behavior. I should probably either move or remove that comment from the wiki, so that it doesn't implicate IRQ behavior.

Fisher wrote:I hope to someday be able to patch MMC3 rev A or B games to work on rev C chip and vice-versa.

As far as we know, currently no mapper 4 games require MMC3A-style IRQs, and the only mapper 4 game that we have on record as requiring MMC3C IRQs is Star Trek: 25th Anniversary.

I foud really weird that Double Dragon 2 took a long time to show it's title screen, with scrambled tiles and crashed in the beginning of first stage. Double Dragon 3 worked fine, but in the Chin's battle he just stay stopped after talking and takes no damage.

This may be due to some bug on the clone's implementation that is hit by these games...
As in this thread viewtopic.php?f=28&t=13698 that I'm trying to fix a bug in a MMC1 clone, a bad mapper implementation seems perfectly plausible.
I have not progressed much, since I'm having problems to find the parts to build the suggested fix.
Looks like it's time to return to that project, since I have finished this one.

I think these findings should go to the wiki, maybe making a page talking about the known MMC3 clones. Should I add it? I would not like to add something that is considered superfulous or useles...

I don't know if it belongs on the MMC3 page itself, but I'd support putting it somewhere on the wiki.

Well...
My english isn't that marvelous, but I'll try to write something usefull.
I think the most important part is the pinouts, so I won't be writting that much...

Maybe I should include the pinouts of some clone's joysticks.
I could not find the full connector's pinout floating around when I needed to adapt a lightgun to it.
One of them even has "stereo" audio out on the joysticks!

Anyway, I would like to ask if someone could do a backup of the wiki if it's not already done regullary.
Just in case I mess up very badly.
I'll start as soon as I found some spare time in front of a PC.
I'm viewing this as a little payback for the very useful help I'm getting here.