Difference (Unl) shakes in my emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: Difference (Unl) shakes in my emulator

Post by rainwarrior » Mon Feb 13, 2017 8:54 am

Zepper wrote:
rainwarrior wrote:Visual NES needs validating too. ;)
Keep this line of thought and the "validation" won't pass in the hardware too.
I don't understand this comment.

I was saying that Visual NES has its own inaccuracies that need to be worked out, just like emulators.

fred
Posts: 64
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Difference (Unl) shakes in my emulator

Post by fred » Mon Feb 13, 2017 9:37 am

I improved the test prototype a little bit. Running it in nintendulator, it starts the second STA $2006 between dots 239-252 on scanline 1, but I'm still unsure about some timing details, like where the actual write cycle happens.
This timing window should be easy to adjust in any direction on a cpu cycle basis, in any case.

It still doesn't seem to work in visual nes which is unfortunate. Maybe there's some ppu alignment problem going on... not sure.

Edit: Well, commented out the cpu-ppu sync code because... it's not actually needed, haha. Also makes it run in visual nes! I'll see if I can make do something useful now.

Edit 2: I guess cpu-ppu syncing code is actually needed to know exactly which cycle we are on. Oops. I'll try reading blargg's code and see if i can figure it out...
Attachments
2nd2006-256.7z
(1.58 KiB) Downloaded 146 times
Last edited by fred on Mon Feb 13, 2017 4:06 pm, edited 1 time in total.

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

Re: Difference (Unl) shakes in my emulator

Post by Sour » Mon Feb 13, 2017 3:13 pm

rainwarrior wrote:Visual NES needs validating too. ;)
I'd like to stress this point too - there are a number of issues with the Visual NES at the moment (OAM read/writes, palette read/writes, and the timing of I/O writes to the PPU from the CPU).
I know some of these are issues shared with the original Visual 2A03 and 2C02, but some may be specific to the Visual NES (e.g how both cores are hooked up together in the code). I simply haven't had the time/energy to look into these issues, plus I lack most of the actual technical knowledge that would probably be required to fix most of these problems. If anybody actually fixes any of the issues in it though, I'd be more than happy to incorporate the fixes to the repository.

The visual nes may be useful to trace signals and try to understand some of the master clock level timing, but anything that comes out of it should also be validated on an actual NES before making any conclusions.

User avatar
Zepper
Formerly Fx3
Posts: 3190
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Difference (Unl) shakes in my emulator

Post by Zepper » Mon Feb 13, 2017 3:48 pm

I wonder what's the huge difficulty of running homebrew software in a NES with all our stuff? Lack of interest or lack of proper equipment/tools?

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

Re: Difference (Unl) shakes in my emulator

Post by rainwarrior » Mon Feb 13, 2017 5:18 pm

Zepper wrote:I wonder what's the huge difficulty of running homebrew software in a NES with all our stuff? Lack of interest or lack of proper equipment/tools?
I never saw an actual request to run something... If you don't have hardware I'm sure there's lots of people willing to run tests from a flashcart etc., myself included.

If you're referring to the actual OP's question there's kind of a paradox to do with "unlicensed" vs "MMC3", I think? What hardware is it supposed to run on, and are you requesting a test of that ROM?

User avatar
Zepper
Formerly Fx3
Posts: 3190
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Difference (Unl) shakes in my emulator

Post by Zepper » Mon Feb 13, 2017 5:53 pm

fred wrote:I improved the test prototype a little bit. Running it in nintendulator, it starts the second STA $2006 between dots 239-252 on scanline 1, but I'm still unsure about some timing details, like where the actual write cycle happens.
This timing window should be easy to adjust in any direction on a cpu cycle basis, in any case.
What's the expected behaviour/screen result when running the test?

fred
Posts: 64
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Difference (Unl) shakes in my emulator

Post by fred » Mon Feb 13, 2017 7:11 pm

For now, it simply draws triangle tiles from the first nametable on the first row of tiles. At around scanline 1, dot 256 it does a second write to 2006 and draws from the second nametable instead. If t->v happened too early, the triangles will start shaking as some writes will happen before dot 256.

...Yes, this is very much a prototype... haha. Anyway, it's currently tuned to be 1 cpu cycle too early in nintendulator, thereby causing shaking. At this point, I should see how other emulators react. I'll also go back to bart vs the space mutants (shakes in nintendulator) and check if the write timings there are similar to the current test.
A real nes should have a delayed t->v transfer and not have any shaking, so if someone feel like giving the current version a try it can be found here: https://github.com/FredYeye/2nd2006 (2nd2006_simple.nes).

As stated in the git readme, the timing variance is too big too determine the exact t->v delay, but it should in theory not shake on a real nes. I don't know if this is true for all cpu-ppu alignments.


And yes, I didn't ask for HW tests earlier because it was even more prototype back then, haha.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Difference (Unl) shakes in my emulator

Post by thefox » Tue Feb 14, 2017 8:55 am

In PPU-timing-dependent tests like this, it would be nice to have a piece of code which detects the CPU-PPU synchronization and prints it somewhere.
(I don't know if anybody has implemented a routine like that, blargg may have. Would be nice to have for various test authors, though.)

@fred: You should clear the nametable in your test, otherwise you may get random garbage on screen (also, attributes will be ~random).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

fred
Posts: 64
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Difference (Unl) shakes in my emulator

Post by fred » Tue Feb 14, 2017 10:04 am

thefox wrote:In PPU-timing-dependent tests like this, it would be nice to have a piece of code which detects the CPU-PPU synchronization and prints it somewhere.
(I don't know if anybody has implemented a routine like that, blargg may have. Would be nice to have for various test authors, though.)
Blargg does have some code syncs the cpu with the ppu. It has too many macros and files for me to read, but maybe it can simply be used as is somehow.
@fred: You should clear the nametable in your test, otherwise you may get random garbage on screen (also, attributes will be ~random).
Ok, will do.


Edit: Think i made some progress. Borrowed the nmi sync loop from blargg and tinkered some with it. Currently the 2006 write instruction starts at either dot 250 or 252, alternating between the two. I'll see if I can easily adjust it tomorrow.

Edit2: The variance is down to 1 dot. Pretty good! Let's see what's next...

Edit3: It's now possible to toggle scanlines and dots for precise writes. Here's a cheat sheet for what cycles sta $2006 starts on in nintendulator.

Code: Select all

y,x
dot,dot+1
y= toggle scanline (up/down)
x= toggle dot*3 (left/right)

0,0      0,1      0,2
240,241  243,244  246,247

1,0      1,1      1,2
241,242  244,245  247,248

2,0      2,1      2,2
242,243  245,246  248,249
I guess there's still some things to do, like setting up a known start point. Right now it just wings it and works in nintendulator, unsure if alignment makes a difference.
Also the graphics output, which was already cryptic, makes no sense right now since it doesn't take changing scanlines into account.

fred
Posts: 64
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Difference (Unl) shakes in my emulator

Post by fred » Sun Feb 19, 2017 2:31 pm

I've updated the rom to make a bit more sense. See the readme here for an explanation of what it does. (tl;dr: change offset with d-pad. perfect triangles = t->v after Y inc, broken triangles = t->v before Y inc)

I suppose all that's left for a complete prototype is initially waiting for a missed nmi, so the starting point is known.

User avatar
Zepper
Formerly Fx3
Posts: 3190
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Difference (Unl) shakes in my emulator

Post by Zepper » Sun Feb 19, 2017 8:13 pm

You mean... the bottom line of the triangles shouldn't be flickering, right?

fred
Posts: 64
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Difference (Unl) shakes in my emulator

Post by fred » Sun Feb 19, 2017 8:38 pm

It's a limitation of the test I believe - every offset writes at dot X, and then X+1 the next frame (then X, X+1 etc). So if dot X is before the Y inc and dot X+1 is after, it should be flickering. There should only be one offset with flickering, at least as far as I know.

For reference, here's one possible broken triangle, which means that t->v happened before the Y inc:
Image

A perfect staircase triangle, which means that t->v happened after the Y inc:
Image

(I'll change the triangle to have one color since it means nothing, btw.)

The only way to know on which offsets it should be before, after or flickering is to compare against hardware. It *should* work on hardware, but I still want to add some init code to make the setup consistent.
The output isn't the greatest, I know... and there's no clear pass/fail. I'll try to improve it once I know it works as intended, and see which offset does what on hardware. Different alignments might even make offsets do different things, who knows...

zxbdragon
Posts: 474
Joined: Mon Dec 12, 2011 8:15 pm

Re: Difference (Unl) shakes in my emulator

Post by zxbdragon » Mon Feb 20, 2017 5:32 am

fred wrote:I improved the test prototype a little bit. Running it in nintendulator, it starts the second STA $2006 between dots 239-252 on scanline 1, but I'm still unsure about some timing details, like where the actual write cycle happens.
This timing window should be easy to adjust in any direction on a cpu cycle basis, in any case.

It still doesn't seem to work in visual nes which is unfortunate. Maybe there's some ppu alignment problem going on... not sure.

Edit: Well, commented out the cpu-ppu sync code because... it's not actually needed, haha. Also makes it run in visual nes! I'll see if I can make do something useful now.

Edit 2: I guess cpu-ppu syncing code is actually needed to know exactly which cycle we are on. Oops. I'll try reading blargg's code and see if i can figure it out...
2nd2006-256.7z, real hardware is black srceen.

fred
Posts: 64
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Difference (Unl) shakes in my emulator

Post by fred » Mon Feb 20, 2017 8:10 am

I added an init loop that waits for $2002 to return the nmi bit and the actual nmi getting suppressed. Cpu-ppu sync and entering the main loop should be consistent now, I hope. (it already was in nintendulator, but who knows about other setups.)
2nd2006-256.7z, real hardware is black srceen.
Right, that was an old version. Newest version: https://github.com/FredYeye/2nd2006/raw ... _level.nes


I'll work on adding an explanation of the output up next. An indicator of the current offset would be nice too.
Btw, is the top-most tile row safe to draw on, or could it be cut off on a TV? I could just bump down the tiles a few rows I guess.

tepples
Posts: 21754
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Difference (Unl) shakes in my emulator

Post by tepples » Mon Feb 20, 2017 8:57 am

On PAL, all scanlines are visible. On NTSC, the TV will cut off the top and bottom of the picture. Exact amounts vary by TV, but don't count on the top 16 or bottom 12 lines being visible in every case.

Image
Diagram of safe areas

Post Reply