Video updating is not synchronized with 9900

[eswartz]

V9t9 video updating is being done at times and rates totally different from what the emulated machine expects, so effects like scrolling can become obvious in V9t9. These updates should track the emulated VDP interrupt instead.

From @endlos99 's report in #2:

"Well, what is "smooth"? To me, it feels choppy in that the Parsec ship jumps and/or keeps moving after I release the key, and the landscape scrolling looks "wobbly", i.e., the scenery often grows and shrinks during scrolling -- not very profound, but noticeable. There are no such effects in MESS."

From me:

I agree about the landscape choppiness. V9t9 tries to avoid eating up CPU by making video updates to the entire screen according to arbitrary host CPU timing, whereas a game like Parsec assumes the video is being updated row-by-row at a given rate and the top row starts being updated in lockstep with the video interrupt, thus giving it time to scroll the landscape "before" the monitor shows the changes. I think MESS tries the row-by-row approach, but it's much more CPU-intensive, and my goal (as you've noticed) is that an emulator asking like an ancient machine will actually use less CPU than a modern machine. ;)

That's just a long-winded way to say, I guess I need to pay some more attention to doing that video synchronization more correctly.

[eswartz]

Part of this was due to the aforementioned missynchronization between video updates and emulated VDP interrupts. Once I got all that in line, though, I see that Parsec can't possibly do all these updates in 1/60 s anyway, so my changes won't actually result in seamless scrolling.

The choppiness is actually caused by the attempt to keep the emulated CPU executing at a consistent rate. For some reason a while ago I decided to switch the implementation of how this was done to use semaphores instead of a sleep, but this appears to degrades the client performance in this choppy way. I will try switching that back.

[eswartz]

OK, I remembered that the use of a Semaphore was needed to get cassette reading/writing to work properly. And that code is not actually responsible for this behavior.

BTW, I was able to reproduce the same jumpy scrolling even in v9t9 v6.0 for DOS. So it's not a new bug.

Instead, it seems Parsec cannot by design actually scroll the landscape in a smooth way. The code is not at all bound to a timer (e.g. the VDP interrupt). If I change the CPU speed (lower-left menu) then everything goes faster, proving this point. Given this, it seems that either the Parsec code was tightly tuned to exact TI-99/4A instruction, memory, VDP redraw, and clock timings to give the appearance of never scrolling inconsistently -- which seems unlikely, since the redraw loop has interrupts enabled, which would defeat such an optimization -- or, MESS is doing something to compensate for this.

I will publish a fix for the video updating, though, to have redraws that are less likely to introduce "tears" if code is actually synced to the VDP interrupt.

[eswartz]

Will leave this open until a release...

[eswartz]

Fixed in 2015/07/21 release.