Need help about a Sprite rendering issue in Road Fighter

[GorgonMeducer]

Hi,

I have encountered an issue which I cannot understand. If the sprite buffer is enabled, the Road Fighter will render incorrect sprites. The sprite buffer works well with Super Mario Bro and City Tank

Please help.

Cheers,
Gabriel

[semiversus]

Will have a look at it.

[GorgonMeducer]

Thank you.

[semiversus]

Was looking into the old problem of failing test roms on my side. Maybe it' the same issue with Road Figther: ppu_dma_access is asserting for ppu->oam_address to be 0, but this is possible and has a defined behavior. The destination address starts with ppu->oam_address (which is usually 0) and wraps around at 256 bytes (when oam_address is not 0).

I fixed the unoptimized code via ppu->tSpriteTable.chBuffer[(ppu->oam_address+i) & 0xFF]=v;. You're able to imitate this behavior with two memcpy calls

[GorgonMeducer]

What you said is correct, but the issue I encountered might be different. Because, if I disable the sprite buffer(JEG_USE_SPRITE_BUFFER == ENABLED) and keep normal dma optimisation ( JEG_USE_DMA_MEMORY_COPY_ACCELERATION == ENABLED) , the issue will disappear.
the assert() in Cortex-M is implemented as a software breakpoint (system will stop here permanently). But when I encounter this issue, the emulator can run without any stop. So that is not the case.

[semiversus]

OK, will investigate further - but now going to sleep ;-)

[GorgonMeducer]

Good night, I will add the fix you mentioned.

[GorgonMeducer]

Is there any update about this issue?

[semiversus]

No update on this

[GorgonMeducer]

I have been thinking about this issue. It implies that we haven't fully understand the PPU scheme yet, that's why we can not find the issue. I believe solving this issue would help us to understand the ppu behaviour more.

[semiversus]

Yes, that's true. I started to prepare two other nes emulators to deliver debug data (dumping every ppu access) and compare them with dumps from our emulator. I think this will help to detect the origin of the problem. Another idea (which would have a lot of work involved) would be to hook up a real NES and trace the busses and compare them with our emulator (given the exact same controller inputs). I don't know if anybody has gone so far - but this would be the real proof ;-)

[GorgonMeducer]

hooking up a real NES would be the ultimate solution, but I guess it's complicate.
My suggestion is, maybe we can add some trace feature to the emulator and generate tarmac log which can be further investigated.