One theory is that when 6502 is doing OAM DMA, there will be interferences/glitches on the CPU databus. If the external memory is ROM (flash or mask-ROM), there is usually no problem due to the long setup time of ROM accessing. If we use ram instead of ROM (such as ROM emulator device or FDS RAM adapter), high-speed RAM will couple OAM DMA interferences and cause abnormal writing, or they affect each other, it will pass into the sprite buffer inside PPU and cause sprite fragmentation.
Kevtris' patch works fine by connecting 330 ohm resistor in series with PRG data line. Is this reliable?
a databus conflict between OAM DMA and PRG-ROM.
Moderators: B00daW, Moderators
Re: a databus conflict between OAM DMA and PRG-ROM.
At present, I guess that after setting $4014 in vblank, the databus during φ1 period will be occupied by DMA. If prg-ram is written in vblank interrupt, there will be a certain time overlapping drive between φ1 and φ2 due to the inaccurate M2 timing, which will lead to bus competition.
Need to avoid accessing rpg-ram during vblanK, or set a global variable Spr_Flush_Ready to enable OAM DMA operation. But some games don't. There are OAM and rpg-ram operations both in vblank(probably in FDS BIOS).
Need to avoid accessing rpg-ram during vblanK, or set a global variable Spr_Flush_Ready to enable OAM DMA operation. But some games don't. There are OAM and rpg-ram operations both in vblank(probably in FDS BIOS).
Re: a databus conflict between OAM DMA and PRG-ROM.
Isn't it more than just the first byte though? It has to be something lower level than collisions between normal code and OAM DMA...
Re: a databus conflict between OAM DMA and PRG-ROM.
If I'm understanding right, it sounds like you're talking about the behavior discussed in this thread, which affects the FDS RAM adapter, some flash carts, and some modern carts: Graphical glitches on the Everdrive (page 3). If you mean something else, please disregard this post.
These glitches don't seem to be related to OAM DMA, and are in fact most likely to occur on lag frames where OAM DMA is skipped, though this depends very much on the combination of cartridge, console, and vblank workload. The oam_corruption_test_v2.zip archive in the thread linked above only does OAM DMA once at boot, and glitches occur after this depending on the workload. oam_corruption_test_v2.nes allows you to specify a value that is read from zero page RAM and how long during vblank to do these reads, and corruption depends on the combination of these two (some values are more likely to trigger corruption, and spending more time in vblank doing these reads makes corruption more likely).
The best guess as to the cause of this problem is signal reflection. infiniteneslives encountered this problem with some of his cartridges on some customer consoles and did some testing of this theory, finding that increasing the length of the lines between the console and cartridge allowed him to reproduce the issue, and adding resistors on the CPU data lines fixed it.
These glitches don't seem to be related to OAM DMA, and are in fact most likely to occur on lag frames where OAM DMA is skipped, though this depends very much on the combination of cartridge, console, and vblank workload. The oam_corruption_test_v2.zip archive in the thread linked above only does OAM DMA once at boot, and glitches occur after this depending on the workload. oam_corruption_test_v2.nes allows you to specify a value that is read from zero page RAM and how long during vblank to do these reads, and corruption depends on the combination of these two (some values are more likely to trigger corruption, and spending more time in vblank doing these reads makes corruption more likely).
The best guess as to the cause of this problem is signal reflection. infiniteneslives encountered this problem with some of his cartridges on some customer consoles and did some testing of this theory, finding that increasing the length of the lines between the console and cartridge allowed him to reproduce the issue, and adding resistors on the CPU data lines fixed it.
Re: a databus conflict between OAM DMA and PRG-ROM.
Thank you very much for your reference. If it could be expanded, the code execution is put in $e000 - $ffff, and then the test is not only for zero page ram, but also expanded to $6000 - $dfff. It needs to read and write, first write the continuous addresses, and then read and compare.Fiskbit wrote: ↑Wed Mar 17, 2021 2:12 amIf I'm understanding right, it sounds like you're talking about the behavior discussed in this thread, which affects the FDS RAM adapter, some flash carts, and some modern carts: Graphical glitches on the Everdrive (page 3). If you mean something else, please disregard this post.
These glitches don't seem to be related to OAM DMA, and are in fact most likely to occur on lag frames where OAM DMA is skipped, though this depends very much on the combination of cartridge, console, and vblank workload. The oam_corruption_test_v2.zip archive in the thread linked above only does OAM DMA once at boot, and glitches occur after this depending on the workload. oam_corruption_test_v2.nes allows you to specify a value that is read from zero page RAM and how long during vblank to do these reads, and corruption depends on the combination of these two (some values are more likely to trigger corruption, and spending more time in vblank doing these reads makes corruption more likely).
The best guess as to the cause of this problem is signal reflection. infiniteneslives encountered this problem with some of his cartridges on some customer consoles and did some testing of this theory, finding that increasing the length of the lines between the console and cartridge allowed him to reproduce the issue, and adding resistors on the CPU data lines fixed it.
Sprite flushing and ram accessing are used to perform stress test together. Zero page can't be written at all addresses, so it can only do read test.
If there is a read-out error, do not stop the test, but display the error message on the screen, and continue the cycle to observe whether the sprite display is affected