Hello guys!I hope I have some good news here! We finally managed to fix Battletoads level 2 and Megaman 5 issues with our emulator!

Just yesterday Foomarumota and myself got together to check a "simple" issue with Megaman 5 that was causing a shaking bar when selecting a stage, we thought it was going to be easy, but what i found out was that sometimes the screen split was being set before tick 256 (exactly at tick 255). Something important to notice is that at tick 256 there is a Y-increment for loopy_v. if the split is set after 256 the split would stay but if the split is set before 256 it would be fine-y-incremented at tick 256, resulting in a different behavior, lowering it one scanline.Battletoads suffers the same, it enables rendering just after tick 256, but sometimes at level 2 it would enable rendering at tick 255, resulting in lowering background one scanline and this will make zero-hit miss and freeze the game.

So after spending some time thinking about how we could fix this synchronization issue, we decided to adjust only one timing, we decided to set the Y-increment at tick 255, only 1 tick before, and this fixed both issues!We had a problem before with Bart vs space mutants and the status bar, it would shake. We fixed that before, but after making this timing adjustment Bart vs space mutants is still working OK.

With all my PPU knowledge (which is not too much) I think this adjustment is fair enough. I don't see it as a hack, since it's just one tick adjustment, this applies for all games and I don't think it would interfere with the normal PPU behavior too. I cannot see any bad consequence so far for doing this for the PPU, the CPU or the synchronization between both too. Please feel free to correct me if i'm wrong!

So my intention with this post is to return a little to this big community which has help us learn a lot of knowledge, and see if this can help somebody else, we have seen these 2 games to cause a lot of questions in the forums, so maybe this adjustment would be good enough for other emulator authors to try it. Also I would like to see if you guys in your own experience know what games/tests could fail if someone implements hacks to fix Battletoads, so we can try them and check what happens, because so far we haven't seen any failure because of this change.

@zerooneWe have been trying test ROMs and everything is passing, except for the ones that test not-yet-implemented features, (apu, sprite overflow, unofficial opcodes). Basically tests that were passing are still passing.

@zepperI tried that game and the adjustment fix that game for us, now the game is not shaking anymore.

This is unrelated we think, but we still have problems with both Mickeys, both Startropics and Kick Master. All games work ok, you see the title screen and everything, but when the actual game starts we see a black screen.

@ZepperI think it depends totally on how your emulator works, specially how you programmed the synchronization between PPU and CPU.At least for us, the scanline starts from tick 0 as you do too. Because how the synchronization works in our emulator everything in the PPU is coded one tick before, so that would mean if the wiki says Fine-Y-Increment is at tick 256, in our actual code you would see 255. That being said, all the timings are coded like that, except for the adjustment we are talking about here, in our code is a 254, that means one tick before the normal timing. But again, I think you need to check how your synchronization works between your PPU and CPU.

I think it depends totally on how your emulator works, specially how you programmed the synchronization between PPU and CPU.

PPU runs for 3 cycles, then the CPU (1 cycle) - NTSC mode.

Quote:

At least for us, the scanline starts from tick 0 as you do too. Because how the synchronization works in our emulator everything in the PPU is coded one tick before, so that would mean if the wiki says Fine-Y-Increment is at tick 256, in our actual code you would see 255. That being said, all the timings are coded like that, except for the adjustment we are talking about here, in our code is a 254, that means one tick before the normal timing.

The first reply (after reading a tracelog) was... "your sprite zero is off by 1". Putting -1 PPU cycle has fixed the shaking scorebar in "The Simpsons - BvsSM", but the sprite tests were broken. The same for MMC3 IRQ-hell... put 1 cycle earlier (or later?) and the things are nice. Really, I don't know what to think about. ^_^;;

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum