Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TV jitter #11

Closed
DirtyHairy opened this issue Nov 26, 2016 · 7 comments
Closed

TV jitter #11

DirtyHairy opened this issue Nov 26, 2016 · 7 comments
Assignees

Comments

@DirtyHairy
Copy link
Member

No description provided.

@sa666666
Copy link
Member

When we get to this, the following ROM will be useful in comparing output to the old core:
jitter.zip

Use cursor keys to adjust scanlines, and press space to use the selected count. The effects in pre4 are already quite close to the old core, but still incomplete since the 'tv.jitter' and 'tv.jitter_recovery' options aren't being used.

@sa666666
Copy link
Member

Refer to this thread on AtariAge for more information.

@DirtyHairy DirtyHairy self-assigned this May 7, 2017
@DirtyHairy
Copy link
Member Author

DirtyHairy commented May 7, 2017

I have started to look into this and am confused by the behavior of the implementation in the old core. What I do understand is that, if frame length changes, a CRT requires some time to lock onto the new sync timings, causing the screen to "roll into place".

However, I would have assumed that, if frame lenght increases, the next frame will start too early and thus appear shifted towards the bottom and then roll into place. However, what I observe in Darrell's example is precisely the opposite behavior. In addition, things get even more funky above 169 lines or 89 lines (again in jitter.bin):

  • more than 169: Only every odd frame is drawn, the screen is aligned at the bottom (!) of the kernel (top is cut off)
  • less than 89: Roll direction is partially reversed, so both pressing and releasing fire causes the screen to roll in place downwards.

Bevore I invest more time in understanding and possibly reproducing this to the bits: is the old implementation just an effective implementation that rolls in a superficially convincing way, or is there more to it?

I can't test atm (away from home) and don't have a CRT at any rate, so I am asking instead from testing 😏

@SpiceWare
Copy link
Contributor

SpiceWare commented May 7, 2017

bingo - "just an effective implementation that rolls in a superficially convincing way"

I did it after encountering one too many posts like this where the programmer had no way to test on real hardware and was surprised when others encountered jitter. I just made it so the problem would be readily apparent so the programmer would know they needed to fix it.

My last three blog entries about Stella are on the jitter implementation.

@SpiceWare
Copy link
Contributor

Also note that what happens at the extremes totally depends upon the TV/monitor. Some end up showing 2, or even 3, stable images. See reply #76 & 77

@DirtyHairy
Copy link
Member Author

😄 That's about what I expected. In this case, I'll aim for the same effect, without attempting an exact recreation .

@DirtyHairy
Copy link
Member Author

This commit reimplements jitter. The new implementation works differently, but the effects look similar 😏.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants