a databus conflict between OAM DMA and PRG-ROM.

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
User avatar
aquasnake
Posts: 226
Joined: Fri Sep 13, 2019 11:22 pm

a databus conflict between OAM DMA and PRG-ROM.

Post by aquasnake » Mon Mar 15, 2021 9:53 pm

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?

User avatar
aquasnake
Posts: 226
Joined: Fri Sep 13, 2019 11:22 pm

Re: a databus conflict between OAM DMA and PRG-ROM.

Post by aquasnake » Tue Mar 16, 2021 10:29 pm

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).

lidnariq
Posts: 10459
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: a databus conflict between OAM DMA and PRG-ROM.

Post by lidnariq » Tue Mar 16, 2021 10:42 pm

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...

Fiskbit
Posts: 267
Joined: Sat Nov 18, 2017 9:15 pm

Re: a databus conflict between OAM DMA and PRG-ROM.

Post by Fiskbit » Wed Mar 17, 2021 2:12 am

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.

User avatar
aquasnake
Posts: 226
Joined: Fri Sep 13, 2019 11:22 pm

Re: a databus conflict between OAM DMA and PRG-ROM.

Post by aquasnake » Wed Mar 17, 2021 5:15 am

Fiskbit wrote:
Wed Mar 17, 2021 2:12 am
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.
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.

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

Post Reply