Thanks for the info. I always had that doubt about the mmc3 and i
corrected it in that aspect now.
Regarding the problem it seems there are 2 wich can mess up the emulation. Or The stack is messed up (wich would be a CPU emu bug) or as im allocating memory (malloc) for mappers it seems the "heap" is changed or destroyed (i mean no deallocating). If the prg-addr rom is written i DONT change the prg-rom i mean would be ridiculous since its "ROM" so im using function pointers and an array of byte ptrs to map so it results in "swap" (as you teach me a little post ago).
I think the heap is changed since i have a little MessageBoxFormated() when the opcode is not found wich i pass an str and a value (the opcode) and when things mess up (mmc3) this func. shows any thing.
Im using 16 pointers -> BYTE lpPrgData[16] then i do a ">> 12" to the addr to access memory (read). I use 16 pointers and the "upper" 8 ones are not used (since rom as we know start from 0x8000).
Regarding the "stack" problem i think im doing it well i mean when a value is to pushed into the stack i FIRST write the value in the stack and then decrement it (Cpu.S--) and viceversa for poping i first increment and then read. I think there can be an stack problem since blargg mmc3 irq counter test 1-3 throw me errors in the way that the code i think when an IRQ is generated is popping 3 times the A (PLA) so it increment the stack +3 and then do a RTS.
The last thing i suspected was that the ms c/c++ compiler (im using plain c, i mean i set the option "compile as c code") had errors since i put it to "optimize" the code/speed at maximum posible. But it seems NOT i compiled the emu with mingw and the same thing happens.
Well maybe could be much better to put code in the post and not such large explanation of how i do things, but it would take a lot of code and maybe some things could be voided wich would result in problems.
I ask and i beg for help