Super Mario Bros 1 Menu not working

[miguelfsp]

Thank you 3gengames, all the other bits read from 4016 return 0 (only the 1st bit is set/clear), is that what you mean?

Now, in an act of "dispair" I managed to enter the game by doing this:

Code: Select all

            if (address == 0x4016)
                return this.console.controller.Read();
            else if (address == 0x4017)
                return this.console.controller.Read();

By reading address 0x4016 and 0x4017 from the same controller... AND returning the value "4" (0x0100) after 8 reads

Code: Select all

retval = (n < 8) ? Convert.ToByte(state[n]) : (byte)4;

If I do this, SMB gets fixed, but ALL the other games controls stop working... :/
I also just realized that my ppu scrolling completely sucks...

[3gengames]

Don't hack in fixes. Just work on getting the behavior right. You return only 1 bit right? And you or with $40 for each return byte for open bus, right?

[miguelfsp]

Uh, no? What do you mean? When I return the value from the controller I "or" that 8 bit value with 0x40? I wasn't doing that. Just added it now, but still doesn't fix SMB.

[blargg]

His hack is useful to show that it's likely not something else (like sprites) that's broken, that it probably is with the controller. Now he can change his code back to before the hack and have a better idea of where to focus effort.

[3gengames]

Don't worry about the 0x40 until later. But odds are if you try paper boy, it won't work because you don't emulate that. But also, SMB always had problems using different controllers/switching controllers. But still, is there any more program for reading the $4016 register?

[miguelfsp]

Hi again guys. This keeps getting better and better ... But somehow I got it working...

What did I change? Well... After 8 bytes I now return 4 (100b in binary) and when reading, I read the same controller from $4016 and $4017. I don't know what I changed but that "hack" put my controls to work in all the games...

It really pisses me off getting stuff working without understanding what's going on but ok.

@3gengames I'm also oring with 0x40 but it has no effect on SMB, anyway thank you for alerting me to that. In the future when I start testing other games I doubt I'd ever figure that out if I had a bug!

But still, is there any more program for reading the $4016 register?

What do you mean?

Thank you very much for you anwsers guys. If you want to comment on this "solution" please feel free. Still can't really understand why this would work as the documentation doesn't talk about this...

This SMB seems kinda hard to get it working... My scrolling is kinda crappy and sprites in super mario bros are being drawn too much to the left then they should (what the hell?) and in other games everything works good!

[3gengames]

That oring with $40 fixes PB because of open bus. Instead of doing it just for $4016+17 reads, you should probably do it with every address on your bus that is open bus to keep it easily working with other games in the future. But otherwise, did you return 0's or 1's as the main byte value after the controller is read? After the first 8 reads, a real controller will return all 1's.

[blargg]

It really pisses me off getting stuff working without understanding what's going on but ok.

Your desire to have the games appearing to work outweighs your desire to understand what's happening. If you don't want hacks like that that will fail in the future and force you to revisit the issue all over again and have to review the material that's fresh in your mind right now, don't do them. Work methodically and figure out what the problem might be and test solutions. If you do random things like return 0x04, you're guaranteeing this undesirable outcome.

[miguelfsp]

@3gengames
When a "key" is up, I return "1", when its down I return "0" in its corresponding order :/ After 8 bytes read I return 4 now... But before this hack returned 1.

@blargg
Well I just noticed that this "fix" makes pacman controls STOP WORKING (even thought in other games it works perfectly...).
But after testing and commenting the $4017 read (and returning 0x4), it starts working (and smb stops...). What an annoying problem... The difficulty of writing an emulator is not supposed to be implementing the controls :/...


Hey, maybe SMB requires TWO controls implemented in order to work, and as I'm using the same control for $4016 and for $4017 reads, in my "hack" it's messing up??? Well I'll try this tommorow. Now got to go to sleep as it's very late here in Portugal...

[blargg]

Hey, maybe SMB requires TWO controls implemented in order to work, and as I'm using the same control for $4016 and for $4017 reads, in my "hack" it's messing up???

That would break it. I bet your original code would start the game if you pressed one of the directions. Ignore $4017 reads with regard to the controller.

It's too bad we don't have a controller test ROM. Checking that an emulator didn't treat it as having the same controller connected to both ports (or other state-dependence) would be a good test.

[lidnariq]

I just threw this together. It isn't exactly a test rom because it can't be "passed" or "failed", but it is a diagnostic. It displays lines of dots, which are big if the corresponding button is pressed. The 10 rows from top to bottom are port 1 D0,D1..D4 and then port 2 D0...D4. The reads are interleaved, port 1 first. It reads each port 32 times (the columns), so it's adequate for dumping SNES mouse packets, too. Only problem with it is that the display is so unformatted that it's basically useless without comparing to a known-good emulator or hardware. Source is included.

[miguelfsp]

All right, fixed the bug by creating two controller instances, one of them is read by $4016, the other is read by reading $4017. I'm returning "1" after 8 reads now. Writes to $4016 are common, thought (I suppose that is the correct behaviour and there are no writes to $4017!).

Thank you for your rom, lidnariq, just tested it and 1 control is not affecting the other one (still haven't implemented the keys for the second one thought).

Also I I'm not yet checking if both left/right and up/down keys are pressed at the same time.

Thank you all for your help!

[Dwedit]

If you have MMC3 implemented, you can also try out Chu Chu Rocket as a test case for joypad emulation. For some reason, the game's joypad reading is broken on many emulators, but works fine on the more accurate emulators, and also works on the console.
And if you don't have MMC3 implemented, it's still uses only 32k of PRG all mapped sequentially, so you can pretend that it's NROM with screwed-up graphics. Just to test out the joypad input. When it works, it works. When it doesn't, the game thinks you're pressing a different button than what you are actually pressing.

[miguelfsp]

All right thank you, I'll put that high on my to-do list. I'm currently trying to figure out MMC1 (still no mappers implemented).

[ember]

Hi again guys. This keeps getting better and better ... But somehow I got it working...

What did I change? Well... After 8 bytes I now return 4 (100b in binary) and when reading, I read the same controller from $4016 and $4017. I don't know what I changed but that "hack" put my controls to work in all the games...

for famicom controllers $4016.2 is microphone input(from wiki), is your rom famicom version?