the iNES mapper #7 AOROM.
In my emulator,
running BattleToad and BattleToad&DoubleDragon,
everything is ok in demo screen, title screen and character select screen.
but died right on starting the game which is after the demo following role-selection.
I know that it need precise timing. But that's all.
Would anyone explain what the game is toying with about cpu/ppu timing ?
thanks !
My understanding is that Battletoads was originally designed for PAL, which has a much longer VBlank time. When it was ported to NTSC, the developers had to buy more time to do PPU updates, so they turned off PPU rendering in order to give them more time. Thus, when they turn rendering back on, the PPU is past the dummy pre-render scanline (where the scroll counters normally get reset), so they have to reset the scroll counters manually with well-timed writes to $2006. In order to emulate this game properly, you have to be VERY accurate in CPU/PPU synchronization. If Battletoads' attempt to activate the PPU occurs a smidget too soon or too late, the counters won't get set to the proper initial values, causing the screen to be offset and resulting in a failed sprite 0 hit (sprite 0 is only one pixel, so it is very sensitive to the screen contents being drawn at the right spot).
Yep, it's probably sprite0. Try manually setting the sprite0 flag and seeing if that works. Accuracy REALLY has to be on the ball for sprite0 to hit in this game. Now if we had not produced games in Europe in the first place this wouldn't have been a problem.
so I know the reason.
It need mid-scanline emulation as least.
I am just writing a rough scanline-base one.
Still a long way to go...
Thanks, Dvdmth !
hey, laughy reply at that very moment...
Seems a good idea for testing, I'll try it.
Thank you, too !
Emulation accuracy is often referred to as if the entire emulator must be to the same accuracy. This is no the case; parts of the emulator can be more or less accurate than other parts. Few games need mid-scanline rendering accuracy, but many games need mid-scanline accuracy for PPU status register readsand scroll registers. Emulating cycle-accurate PPU rendering is significantly more complex than just emulating $2002, $2005, and $2006 accurately and rendering graphics with only scanline accuracy.
Theoretically, emulating PPUSTATUS ($2002), PPUSCROLL ($2005), and PPUADDR ($2006) with cycle accuracy requires rendering with cycle accuracy because something might change the scroll position and thus the pixels under sprite 0, causing sprite 0 not to be triggered and PPUSTATUS to be incorrect.
tepples wrote:
Emulation accuracy is often referred to as if the entire emulator must be to the same accuracy. This is no the case; parts of the emulator can be more or less accurate than other parts. Few games need mid-scanline rendering accuracy, but many games need mid-scanline accuracy for PPU status register readsand scroll registers. Emulating cycle-accurate PPU rendering is significantly more complex than just emulating $2002, $2005, and $2006 accurately and rendering graphics with only scanline accuracy..
Yeah, how do you accurately emulate $2002, $2005, and $2006 while still using scanline rendering? If by accurate you mean the correct data is displayed on the screen, then no I don't see how that's possible. Although would you consider queuing all writes to these registers and processing them at the end of a frame "frame rendering", in which case it's still cycle accurate rendering
I'm just a little confused
Sorry, I wasn't specific enough. I meant emulating $2002 to cycle accuracy, and $2005 and $2006 writes to PPU cycle accuracy during HBLANK (when they usually occur to change vertical scrolling). A few games write to them mid-scanline, so these would require a more accurate scheme.
My unstand is that keeping accuracy on writting to ppu register is simple. but is a little complicated on reading.
In fact, in my emulator(and may be so for other scanline based ones), any write to ppu writtable register update all relative status data. But not for $2002 flags until render finished(usually in 256 ppu cc or end of scanline).
I read some VirtuaNes source, and found that it render scanline in different time for different games. For BattleToads, it use PRE_ALL_RENDER, which I considered as rendering the scanline before execute CPU instructions(I haven't read this parts). Change it to other method such as POST_RENDER, the game holds.
Is the following method ok?
keep status about the current scanline-rendered position in some variables . If some instruction change or read from ppu register, render the scanline from last position to current one, and update the position status. Then $2002 is aslo synchronized.
does this work for all games?
and how much impact on speed?