2nd2006_next_level test rom and extensions
Moderator: Moderators
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
@lidnariq: you seem to be really good at understanding what the circuits in the ppu are supposed to do, do you have any idea why VisualNES is failing to scroll in the first version of the tests fiskbit posted? That error seems pretty serious and makes me a bit wary of VisualNES.
@Eugene.S: well the first thing we need is just a video of what the test looks like on poweron. This will hopefully confirm the initial timing. On my end it powers up to the glitchy state right away. I think the v bit effects are pretty well settled, so I'll look for conditions where the h bit should be effected. Also I guess we have to test the pre-render line where v=t continuously.
EDIT: hmmm, actually maybe the test needs to be modified to test the h bits.
@Eugene.S: well the first thing we need is just a video of what the test looks like on poweron. This will hopefully confirm the initial timing. On my end it powers up to the glitchy state right away. I think the v bit effects are pretty well settled, so I'll look for conditions where the h bit should be effected. Also I guess we have to test the pre-render line where v=t continuously.
EDIT: hmmm, actually maybe the test needs to be modified to test the h bits.
Re: 2nd2006_next_level test rom and extensions
To be fair, you should be wary of Visual NES either way, there are a number of issues with it (e.g palette is often incorrect, etc.) that I haven't taken the time to analyze in more details ever since I initially made it. It may or may not have more issues than the standalone ones - I wish I had the proper knowledge to get it fixed, but unfortunately, I've forgotten most of the minimal knowledge of transistors and circuits that I had :pAlyosha_TAS wrote:That error seems pretty serious and makes me a bit wary of VisualNES.
Re: 2nd2006_next_level test rom and extensions
The scrolling isn't happening because the sprite 0 hit isn't happening in VisualNES.
Since Fiskbit's test doesn't rely on sprite 0, it might work, but requires user interaction.
Since Fiskbit's test doesn't rely on sprite 0, it might work, but requires user interaction.
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
Oh, ok well that settles that. Thanks.lidnariq wrote:The scrolling isn't happening because the sprite 0 hit isn't happening in VisualNES.
Since Fiskbit's test doesn't rely on sprite 0, it might work, but requires user interaction.
@Sour: That's ok, I sure as heck can't fix it. It did perfectly duplicate 3 out of the four tests though, so that's not bad.
Re: 2nd2006_next_level test rom and extensions
For the write to $2000, does anybody have the ability to run blargg's test in this post http://forums.nesdev.com/viewtopic.php?p=112503#p112503 ?
Theoretically every 3rd scanline should be glitched out, I think. (And only half the times the machine comes out of reset)
If my understanding is right, then changing two bytes: (6502 addresses0xE41F and 0xE434 = file offsets 0x642f and 0x6434 = lda #1 and sta $2000) to instead be 0 and $21 should cause the glitch to happen the other direction.
(No photos or videos are necessary, just verbal verification)
Relevancy: I think this glitch should happen withallthe first writes to $2005 or the first write to $2006 also...
Theoretically every 3rd scanline should be glitched out, I think. (And only half the times the machine comes out of reset)
If my understanding is right, then changing two bytes: (6502 addresses
(No photos or videos are necessary, just verbal verification)
Relevancy: I think this glitch should happen with
Last edited by lidnariq on Tue Dec 24, 2019 12:05 pm, edited 2 times in total.
Re: 2nd2006_next_level test rom and extensions
Eugene.S: It's hard to say what specific values to test in split_scroll_test_v2 because it likely doesn't match Mesen timing exactly and different power-on states may affect it. You can get an idea of where you are by looking at the split behavior; on a given scanline, there will be a point where either the split will jitter because the two target dots are on either side of the end of the visible scanline, or adjusting by 1 CPU cycle left or right will cause a scanline to be added or dropped. I tried to time the split to occur by default right around the start of hblank on scanline 63, which is the last scanline of the 7's row. If the split occurs after hblank begins, the first scanline of the 8's will be cut off.
If you go down 1 scanline (moves split left by 2 dots) and right 1 CPU cycle (moves split right by 3 dots), you'll advance 1 dot forward on that next scanline. If you do this across several scanlines around the start of hblank, we can get perhaps get an idea of where this stuff is happening. And, doing this at different parts of the screen and with different write values can help verify that the behavior is actually an AND of the incremented value and the write value. I don't know if it's important to do this with different CPU/PPU alignments.
Also interesting would be test results across several power cycles of the two versions of blargg's PPU_CONTROL write test. I've attached my modified version below, and the original is here. As lidnariq stated, we just need confirmation that the glitch happens on the $2100 version like it does on the $2000 version, so video isn't necessary.
fred: Thanks for the kind words. Your tests were super useful in getting us this far, too! Also helped improve my timing substantially, since I previously had no idea blargg's synchronization code existed.
Alyosha_TAS: If you have specific requests for what modifications you'd like for testing additional cases, please let me know and I can try to work them in or make a different version for them.
Alyosha_TAS & lidnariq: If user input can't be done in VisualNES, the default values for scroll_nametable_high, scroll_nametable_low, nametable, scanline_delay, and cycle_delay can be modified in the assembly file. Assembling with snarfblasm can be done by placing the binary into the source directory and running snarfblasm.exe split_scroll_test.asm in command prompt. It will output the result as split_scroll_test.bin. Adding additional LDA's for setting these variables at this point is fine; this part of the code is not timing-critical.
lidnariq: Interesting hypothesis about the $2000 writes. For modifying blargg's test, the correct changes are actually ROM file $6434 = #$00 and $6444 = #$21. I've attached the modified ROM below. If this works out, then the glitch can be avoided when using the SMB-style NMI handler by writing to the PPU_CONTROL mirror that matches the current nametable X, which is an easy workaround. Regarding this happening with $2005/2006, as well, we should be able to test the $2006 case with the current split_scroll_test_v2. The first write occurs 12 dots before the second (and probably seems like 15 because the main effect we see from the second write in the test should be 3 dots early, I guess?).
If you go down 1 scanline (moves split left by 2 dots) and right 1 CPU cycle (moves split right by 3 dots), you'll advance 1 dot forward on that next scanline. If you do this across several scanlines around the start of hblank, we can get perhaps get an idea of where this stuff is happening. And, doing this at different parts of the screen and with different write values can help verify that the behavior is actually an AND of the incremented value and the write value. I don't know if it's important to do this with different CPU/PPU alignments.
Also interesting would be test results across several power cycles of the two versions of blargg's PPU_CONTROL write test. I've attached my modified version below, and the original is here. As lidnariq stated, we just need confirmation that the glitch happens on the $2100 version like it does on the $2000 version, so video isn't necessary.
fred: Thanks for the kind words. Your tests were super useful in getting us this far, too! Also helped improve my timing substantially, since I previously had no idea blargg's synchronization code existed.
Alyosha_TAS: If you have specific requests for what modifications you'd like for testing additional cases, please let me know and I can try to work them in or make a different version for them.
Alyosha_TAS & lidnariq: If user input can't be done in VisualNES, the default values for scroll_nametable_high, scroll_nametable_low, nametable, scanline_delay, and cycle_delay can be modified in the assembly file. Assembling with snarfblasm can be done by placing the binary into the source directory and running snarfblasm.exe split_scroll_test.asm in command prompt. It will output the result as split_scroll_test.bin. Adding additional LDA's for setting these variables at this point is fine; this part of the code is not timing-critical.
lidnariq: Interesting hypothesis about the $2000 writes. For modifying blargg's test, the correct changes are actually ROM file $6434 = #$00 and $6444 = #$21. I've attached the modified ROM below. If this works out, then the glitch can be avoided when using the SMB-style NMI handler by writing to the PPU_CONTROL mirror that matches the current nametable X, which is an easy workaround. Regarding this happening with $2005/2006, as well, we should be able to test the $2006 case with the current split_scroll_test_v2. The first write occurs 12 dots before the second (and probably seems like 15 because the main effect we see from the second write in the test should be 3 dots early, I guess?).
- Attachments
-
- ppu_2100_glitch.nes
- Modified version of blargg's ppu_2000_glitch.nes test for seeing if the high byte of the address matters.
- (40.02 KiB) Downloaded 654 times
Re: 2nd2006_next_level test rom and extensions
It is so very satisfying to have one's hypothesis verified.
Here's a pair of screen captures from Eugene.S's video
Here's a pair of screen captures from Eugene.S's video
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
Can confirm that the scroll_v2 test powers up in the same state as I see on emulator, and that 'inc then &' correctly reproduces the results pixel for pixel.
Cool stuff!
Cool stuff!
Re: 2nd2006_next_level test rom and extensions
Ok, so thinking about the rest of my hypothesis.
The shoot-through glitch can only happen on dot 257, on those bits that are reloaded from T to V and are part of the horizontal position. It can't happen on the second write to $2006 even if it collides with dot 257, because the T is copied to V for the entire duration of that write, and the wrong value at the beginning can't get stuck in V for one scanline.
The second write to $2005 will also have no effect, because it only sets vertical position bits.
So, describing the glitch we "should" see on a first write to $2005 that collides with dot 257, it should end up setting just the following scanline to a coarse X of (upper byte of address of PPU mirror)÷8 - i.e. ranging from 4 to 7, ultimately. There is no "V" for a wrong fine X to get caught in, so that will produce the expected result. (i.e. writing to $2005 should cause a glitched coarse X of 4. Writing to $3F05 should cause a glitched coarse X of 7)
On a first write to $2006 that collides with dot 257 ... the only horizontal bit affected by the first write to $2006 is the one that selects the nametable, so writing to the PPU register mirrors at $2006 vs $2406 should have the same effect as writing to $2000 vs $2100.
Both of these assume that there isn't another write to $2006 copying from T to V before the background tile fetches start for the next line.
So I guess at this point we want tests for to verify these?
* If the second write to $2006lands ends either during dot 256 or between dots 256 and 257 ends during the right half of dot 256 or the left half of dot 257, the resulting value in both T and V will be the result of the bus conflict between the incremented X/Y location and the written value
* If the second write to $2006 lands on a whole bunch of other X coordinates (multiples of eight, except 256 through 320 inclusive), the resulting value in both T and V will be the result of the bus conflict between the X location and the written value, but the Y location will be loaded as intended
* A write to $2000(✓), or a first write to $2005 or $2006, that starts in the middle of the right half of dot 257 will end up writing open bus to V, and then the desired value will be in T during dot 258.
The shoot-through glitch can only happen on dot 257, on those bits that are reloaded from T to V and are part of the horizontal position. It can't happen on the second write to $2006 even if it collides with dot 257, because the T is copied to V for the entire duration of that write, and the wrong value at the beginning can't get stuck in V for one scanline.
The second write to $2005 will also have no effect, because it only sets vertical position bits.
So, describing the glitch we "should" see on a first write to $2005 that collides with dot 257, it should end up setting just the following scanline to a coarse X of (upper byte of address of PPU mirror)÷8 - i.e. ranging from 4 to 7, ultimately. There is no "V" for a wrong fine X to get caught in, so that will produce the expected result. (i.e. writing to $2005 should cause a glitched coarse X of 4. Writing to $3F05 should cause a glitched coarse X of 7)
On a first write to $2006 that collides with dot 257 ... the only horizontal bit affected by the first write to $2006 is the one that selects the nametable, so writing to the PPU register mirrors at $2006 vs $2406 should have the same effect as writing to $2000 vs $2100.
Both of these assume that there isn't another write to $2006 copying from T to V before the background tile fetches start for the next line.
So I guess at this point we want tests for to verify these?
* If the second write to $2006
* If the second write to $2006 lands on a whole bunch of other X coordinates (multiples of eight, except 256 through 320 inclusive), the resulting value in both T and V will be the result of the bus conflict between the X location and the written value, but the Y location will be loaded as intended
* A write to $2000(✓), or a first write to $2005 or $2006, that starts in the middle of the right half of dot 257 will end up writing open bus to V, and then the desired value will be in T during dot 258.
Last edited by lidnariq on Sun Dec 16, 2018 11:51 am, edited 1 time in total.
Re: 2nd2006_next_level test rom and extensions
I've modified blargg's test to handle the first-write case for $2005 and $2406, which was a little more involved than the other modification. For both, #$00 is written to the register, $2002 is read after the write to clear W, and the timing has been changed to accommodate this new read. These new tests are attached below. I believe they're correct, but I'd like if someone could verify that they are successfully testing the cases we care about.
For the two $2006 second-write cases, I think split_scroll_test_v2 can handle them, but if it can't, I can update it to do so if someone can explain what it's lacking. Alternatively, I could try to hack up blargg's test further to get those writes to hit specific dots, which might be a better idea just for ease of testing.
For the two $2006 second-write cases, I think split_scroll_test_v2 can handle them, but if it can't, I can update it to do so if someone can explain what it's lacking. Alternatively, I could try to hack up blargg's test further to get those writes to hit specific dots, which might be a better idea just for ease of testing.
- Attachments
-
- ppu_2005_glitch.nes
- (40.02 KiB) Downloaded 658 times
-
- ppu_2406_glitch.nes
- (40.02 KiB) Downloaded 641 times
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
I think it would be good to modify the scroll test to check h-scroll as well. As in writing to the lower its of $2006 (and having some horizontal scroll apparent on screen of course.)
It seems highly likely that the results will agree with the v-scroll ones, but having a dedicated test for would be good.
It seems highly likely that the results will agree with the v-scroll ones, but having a dedicated test for would be good.
Re: 2nd2006_next_level test rom and extensions
The start button can be used to increment the value being written to $2006 by 1, which should allow for h-scroll tests.
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: 2nd2006_next_level test rom and extensions
Oh I didn't even try that, shows my reading skills.
Looks like there is an interesting case for v2 scroll at:
4A
40
00
012X
My emulator and Mesen seem to disagree here (and apparently not because of 2006 writes?)
@Eugene.S: Do you think you can make a video for this case?
Looks like there is an interesting case for v2 scroll at:
4A
40
00
012X
My emulator and Mesen seem to disagree here (and apparently not because of 2006 writes?)
@Eugene.S: Do you think you can make a video for this case?