It is currently Thu May 23, 2019 8:28 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Mon Dec 17, 2018 11:33 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
er... something should have shown up. Either that or I'm completely wrong, but I can't see an obvious reason how.

Given that the odds of the effect showing up at all is only 50% for any given reboot... I was already kinda surprised that it worked in both ppu_2000 and ppu_2100.



Tangentially related, this makes me really curious about the breakdown of pclk0 vs pclk1 in the 2C07 / UA6538.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2018 11:42 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 290
Location: Russia (UTC+3)
I have original PAL NES, but still waiting 72 to 60 pin converter from ebay.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2018 1:59 pm 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
Note that these tests won't function properly on PAL as-is, but may still be able to provide useful results without being retuned. The ppu_xxxx_glitch tests will drift, but it looks in Mesen like they'll occasionally hit the correct dots. split_scroll_test_v2 will fail its NMI/PPU sync, so there will be much more jitter, and the scanline delay isn't tuned to the different ratio of dots to CPU cycles.

For the new 2005 and 2406 tests, did anyone verify in Mesen that the tests do what we expect? I think they're right, but especially with them not working on real hardware like we expected, I'd like to be sure I didn't misunderstand the requirements.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2018 2:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
They looked like they put the write of the right value at the right time to me, but I was just using Mesen's event viewer.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2018 4:59 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
For me, I am seeing the first write to $2005 happen one tick too late.

Oops nevermind, it's happening on the correct tick.


Top
 Profile  
 
PostPosted: Tue Jan 01, 2019 5:32 am 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
I finally got all the equipment I need to run some tests on my NTSC frontloader via Everdrive. Here are some results.


ppu_2005_glitch.nes & ppu_2406_glitch.nes
After many resets, I can confirm that the $2005 and $2406 tests do indeed show the glitching that lidnariq predicted for some (but not all) PPU alignments.


split_scroll_test_v2.nes
When powering on, at 40,39, the 2 dots I hit are right before the increment (scanline lost) and right after. The latter dot is the one that causes the glitch. This shows onscreen as vertical jitter plus the glitch. Moving down and right (41,3A) puts us one dot further, so both target dots are after the increment, which makes the left one cause the glitch (but there's no vertical jitter).

At 40,39,00, if I try the range 0101-011F, all of these cause glitching except 0102, which just moves the post-split section 2 tiles left without any glitching.

40,39,00,0800 causes glitching, but 40,39,02,0800 does not, showing the glitching with just a nametable select bit.

Positioning at any place where the first tile post-split on the target scanline flickers can cause coarse x glitching for the full screen post-split. This can be seen at 40,11,00,0104. 41,12,00,0104 also causes this, so it's the right dot for the former and left for the latter. This confirms the coarse x behavior that had been guessed earlier in this thread.

Some emulator comparisons:
- 40,39,00,0100: Post-split, the screen should jitter vertically by 1 scanline. puNES 0.100 matches this. Mesen 0.9.7 does not; it must be at 41,3A,00,0100 for this to happen.
- 3F,10,00,0100: Post-split, the target scanline should jitter horizontally by 1 tile. Mesen and puNES both do this at 3E,10,00,0100, a position at which real hardware consistently skips the first tile post-split.
- 40,11,00,0100: The first visible tile of the target scanline post-split should flicker. Mesen does this at 3F,11,00,0100 and puNES at 3E,11,00,0100 (both should skip the first tile on that scanline post-split).

There appears to be another PPU alignment where the jitter+glitch occur at 3F,38 and glitch at 40,39, instead of 40,39 and 41,3A as I had described earlier.


If anyone's interested in results for specific values, I can test them and report results, but I don't expect to have the means to capture video of this anytime soon.


Top
 Profile  
 
PostPosted: Tue Jan 01, 2019 11:35 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
Fiskbit wrote:
ppu_2005_glitch.nes & ppu_2406_glitch.nes
After many resets, I can confirm that the $2005 and $2406 tests do indeed show the glitching that lidnariq predicted for some (but not all) PPU alignments.
If you had to take a guess, did it feel like it was roughly half the time, or roughly one quarter the time?

As far as I know, the different alignments should be all equally likely...


Top
 Profile  
 
PostPosted: Tue Jan 01, 2019 6:38 pm 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
I've tested how often I get each result across batches of 30 resets. I only tracked number for the first several tests, and then started tracking order, as well. I also did tests on how often I get jitter when starting up split_scroll_test_v2. Here are my results in the order I got them:

Code:
 (y = yes glitch, n = no glitch)
2000: y = 15, n = 15
2005: y = 7,  n = 23
2100: y = 5,  n = 25
2406: y = 9,  n = 21

2000: y = 15, n = 15
2100: y = 5,  n = 25
2005: y = 9,  n = 21
2406: y = 8,  n = 22

2100: y = 10, n = 20 (nyyny nnnny nyyyn ynynn ynnnn nnnnn)
2406: y = 8,  n = 22 (nnnny nnyny nynnn nnnnn ynnnn yyynn)
2005: y = 9,  n = 21 (nnyyn nnnyn nnynn nnnny ynyny nnnyn)
2000: y = 17, n = 13 (yyyyy nnyny ynyny yyyny nnnnn nnyyy)

(y = yes jitter, n = no jitter)
sst2: y = 24, n = 6  (yyyyy yynyy yynyy yynyy nnyyy yynyy)
sst2: y = 26, n = 4  (nyyyy yyyyy yyyyn nyyyy yyyyy yyyyn)
sst2: y = 23, n = 7  (yyyny yyyyy yyynn ynyyy yyyyy ynnyn)

If we assume the 4 PPU alignments are equally likely, this feels to me like everything here is around 1/4 except the 2000 test, which is 1/2. I expected 2000 and 2100 to have the same results and am a bit confused by them differing, though.


Top
 Profile  
 
PostPosted: Tue Jan 01, 2019 8:11 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
Assuming my mental model is correct, there's two cases here:
A) M2 rises 1/2 master cycle before dot 257
B) M2 rises 3/2 master cycle before dot 257

The CPU/PPU's pulldowns are a little stronger than its pullups (because NMOS)... Maybe, because this is analog race condition land anyway, the $2100 leaves $21 on the bus during φ1 and the CPU can pull down the least significant bit in case B but not case A, before it gets stuck inside? Whereas for the reverse, $2000 leaves $20 on the bus and the CPU can't pull the line up early enough?


I don't suppose anyone (Quietust? Kevtris?) knows of ways for software to detect which of the four alignments one's NES is in?


Top
 Profile  
 
PostPosted: Tue Jan 01, 2019 9:28 pm 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
This post by blargg indicates there is a way to detect the alignment and that he may have made a test ROM for it, though I haven't yet found evidence of such a ROM being posted. The data also shows that alignments may have different likelihoods, though I'd like to see more testing done on that to be sure. I'll continue digging into alignment detection, but it's definitely at the edge of my understanding at the moment, so any help would be appreciated.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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