nesdev.com

I fixed the PAD problem, Thwaite works 100%.
Pacman works, except I have no sound while the sound routine executes.

Thanks for the solution AWJ, I could find a way to emulate it by using the bit 8 of the object data.

Congratulations. Do you have the mouse that came with Mario Paint?

I do not have the mouse for the snes.
Edit: Plus it is a rare object, it could be tried on an emulator?

Using the FCEUX debugger, I found out why PACMAN does not play music:

STA ($F6,X) @ $4000 = #$FF

It writes in the sound port using this direct indexed thing. X is 0 by the way. $4000 is in the direct page at $F6. It must be patched by hand, like adding an asm file containing a custom routine, and calling it from a patch at this address. This cannot be automatic, the address checks would slow everything down.

Edit: doing like Memblers in the NSF player should also work: executing from the WRAM and reading the register values from WRAM @ $4000 to $4015.

Hello.
I managed to execute the converted rom from work ram. It is how Memeblers emulation works because there is no need to patch the accesses to $4000 - $4015, it writes directly in WRAM to this address range.
I did this because pacman accesses sound registers in a way that cannot be detected when disassembling.

However, it does not work 100% yet, the sound is weird I must have missed something because pacman hangs.

There is one thing to watch out for when you execute from work RAM, you might have seen this already, but it is surprisingly common to find code that writes to zeropage with absolute mode. So they'll do something like STA $0000 / LDA ($00,y). But with direct register page allowed in bank zero only, and the data bank register being in WRAM, $00 and $0000 are different places. In my NSF player, I had to patch that code manually. In the NSF it was usually just 1 or 2 spots where that would happen, but there was at least one game where every single ZP access was in absolute mode (I didn't even bother with that one).

Thanks Memblers, I was not expecting this behaviour. I must look at this.

As I understand it, that can be worked around by running the NES program from bank $7E, as $000000-$001FFF is a mirror of $7E0000-$7E1FFF.

One plausible scenario is to assign to X and Y the indices of two elements in the same array and access one element with dd,X and the other with aaaa,Y, as the 6502 lacks dd,Y mode for most instructions that aren't LDX/STX.

Maybe it could work if using bank $7E. The lower 8KB of bank $7E is the same ram as the $00 bank. And I use $7E as data and program bank. I converted the following code (using the nes palette test rom) and it works:


It loads $34 from $00CC in A ($918 is my breakpoint address).

I am close to fix the audio, I may have forgotten some IO request in the $7E bank.

Pacman passes on WRAM, it plays sound.

I tested upernes from a fresh clone and it works (on needs to write the indirect jumps and then disable the tests on them, but once this is done, it works).

Sound is a little weird however, like when I first integrated it. But it plays more sounds than by using the IO patching method. I assume it is because it missed sound IO accesses when disassembling and now it is read from the WRAM at $4000. Maybe I should do a video to show the problem, not today however.

I was thinking about using upernes on NSF files. If they are like maper zero roms, it should work?

If all the starting bank number bytes are 0, then it's essentially the same as NROM, except:

• Valid data starts at the load address instead of $8000.
• Init ends with RTS instead of forever: JMP forever.
• Play ends with RTS instead of RTI.
• Audio registers and RAM outside the stack need to be initialized.

Thanks tepples. Hence it is mapper 0, upernes could be adapted to work with this. It would help to improve upernes sound accuracy (it actually does not work very well).