Properly model NUSIZ during player decode and draw

[DirtyHairy]

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

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

[thrust26]

Sounds interesting. Which ideas?

[DirtyHairy]

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]

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]

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]

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

[DirtyHairy]

@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 😏 🎄 ❄️

[DirtyHairy]

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

16 -> 8

16 -> 32

32 -> 8

32 -> 16

Now all I'll have to do is to determine a rule from those... 🎱

[DirtyHairy]

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

8 -> 16

8 -> 32

16 -> 8

16 -> 32

32 -> 8

32 -> 16

[sa666666]

Just wanted to confirm that this fixes the final remaining issue in #68 too (the second-last horizontal bar was too short).

[DirtyHairy]

This als renders Joe Musashi's testcase pixel correct.

[DirtyHairy]

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

vs.

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 😏

[DirtyHairy]

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.

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]

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:

32 -> 16

Commit e021660 improves emulation to include this class of edga cases. The emulation now looks like this:

32 -> 8

32 -> 16

This fixes #82 for good. More to come...

[DirtyHairy]

The very same commit also fixes the cases 16 -> 8 and 16 -> 32. For reference:

16 -> 8 hardware

16 -> 32 hardware

16 -> 8 Stella

16 -> 32 Stella

[thrust26]

@DirtyHairy Is this still an issue?

[DirtyHairy]

Not so much an issue as an reminder that there are still some edge cases that I didn't investigate and that I want to revisit eventually.