scanline.nes Test Rom

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
lukexor
Posts: 22
Joined: Sat Jun 08, 2019 2:53 am
Location: Portland, OR
Contact:

scanline.nes Test Rom

Post by lukexor » Fri Oct 25, 2019 6:21 pm

I've looked around for a good while trying to find anyone else who may have explained how this rom works in more detail.

It's the one made by Quietust to test basic PPU emulation. I used to have it working fine before I implemented cycle accuracy, and now I have some slight shimmy on the bottom two vertical separators between the text description and the errors column.

I've got a whole slew of working tests and I'm not sure what next to look at for getting this working.

Here's what I've got passing so far that I think relates to the timing of $2000, $2005/$2006 toggling that's going on:

- 1.Branch_Basics.nes
- 2.Backward_Branch.nes
- 3.Forward_Branch.nes
- cpu_timing_test.nes
- instr_timing.nes
- interrupts/1-cli_latency.nes
- interrupts/2-nmi_and_brk.nes
- interrupts/3-nmi_and_irq.nes
- interrupts/5-branch_delays_irq.nes
- 01-vbl_basics.nes
- 02-vbl_set_time.nes
- 03-vbl_clear_time.nes
- 04-nmi_control.nes
- 05-nmi_timing.nes
- 06-suppression.nes
- 07-nmi_on_timing.nes
- 08-nmi_off_timing.nes
- 09-even_odd_frames.nes
- 1.frame_basics.nes
- 2.vbl_timing.nes
- 3.even_odd_frames.nes
- 4.vbl_clear_timing.nes
- 5.nmi_suppression.nes
- 6.nmi_disable.nes
- 7.nmi_timing.nes
- All of the instr tests except SYA and SXA

I suspect some of the above tests are duplicates (possibly different versions), but I'm not sure which are which so I've been testing against them all to be sure.

I'm not passing 4-irq_and_dma.nes right now either as I'm sure I'm not handling all the DMA oddities right now, but I don't think those relate to the scanline test.

The only other thing I could think might indicate some issues is that sprite_hit.nes says "flag set too late soon for upper-left corner" and sprite_overflow.nes says "PPU VBL timing is wrong"

However, I've never had either of those two tests working back when the scanline.nes displayed without flickering previously.

I've spent hours pouring over the source assembly trying to figure out where my timing is wrong. Anyone have ideas on where to look or on a better way to debug the PPU timing? My only debugging method lately has been just printing out tons of information and trying to compare it what the assembly source is trying to test for but it's been slow and laborious.

Also, just wanted to say I appreciate all the help here. I know there are too many emulators out there and much of this information has been repeated over and over but I'm stoked to be getting close to passing all the test roms and being the most accurate Rust emulators out there. (At least I haven't found any that surpass mine yet)

Edit: I attached a screenshot showing what I mean by a shimmy. The bars to the right of the bottom two sections flicker when the should appear as a consistent dashed line similar to the top two sections.
Attachments
Screen_Shot_2019-10-25_at_18_07_45.png
Screen_Shot_2019-10-25_at_18_07_45.png (5.88 KiB) Viewed 5170 times

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: scanline.nes Test Rom

Post by Sour » Fri Oct 25, 2019 6:33 pm

There's some info/discussion and captures from a Famicom AV for that particular test here: viewtopic.php?f=3&t=14833

Basically, it looks like you might not have to worry too much about it, since the video also has a similar glitch there.
Also see Quietust's reply in that thread:
Quietust wrote:Also consider that the scanline.nes jitter may be sensitive to CPU/PPU alignment - the last time I ran it on a CopyNES, there was some variation between resets.

User avatar
lukexor
Posts: 22
Joined: Sat Jun 08, 2019 2:53 am
Location: Portland, OR
Contact:

Re: scanline.nes Test Rom

Post by lukexor » Fri Oct 25, 2019 6:39 pm

Oh perfect! thank you. Guess I didn't scrounge hard enough through the search pages. Good to know, but interesting that neither OpenEMU or FCEUX have the flicker.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: scanline.nes Test Rom

Post by Sour » Fri Oct 25, 2019 7:02 pm

FCEUX is not overly accurate as far as these sorts of things go. Especially if you're using the "old ppu" (which is the default), in which case it renders the screen 1 scanline at a time, I think. I think the new ppu is 8 pixels at a time.

I'm not familiar with OpenEmu, but it seems to include both FCEU and Nestopia (UE?), so if you're using the FCEU core, it's not too surprising you're getting the same result. Unsure how Nestopia behaves on this one, though.

ap9
Posts: 39
Joined: Sat Jun 01, 2013 11:55 am
Location: Maine, U.S.A.
Contact:

Re: scanline.nes Test Rom

Post by ap9 » Fri Oct 25, 2019 8:22 pm

Sour wrote:FCEUX is not overly accurate as far as these sorts of things go. Especially if you're using the "old ppu" (which is the default), in which case it renders the screen 1 scanline at a time, I think. I think the new ppu is 8 pixels at a time.
The old PPU rendered 8 playfield pixels at a time, combined with sprites at the end of each line. The new PPU is a bit more precise with 2-dot timing, rendering PF and OAM on every pixel. However, the new PPU is still considered experimental, and still doesn't handle many things correctly; emphasis is broken.

Nestopia manages to deliver decent pixel timing results despite never handling DMA/DMC collisions.

User avatar
rainwarrior
Posts: 7836
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: scanline.nes Test Rom

Post by rainwarrior » Fri Oct 25, 2019 8:35 pm

ap9 wrote:emphasis is broken.
Emphasis is broken? I know it was broken, but sometime in 2015 the 256-colour limitation was lifted which finally allowed switching emphasis more than once in a frame. Do you still consider it broken with the latest version, or is this comment about an older version?

If it's broken in the NTSC filter output specifically, that's something that I fixed more recently because it was missed in the earlier change, but that's not old enough to be in the last release, only available in interim builds.
ap9 wrote:the new PPU is still considered experimental, and still doesn't handle many things correctly
I don't think it's fair to call it "experimental" at this point. It's much more accurate than the old PPU, and has been present for many years now. It doesn't get everything in the world right, but there's nothing it does worse than old PPU except requiring a little more CPU to run.

I don't think old PPU is the default because new PPU is "experimental"... Old PPU is the default to keep from stepping on the toes of legacy TAS stuff, etc. If you're using it for homebrew you should definitely turn it on, and probably worth it even if you're not, unless you just want lowest CPU use.

User avatar
lukexor
Posts: 22
Joined: Sat Jun 08, 2019 2:53 am
Location: Portland, OR
Contact:

Re: scanline.nes Test Rom

Post by lukexor » Sat Oct 26, 2019 9:39 am

Testing OpenEMU with the Nestopia core results in some flicker of the stars in the top section, and a slight flicker (smaller than mine) of the dotted bars in the bottom section.

Post Reply