Properly model NUSIZ during player decode and draw

DirtyHairy commented 7 years ago

...as described on AtariAge. As for the players, this will basically boil down to replacing the precomputed player patterns with a proper description of the player scan counters. Looking at Joe Musashi's testcase, I think that there is no delay in NUSIZ (I'll have to recheck, but if I remember correctly, a delay will wreak havok on several ROMs, including Tominv5), but instead the current pixel will finish rendering and, after that, the clock divisor will continue counting at the new ratio.

DirtyHairy commented 7 years ago

By the way, that's a pretty fascinating thread :smirk: Several ideas from there are actually implemented in 6502.ts and the new core. A nice case of parallel evolution :beers:

thrust26 commented 7 years ago

Sounds interesting. Which ideas?

DirtyHairy commented 7 years ago

Mainly splitting the individual aspects of the TIA into separate classes and modelling the TIA as interconnected counters. I also stumbled over your branch in Stella when I first started integrating the new core (I didn't know about the corresponding thread); that stuff looks pretty similar to how the new core is structured, too.

sa666666 commented 7 years ago

I had partly forgotten about that thread. Looking at it now, it did lay out the framework of where we are now, but (as you say) in a completely parallel evolution. Things were looking up at that point, but you'll notice how the thread just stopped. In the last message, I went to PM to help the guy set up a development environment. After a week or so of working on it, he decided that he was no longer interested. And some of the other help that was anticipated didn't come, so I became disillusioned and (again) moved on to other parts of the codebase.

So @DirtyHairy, you'll understand why I switched to your core so quickly, as we talked about in a PM. I've since learned that once you find reliable help, you latch on immediately :)

thrust26 commented 7 years ago

If the same solution is found multiple times independently, that 's a very good sign.

Sorry for aborting my work on Stella, first SCA had to be done and took much longer than I had expected. And afterwards I simply was not motivated enough to return. But at least I was able to help to forward Christian to Stella.

sa666666 commented 7 years ago

For the record, Thomas, I wasn't referring to you in that last comment.

DirtyHairy commented 7 years ago

@sa666666 Indeed, this is an interesting bit of history that explains very well why you wanted to get rid of the old core as soon as possible. It is also a peculiar coincidence that the 6502.ts core came around and to fill that particular hole.

I started 6502.ts as a mere research project and tech demo on Typescript and Javascript performance more than two years ago, and after completing CPU emulation, the project went to sleep again in early 2015. It is a mere coincidence that I started work again on 2600 emulation this spring and, after getting the first few ROMs to work, I was kinda sucked in --- I wasn't into retrocomputing in general or the VCS on particular before. The 2600 and the TIA are fascinating pieces of technology, and the more I learn about them, the more I continue to be surprised by what talented people can get out of this seemingly primitive and unwieldly hardware.

Anyway, merry christmas to you both, I'll propably be mostly gone from the web for a few days now :smirk: :christmas_tree: :snowflake:

DirtyHairy commented 7 years ago

I have created a series of testcases that probe the behavior of nusiz during decode and draw: testcases.zip, source here. The testcases work by switching nusiz at a given clock and shifting the player from right to left through this point. The two red lines mark the point where NUSIZ (and the initial RESP) are hit, and the point where a 8px player would start drawing. Color/BW shifts between two player patterns, difficulty p0 switches between target nusiz values, and difficulty p1 switches between PAL and NTSC. The results:

8 -> 16 8-16

8 -> 32 8-32

16 -> 8 16-8

16 -> 32 16-32

32 -> 8 32-8

32 -> 16 32-16

Now all I'll have to do is to determine a rule from those... :8ball:

DirtyHairy commented 7 years ago

Implemented in 1a7ac60 . The corresponding patterns now look like this in stella:

8 -> 16 player8

8 -> 32 player8_1

16 -> 8 player16

16 -> 32 player16_1

32 -> 8 player32

32 -> 16 player32_1

sa666666 commented 7 years ago

Just wanted to confirm that this fixes the final remaining issue in https://github.com/stella-emu/stella/issues/68 too (the second-last horizontal bar was too short).

DirtyHairy commented 7 years ago

This als renders Joe Musashi's testcase pixel correct.

DirtyHairy commented 7 years ago

However, @thrust26 's testcase is much closer than any other emulator, but there are still two deviations:

img_20170206_224210

vs.

testsize2copies_a

Specifically, the first sample on the right in the second and third groups shows two lines surplus in the emulation. I'm reopening this ticked and will close it again once I get this fixed :smirk:

DirtyHairy commented 7 years ago

It seems that switching off a copy during the very early stages of decoding will skip it alltogether. fd95231 accounts for this behavior and reproduces @thrust26 's testcase perfectly.

testsize2copies_a

Still, this has made me curious about some other cases I want to test before closing this:

Switching from double / quad player to two close copies, inducing an overlap between between the two copies
Systematically switching off copies just after hitting the decode
Systematically switching on copies just before hitting the decode

DirtyHairy commented 7 years ago

The TIA is one hellish chip. It seems that everything that affects the counters obeys slightly different rules during hblank. I have created a new testcase that is very similar to the testcases above but executes the NUSIZ during hblank (I only 32 pixels -> x) for now: testcase.zip. As before, you can find the source in the 6502.ts repo.

The results on real hardware look like this:

32 -> 8: img_20170307_225903