2nd2006_next_level test rom and extensions
Moderator: Moderators
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
2nd2006_next_level test rom and extensions
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.
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.
Re: 2nd2006_next_level test rom and extensions
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)
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 593 times
Last edited by Eugene.S on Sun Dec 09, 2018 2:13 pm, edited 1 time in total.
Re: 2nd2006_next_level test rom and extensions
It is incorrectly marked as having 2 16KiB PRG banks but only has one. You can fix the header accordingly and it will work.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.
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
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):
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):
the video from Eugene demonstrates consistent changes to blue triangles every 10 frames. So, one of the above cycles is responsible for it.252
254
255
257
258
260
261
263
264
266
- Attachments
-
- blue_triangles.png (1.67 KiB) Viewed 17903 times
Re: 2nd2006_next_level test rom and extensions
Okay, here is it:
- Attachments
-
- 2nd2006_next_level.avi.zip
- re-uploaded H264 (2400 kb/s) cut+compressed
- (3.85 MiB) Downloaded 577 times
Last edited by Eugene.S on Sun Dec 09, 2018 2:09 pm, edited 2 times in total.
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
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)
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)
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
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.
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.
Re: 2nd2006_next_level test rom and extensions
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!
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!
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
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.
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
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.
-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.
Re: 2nd2006_next_level test rom and extensions
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.
Edit: Fixed the second Twitch link.
Last edited by Fiskbit on Wed Dec 12, 2018 9:45 pm, edited 1 time in total.
Re: 2nd2006_next_level test rom and extensions
@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...
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...
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
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.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.
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.)
Re: 2nd2006_next_level test rom and extensions
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.
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.