2nd2006_next_level test rom and extensions

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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.
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: 2nd2006_next_level test rom and extensions

Post by Eugene.S »

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
256inc.nes.zip
lagarith lossless
(2.85 MiB) Downloaded 591 times
Last edited by Eugene.S on Sun Dec 09, 2018 2:13 pm, edited 1 time in total.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: 2nd2006_next_level test rom and extensions

Post by lidnariq »

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.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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):
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 17900 times
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: 2nd2006_next_level test rom and extensions

Post by Eugene.S »

Okay, here is it:
Attachments
2nd2006_next_level.avi.zip
re-uploaded H264 (2400 kb/s) cut+compressed
(3.85 MiB) Downloaded 575 times
Last edited by Eugene.S on Sun Dec 09, 2018 2:09 pm, edited 2 times in total.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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)
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: 2nd2006_next_level test rom and extensions

Post by Eugene.S »

Reuploaded
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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.
fred
Posts: 67
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: 2nd2006_next_level test rom and extensions

Post by fred »

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!
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: 2nd2006_next_level test rom and extensions

Post by Fiskbit »

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.
fred
Posts: 67
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: 2nd2006_next_level test rom and extensions

Post by fred »

@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...
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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.)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: 2nd2006_next_level test rom and extensions

Post by lidnariq »

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