Is there a debug version of Nestopia?

[infidelity]

Im working on an MMC1 to MMC3 conversion. Im using FCEUX 2.2.1 as my debugger, and this conversion works perfectly on FCEUX, but the rom wont boot on a powerpak/Nestopia/Nintendulator.

Nestopia keeps giving me a cpu jam in the log file, but it doesnt give an origin for the issue/illegal opcode.

I ran my hack through FCEUX with the break on bad opcode activated, but the debugger doesnt snap.

Ive rewritten my work three different times, and I can figure out what is going on.

Is there a debug Nestopia???

[qbradq]

You should probably try the Nintendulator debugger and single-step the code from power-on. My first guess without seeing your code is that you've got your reset vector in the next-to-last bank instead of the last bank, and the emulators that properly emulate the unknown power-on state are freaking your proverbial brainz. Remember that for MMC3 the only known state at power-on is that the last bank will be hard-wired at $C000. The second fixed bank's address is unknown at power-on.

Good luck!

[infidelity]

My reset vector is within $C000. Thats where it originaly is in its MMC1 form, and currently with my MMC3 hack.

Im not familiar with the bells and whistles of other emulators. Could you explain how I perform this on Nintendulator?

Im not home right now, and I dont have my notes with me, so I cant get explicit with detail on where my mapper setup is jsr'd to within the hard wired bank from the reset vector asm.

[tepples]

Reset vector must be at $E000-$FFFF for MMC3. The mapper could be booting into the state where the second to last bank at $C000 is swapped with the switchable bank at $8000. After you write a value with bit 6 clear to $8000, you may access $C000-$DFFF.

[infidelity]

So, could I have $FFFC-$FFFD goto $E000, set bit 6 of $8000, then jsr to within $C000 to load the rest of the reset vector/mapper setups?

[tepples]

Yes. But it's really only about 28 bytes to init everything.

[infidelity]

I understand, but $E000-$FFF9 is embedded with DPCM sfx, so the less code possible, the less noticeable difference in the sound being initiated.

[lidnariq]

Your life will suck a lot less if you swap the 8K of DPCM and fixed code.
The alternative is to put init code in every 8k slice over the entire ROM.

[qbradq]

Woops, got my address wrong Yea, your init code needs to be between $E000 and $FFF9. Why don't you look at $FFF0 and see if you can put your trampoline there. A lot of games have that semi-standard header information there you could overwrite. If it really is used to the last byte with DCPM data, then hopefully folks won't notice those few strange samples

[infidelity]

Thank you everyone!