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

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

@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.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: 2nd2006_next_level test rom and extensions

Post by Sour »

Alyosha_TAS wrote:That error seems pretty serious and makes me a bit wary of VisualNES.
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 :p
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: 2nd2006_next_level test rom and extensions

Post by lidnariq »

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

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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.
Oh, ok well that settles that. Thanks.

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

Re: 2nd2006_next_level test rom and extensions

Post by lidnariq »

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 addresses 0xE41F 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 with allthe first writes to $2005 or the first write to $2006 also...
Last edited by lidnariq on Tue Dec 24, 2019 12:05 pm, edited 2 times in total.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: 2nd2006_next_level test rom and extensions

Post by Fiskbit »

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

Re: 2nd2006_next_level test rom and extensions

Post by lidnariq »

It is so very satisfying to have one's hypothesis verified. :)

Here's a pair of screen captures from Eugene.S's video
Attachments
ppu2000glitch.jpg
ppu2100glitch.jpg
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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

Re: 2nd2006_next_level test rom and extensions

Post by lidnariq »

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 $2006 lands 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.
Last edited by lidnariq on Sun Dec 16, 2018 11:51 am, edited 1 time in total.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: 2nd2006_next_level test rom and extensions

Post by Fiskbit »

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.
Attachments
ppu_2005_glitch.nes
(40.02 KiB) Downloaded 658 times
ppu_2406_glitch.nes
(40.02 KiB) Downloaded 641 times
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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

Re: 2nd2006_next_level test rom and extensions

Post by Fiskbit »

The start button can be used to increment the value being written to $2006 by 1, which should allow for h-scroll tests.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: 2nd2006_next_level test rom and extensions

Post by Alyosha_TAS »

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?
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 »

Post Reply