Super Mario Bros slides too much

Hi ! After 2 weeks of programming my first NES emulator, I managed to get Donkey Kong working, Karateka working, and probably some others.

Super Mario Bros demanded lots of changes, I had to rewrite my entire video handling since the top bar keep flickering and missing sprite 0 hits, but now it works perfectly.

Except, for some weird reason, Mario has too many momentum, and if I run, he will only stop after 2 seconds. I have no idea what is causing this.

I think it should be logic related, but my cpu is passing all the official opcodes with that nestest rom.

Also, in the demo, Mario dies with the first goomba, again, probably because he cannot stop quick enough to jump !

Since most people here know every emulation bug on SMB, do you have any hints or idea of what may be causing this weird behaviour ?

NESTest is not conclusive. Try blargg's CPU test ROMs.

It definitely sounds like a CPU bug.

My first step would be verifying ROM checksums and checking if it is runs the same way in other emulators. It is definitely CPU bug assuming you have a good rom.

Even if the instructions are executed correctly, sometimes the RAM or memory map implementation might have bugs. Not sure if that's the case here or not.

Perhaps non-sense, but did you check your joypad polling ($4016/17)?

I'm trying to implement MMC1 for that test rom, since it requires it.

I'm gonna check the joypad inputs, weird since they seem to work correctly for other games. I'll see what I can find

Games read the controllers in different ways... Some rely on open bus, or use more than 1 bit from the byte read from the controller register, or expect different results when reading them more than 8 times... There's plenty that can go wrong with input handling, even if it works fine in most games.

Ok so my current logic is this:

when writting to 4016, bit 0 is strobe bit.
When reading 4016, I have an internal pointer that gets a bit from my buttons status, if strobe is 1, returns the current bit of the buttons (ored with 0x40, read somewhere that paperboy needed that), increment the pointer (wraps at 8). If strobe is 0, always return the first bit of the buttons status (A button).

Seems like Mario is always writting 0 and 1 to strobe, and then proceeds to read the 8 bits for the buttons, so it doesn't look like it relies on weird behaviour. But you are the experts =)

any leads ?

It doesn't wrap at 8. Usually it will start returning all 1 bits after 8 (though some devices have other behaviour).

Games don't normally read more than 8, though, unless because of the DPCM glitch.

Ok, changed the behaviour for not wrapping that pointer. Of course this didn't fix Mario's movement but thanks

I'd still maintain this is a CPU emulation instruction or addressing mode bug.

An alternate approach would be to implement a trace log identical to Nintendulator or FCEUX, then compare the results to your emulator.

Also, are you zeroing the memory contents of $0000-07FF in your emulator before the game starts up? Uninitialised areas of allocated memory could result in odd behaviour.

Yes sir, Im doing all that.

I will come back with results once I can run those cpu tests, again, I need to implement MMC1.

Thanks for your help !

All the "rom_singles" tests in instr_test do not need MMC1, so you could try that.

Er, I'm pretty sure that's backwards - strobe=1 is when the button states are copied into the shift register, and strobe=0 is what allows them to be read back.


Actually, it writes 1 followed by 0, just like every other NES game which uses standard controllers.

Managed to fix it.

Turns out my shift left function, was setting carry flag from bit 7 of Accumulator, instead of using the operator passed to the function.

Figured it out implementing unofficial opcodes that use the ASL function.