It is currently Sun May 26, 2019 2:27 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Fri Jan 06, 2017 10:33 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
tepples wrote:
Mail from the wiki is broken right now. Try not providing an email address when signing up. Because mail is broken, you'll need to autoconfirm (2 talk edits and 4 days) or wait for me or another administrator to wake back up and confirm your account.
Yup, that worked. If someone could confirm the account (same username as here) that'd be nice - no hurry though, I'm not planning on editing this right away :p


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 4:50 am 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
I tried to write a test that involved watching for corruption while doing repeated synced joypad reads, with the goal of identifying whether the emulator supported this method of reading. Surprisingly, despite being synced, I was encountering corruption when testing on Mesen.

What I learned was that if your synced region is long enough that two or more DMAs can occur during it (about 430 CPU cycles at minimum, I believe), then you need to ensure that all consecutive write cycles in the routine end on an even cycle; otherwise, DMA landing on that write will take 3 cycles instead of 4. For example, when using ROL on memory, the second write cycle must be even so that DMA that tries to occur on either one is forced onto the following odd cycle, where it will take 4 cycles. Without this, the cycle parity changes, allowing future reads of controller registers to occur on odd cycles where they're subject to bit deletion.

In addition to repeatedly reading the joypad, this seems likely relevant for handling Four Score because of how much time is required to read everything even once.


While I'm reviving this old thread, I'd like to note here on the topic of OAM DMA on PAL that testing done in this thread indicates that if your OAM DMA fits within NTSC vblank, it should also be fine on PAL, so it does not appear that different behavior needs to be taken depending on the region; ending vblank with OAM DMA and joypad read should work either way.


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 9:38 pm 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
By testing this on real hardware via Everdrive, I believe I've been able to confirm this write behavior, and also discovered that the only emulator that seems to be getting this totally correct right now is Nintendulator 0.980. Testing this is a bit tricky because it seems that you can have timing alignments where the DMA avoids landing on certain cycles of the loop, which can cause it to miss an odd write cycle (manifesting as tests showing black when they should show white), but I found that by adding variable delay into the loop, it seems to land on the target cycle reliably. I'd appreciate another set of eyes on this to make sure it all makes sense, but I'm fairly confident in the results because my test ROMs show different behavior despite the only meaningful difference being the timing of the ROL write cycles (all other timing, code positioning, and register values remain the same).

I've attached two modified versions of dma_sync_test_v2. Both of these change the loop to no longer include the OAM DMA, so code has to stay synced indefinitely for the controller port reads to work reliably. They also add a variably delay to try to mix up where DMC DMA lands within the function. The difference between these versions is in the second ROL instruction, which ends on an odd cycle in badrol and an even cycle in goodrol. badrol is expected to exhibit bit deletion (screen turns white) because DMA landing on the odd ROL write cycle (cycle 5/5) will be delayed by 1 to an even cycle and thus take only 3 cycles, changing the parity so that future joypad bits can be lost. goodrol is expected to never encounter bit deletion (screen stays black unless right is manually pressed) because DMA landing on the odd ROL write cycle (cycle 5/6) will be delayed by 2 to an odd cycle, where it takes 4 cycles as usual.

Both tests are verified to give the expected result on real hardware and Nintendulator 0.980, and but not on Mesen 0.9.7.37 (goodrol turns white), puNES 0.100 (goodrol turns white), Nestopia UE 1.49 (goodrol turns white), and Nintaco 2018.12.31 (goodrol turns white on some resets). Other emulators I'm aware of don't emulate the bit deletion at all and will show black on both ROMs. There hasn't been much progress in a couple years on emulator support for this, so I'm really hoping to get the ball rolling so hacks and homebrews can use synced reads and still work properly in emulators.


Attachments:
dma_sync_test_loop.zip [3.64 KiB]
Downloaded 156 times
Top
 Profile  
 
PostPosted: Sun Feb 17, 2019 2:37 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3182
Location: Brazil
I didn't get it. Please, could someone explain this stuff to me? What "bit deletion" are you talking about?


Top
 Profile  
 
PostPosted: Sun Feb 17, 2019 2:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8372
Location: Seattle
https://wiki.nesdev.com/w/index.php/Sta ... ict_glitch


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group