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...

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.

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.

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.

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).

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,xdot,dot+1y= toggle scanline (up/down)x= toggle dot*3 (left/right)

0,0 0,1 0,2240,241 243,244 246,247

1,0 1,1 1,2241,242 244,245 247,248

2,0 2,1 2,2242,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.

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.

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:

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

(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...

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...

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.)

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.

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.

Who is online

Users browsing this forum: No registered users and 3 guests

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