It is currently Mon Jul 15, 2019 11:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 55 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Sun Dec 09, 2018 9:29 am 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
I've been going over everything in my emulator again trying to see if there were any open ends or inconsistencies I could find. This test stands out as being pretty important but untested.

Just as a refresher, this test was originally put out by fred in response to this thread. The idea is that latching the second $2006 write is delayed by a few ppu ticks.

However the results were never verified on real hardware (that I know of), and the test seems to have changed somewhat since it's original creation (there are now 2 'unstable' offsets.)

Can anyone run this test on console and verify the results?

Also this isn't the only ppu register that might be experiencing this effect. I think it would be useful for example to modify the bit that is being changed in blargg's original nmi_sync test rom to gauge different relative timings of when writes to PPU registers take effect.

If anyone has any other ideas about this I'd really be interested to hear them.


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 10:40 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 291
Location: Russia (UTC+3)
I guess 2nd2006_next_level.nes is invalid ROM
I tested it on Famicom AV via Everdrive N8 and InviteNES flashcartridges
and got blank screen in both cases.
BTW, nestopia says it is corrupt file.

256inc.nes is valid
2nd2006-256.7z

Here is AVI capture (FCAV+EDN8)


Attachments:
File comment: lagarith lossless
256inc.nes.zip [2.85 MiB]
Downloaded 243 times


Last edited by Eugene.S on Sun Dec 09, 2018 2:13 pm, edited 1 time in total.
Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 12:08 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8471
Location: Seattle
Eugene.S wrote:
I guess 2nd2006_next_level.nes is invalid ROM
I tested it on Famicom AV via Everdrive N8 and InviteNES flashcartridges
and got blank screen in both cases.
BTW, nestopia says it is corrupt file.
It is incorrectly marked as having 2 16KiB PRG banks but only has one. You can fix the header accordingly and it will work.


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 12:23 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
Cool thanks! That certainly raises more questions then it answers. Why do they turn blue? Curious.

The other file should have 16k PRG and 8k CHR, so the header is wrong. Byte 4 should be 1 instead of 2. If you can get this version working and get some results for each of the 8 alignments that would be immensely helpful. EDIT: Oops, ninja'd.

EDIT: For what it's worth, VisualNES displays the same blue triangles occasionally as well. (attached) So, something interesting is happening here.

Here's a little more info. On my emulator, the $2006 latch is delayed by 3 ppu ticks. For this test ROM, those latches occur at the following 10 cycles (all on scanline 2):

Quote:
252
254
255
257
258
260
261
263
264
266


the video from Eugene demonstrates consistent changes to blue triangles every 10 frames. So, one of the above cycles is responsible for it.


Attachments:
blue_triangles.png
blue_triangles.png [ 1.67 KiB | Viewed 7981 times ]
Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 1:36 pm 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 291
Location: Russia (UTC+3)
Okay, here is it:


Attachments:
File comment: re-uploaded H264 (2400 kb/s) cut+compressed
2nd2006_next_level.avi.zip [3.85 MiB]
Downloaded 243 times


Last edited by Eugene.S on Sun Dec 09, 2018 2:09 pm, edited 2 times in total.
Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 1:56 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
Awesome thanks! That's really interesting. I didn't expect the text to go away sometimes. 0_0

Well, I know for certain now that my emulator is way off in dealing with these things, time to get at it.

(That video format is fine once I found the codec)


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 2:11 pm 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 291
Location: Russia (UTC+3)
Reuploaded


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 4:09 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
So it looks like the automatic update done by the ppu is simple blocking the latching from $2006 from occurring altogether in the cases where the triangles turn blue. Not sure if it's losing a race condition or if it's intentional, but that's pretty clearly what's happening. Neat!

It looks like matching the console behaviour should be pretty simple and deterministic.

I'll start thinking about what other latching behaviour cases would be good to have. $2007 comes to mind as well as $2005, but not sure they'll be as easy to test.


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 4:15 pm 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 54
Location: Sweden
I'm guessing all my recent posts on this forum has been lamenting the fact that I haven't tested this on real hardware but I'll say it again! Haha. :(
I'm sadly not in a great position to get a NES and don't know anyone with an everdrive, so the test is what it is, sadly.

Great to see more interest in researching the results however!


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 6:33 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
These kinds of tests are kind of the last frontier for NES research, if you have any other ideas for similar tests please do put them together and hopefully we can get them run. The results so far are already very interesting.


Top
 Profile  
 
PostPosted: Mon Dec 10, 2018 7:26 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
ok, I can get the exact same behaviour as in the videos if I do the following things.

-Delay latching of $2006 by 3 ppu cycles (this was already known and expected to be correct.)
-Have a race condition between the h and v increments on cycle 256 and the latching from $2006 occurring on the same cycle that results in all related variables being reset to 0.

Obviously that second one is highly speculative. But that is what results in correct behaviour according to the two tests.

@fred: In order to better understand this behaviour I think we'll need some tests that happen on different locations. How hard would it be to modify the test rom to occur in the middle of the scanline for example instead of at the end? It would also help to have more geometry so $2006 can be set to different values and see the effects.

Seems like we're only scratching the surface here.


Top
 Profile  
 
PostPosted: Tue Dec 11, 2018 2:43 am 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 72
The second detail there seems to be on track to explain glitching when scrolling vertically in Zelda, which I've been working on recently. I discuss that in this thread, which includes test ROMs that can reproduce this on real hardware. The ill-timed writes cause some bits to get cleared, but not necessarily all of them; the screen sometimes ends up at $2100 in the nametable. Here are some twitch clips of the glitching in action: one two. From what I've seen in Zelda, when $22xx is written, the split goes to $2000 in the nametable, and when $21xx is written, it goes to $2100.

Edit: Fixed the second Twitch link.


Last edited by Fiskbit on Wed Dec 12, 2018 9:45 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Dec 11, 2018 5:23 am 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 54
Location: Sweden
@alyosha: The test is a bit cumbersome to modify but I've been wanting to improve it, so I'll give it a go.
Haven't kept up on NES dev for a while so i'm a bit rusty though, haha.


Edit: as previously mentioned, the text is shaking... hmm haha, something is wrong. It didn't do that before, but it's hard to figure out exactly what's wrong.
I need to understand both the goal and the code again so I can make it simpler. I remember running into branches crossing pages being a big problem for exact timings...


Top
 Profile  
 
PostPosted: Tue Dec 11, 2018 4:16 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 97
Fiskbit wrote:
The second detail there seems to be on track to explain glitching when scrolling vertically in Zelda, which I've been working on recently. I discuss that in this thread, which includes test ROMs that can reproduce this on real hardware. The ill-timed writes cause some bits to get cleared, but not necessarily all of them; the screen sometimes ends up at $2100 in the nametable. Here are some twitch clips of the glitching in action: one two. From what I've seen in Zelda, when $22xx is written, the split goes to $2000 in the nametable, and when $21xx is written, it goes to $2100.


Yeah the 'everything goes to zero' thing is just a guess that works for those 2 test roms. Probably the behaviour is a bit more complicated (but likely still deterministic, since so far everything matches frame for frame and pixel for pixel.) We'll need some more test cases to figure it out. Also, pretty crazy coincidence that we were looking at the same problem at almost the exact same time.

I tried out your test roms, but the one that's labeled 'delay' seems to be acting without glitches, while the one labeled 'normal' does hit race conditions, but not at cycle 256. These glitches happen on the h-increments at cycle 215, 223, 239. So, maybe they are labeled backwards?

Anyway, it would be very helpful to have hardware captures of these cases too to see how they are different from the 256 case.
@Eugene.S can you help with this?

@fred: Cool thanks! good luck, I'm sure that stuff is pretty complicated to get right.

I feel like we're really on to something here!

EDIT: VisualNES doesn't seem to work with the split_scroll test roms for some reason. It doesn't split the screen or scroll at all. That's kind of disappointing. (Unless it also doesn't split/scroll on hardware, in which case I don't understand what's happening.)


Top
 Profile  
 
PostPosted: Tue Dec 11, 2018 4:38 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8471
Location: Seattle
So, per PPU scrolling:
On dot 256, the fine Y coordinate is incremented within V
On the second write to $2006, T is copied into V

So we've got a situation where parts of the bits in V are both incremented and loaded at the same time...

Looking at Visual2C02, vramaddr_t12 (fine Y lsbit) is copied into vramaddr_v12 when copy_vramaddr_vscroll is true.
vramaddr_v12 toggles after pclk0, then node 2101, pclk0 again, and inc_vramaddr_vscroll.

If either xxx_vramaddr_vscroll would cause the node to be pulled low ... the result should be low, if I'm reading this correctly.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Alexa [Bot] and 14 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