- Is possible to create a set of test ROMs to check Battletoads' Impact Crater issue (stage 2)? I'd like to know exactly what could break the emulation during that stage...
Would you mind letting us know what the issue is? I'm out of the loop because I don't know what the stage 2 issue is. One issue I spent a log of time on in my emulator is the insanely small margin it has in the timing of enabling PPU rendering several scanlines late in the frame (which is why the colors shimmer more on a NES or accurate NTSC emulator). It's something like a 5 CPU clock timing margin. Do a log and watch the two writes to $2006, then two to $2005, and finally one to $2001, around 4043 CPU clocks from VBL (code at $85CF).
And just so you don't go chasing another non-bug, remember that pressing left and right at the same time makes your toad rise into the air, never to fall again. It happened to me more in the Snake Pit, where you're changing directions frequently. I thought it had something to do with the same issue as in stage 2 (Wookie Hole as I've seen it referred to as), and wasted a lot of time on that.
Like blargg said, the issue can be anything. The result is probably a lockup ?
I've noticed that problem early in development, and it was caused by bad PPU<->CPU synchronisation (they were not running exactly in parallel). The result was (probably more):
- lockup in Battletoads stage 2
- lockup in Battletoads vs Double Dragon stage 1
- small graphical glitch in Marble Madness' textboxes
It could also be due to bad DMC emulation; timing or DMA sample transfer.
I believe I ran into similar issues some time in the same level. Here are some things to look into:
- Are NMIs being requested at the proper stage? If NMIs are generated one instruction too early (or one instruction too late) the game will hang;
- Do sprite DMAs take 513 CPU cycles as opposed to 512?
- Do you update the vertical counter at cycle 251?
I did think this issue would be common... guess I was wrong.
Basically, the game hangs randomly during the stage 2 (vertical tunnel). I traced the code and a sprite #0 strike does not occur... OR there's an infinity loop trying to read 2002:40h which is zero.
Hint: look at item #1 in my post. That is what's probably causing it to hang (same happened to me).
Hehe, I can tell Fx3 is encountering the same problems I did. If that critical code I mentioned is run just a few clocks too early or too late, it will update VADDR at the wrong time, causing the status area to be one pixel too high or too low. This will cause the tiny target for sprite #0 hit to miss and for the sprite #0 hit polling code to hang. This means that the NMI the PPU's updating of the vertical scroll counter in VADDR must occur at the proper time (as well as anything else that occurs between them, like instruction timings and sprite DMA, if it's being used). I am pretty sure it doesn't use DMC samples, so that's not an issue.
How did Nesticle manage to even run battletoads without crashing?
Simple: it didn't force sprite 0 to collide with the background - it merely required it to be rendered. Lots of emulators used to work that way.
Hyde wrote:
Hint: look at item #1 in my post. That is what's probably causing it to hang (same happened to me).
Well, I didn't made any deep analysis yet but... if NMI test ROMs are OK, so I suppose my NMI timing is OK too...?
When debugging, assume as little as possible. There is no way to thoroughly test the behavior of any aspect of an emulator. Depending on how complex your NMI implementation is, it could have subtle issues. But given that Battletoads relies heavily (exactly?) on timing, you might check your PPU timing next. When do you increment the Y scroll in a scanline?