Does anyone know why Mad Max doesn't accept any input from the controller in Nesticle? I ask because I seem to be having the same problem (as well as in Paperboy and Dirty Harry, or so someone who used my emu told me (I haven't checked nesticle on these yet)).

Also, in my emu Battletoads is perfect until you actually get into the game, then the one-screen mirroring is always pointing at the wrong nt at the start of a frame, and so the screen is blank and no sp0 hit happens (the graphics are actually in the other nt). Is there any other reason why the one-screen would switch besides an explicit write to the mapper, or is there some odd method it might do this write that I don't recognize? I can get this to work perfectly by cheating the sp0 hit (not checking the bg), but I know for sure that that isn't right.

-hcs

Are you doing the controller stuff correctly?
Reading from $4016 normally returns $40 for no button, and $41 when a button is pressed. Some games need exactly those results.
Another possibility is that your controller strobing code is screwed.

And you need very good PPU timing to get Battletoads working.

> Reading from $4016 normally returns $40 for no button, and $41 when a button is pressed.

Thanks, I'll give that a try!

> And you need very good PPU timing to get Battletoads working.

Well, as I said, every part of the intro works perfectly, its just when entering the game for some reason the wrong screen is used for one-screen mirroring. I implemented the extra cycle on the crossing of a page boundary in the CPU and that stopped the Battletoads status text from bouncing, but again the game itself wouldn't run at all without a sprite 0 hack.

So its not a slight ppu timing issue, I think...

-hcs

And I don't think the timing required can be all that precise if Nesticle runs it more or less correctly... is there a hack for it, maybe?

-hcs

Nesticle also sets the sprite 0 flag on the first scanline of sprite 0 (the "hacky" way often used by emulators designed to run at high frameskip) rather than on the first pixel of overlap between sprite 0 and the background (the "accurate" way).

battle toad requires accurate cpu and ppu emulation, the mapper itself is a easy to emulate. I couldn't get it to work properly until I emulated the extra CPU cycles crossing page boundries cause.

the exact same thing happened to me, the game would pause at that point becuase of a sprite zero hit with no bg, improved timming fixed it, trust me.

How important is it to set the flag at the correct pixel instead of at the correct scanline? Will it affect many games?

Is that 0x40/0x41 thingy really true as isn't one of those bits indicating whether the Zapper's trigger is down? If that's the case you can't emulate the zapper if you're just gonna return 0x40/0x41.

What I mean is that I've read that bit D4 determines the state of the Zapper trigger. 0 = pressed, 1 = not pressed, so it would make more sense to concatinate 000Z000B with 0x40, resulting in 0x50 when Zapper's not triggered and no button down, 0x51 when Zapper's not triggered and no button down.

[...] 0x51 when Zapper's not triggered and button down.
Sorry.

I'm spamming now it seems :) Just looked it up and apparantly it was bit D3 for Zapper trigger status, so do the math for that bit instead. Maybe emulators that OR with 0x40 don't support Zapper games and thus neglect that bit. But I'd still rather OR button status with 0x48 instead of 0x40, as that indicates the Zapper is not pressed all the time.

If you don't set the flag at the proper pixel, some games will switch the scroll registers either part of a scanline early or part of a scanline late, causing a misaligned or bouncing image.