It is currently Thu Nov 23, 2017 8:58 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Mon Feb 13, 2017 8:54 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5838
Location: Canada
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.


Top
 Profile  
 
PostPosted: Mon Feb 13, 2017 9:37 am 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
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 28 times


Last edited by fred on Mon Feb 13, 2017 4:06 pm, edited 1 time in total.
Top
 Profile  
 
PostPosted: Mon Feb 13, 2017 3:13 pm 
Offline

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


Top
 Profile  
 
PostPosted: Mon Feb 13, 2017 3:48 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
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?


Top
 Profile  
 
PostPosted: Mon Feb 13, 2017 5:18 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5838
Location: Canada
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?


Top
 Profile  
 
PostPosted: Mon Feb 13, 2017 5:53 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
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?


Top
 Profile  
 
PostPosted: Mon Feb 13, 2017 7:11 pm 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Tue Feb 14, 2017 8:55 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Tue Feb 14, 2017 10:04 am 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
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.

Quote:
@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:
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.


Top
 Profile  
 
PostPosted: Sun Feb 19, 2017 2:31 pm 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Sun Feb 19, 2017 8:13 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
You mean... the bottom line of the triangles shouldn't be flickering, right?


Top
 Profile  
 
PostPosted: Sun Feb 19, 2017 8:38 pm 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
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...


Top
 Profile  
 
PostPosted: Mon Feb 20, 2017 5:32 am 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
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.


Top
 Profile  
 
PostPosted: Mon Feb 20, 2017 8:10 am 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
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.)

Quote:
2nd2006-256.7z, real hardware is black srceen.

Right, that was an old version. Newest version: https://github.com/FredYeye/2nd2006/raw/master/roms/2nd2006_next_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.


Top
 Profile  
 
PostPosted: Mon Feb 20, 2017 8:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19254
Location: NE Indiana, USA (NTSC)
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group