Advice to debug jitter?

[Sohl]

Hello 2600 programmers! I hope you can offer some advice. Over in the homebrew subforum, I posted my debut game: http://atariage.com/forums/topic/237836-my-first-homebrew-2048-4vcs/.

 

User "accousticguitar" loaded my .bin into a cart and tried it on a real console, and reports significant jitter of the main play screen. I don't have a real console currently, and test and debug with Stella and z26. z26 reports consitent 262 scan line screens. Stella reports consistent 19912 CPU cycles per screen each time I do +Frame in the debugger. So the report of jitter puzzles me.

 

Do any of you have advice on how I might debug this? Especially using Stella? Is there some other timing check I can make that would help me zero in on this problem? Thanks if you can help!

 

Here is a copy of the current "Beta 2" version of my game if any of you would like to poke around yourself with a debugger.

 

2048_4vcs_beta2.bin

[RevEng]

I think the issue on real hardware is your sync handling. VBLANK should be on before VSYNC is enabled. Without blanking on, many TVs don't detect VSYNC reliably.

 

[edit - SeaGtGruff speaks to the issue in more detail here]

[Omegamatrix]

Start by setting some breakif conditions in Stella's Debugger to halt the program when the improper amount of scanlines are taken. In this topic here Random describes how to break when you have too many scanlines, and a few posts down in that topic I talk about how to break on too few scanlines, which is equally as important.

 

Hopefully when it breaks it is doing a weird scanline count all the time. If it does you can step through your code and see what is causing it. It most likely is code is simply taking too long to execute. So you can rework the logic to be quicker, or spread it over more than 1 frame.

 

You can also try using TIMINT instead of INTIM can minimize screen bounces should they occur. You poll bit 7 of TIMINT. That bit goes high once the timer has finished.

 

In rare cases there are problems that are hard to detect because the emulator doesn't pick it up. In this post I ran into one of those nightmares.

[Omegamatrix]

RevEng is right, and to further add to what he is saying I've seen TV's get messed up when VSYNC is longer than it should be and shorter when it should be. Have something like this:

; align VSYNC to start at same time, perferably immediately after WSYNC
    
    lda    #2
    sta    WSYNC             
;-------------------------
    sta    VSYNC
    lda    #0
    sta    WSYNC   ;1
    sta    WSYNC   ;2
    sta    WSYNC   ;3
;-------------------------
    sta    VSYNC

Or like this:

    lda    #$0E
.loopVsync:
    sta    WSYNC
;---------------------------------------
    sta    VSYNC
    lsr
    bne    .loopVsync

With VBLANK, it is generally best to turn the scanline beam off right after you finish drawing the kernel (at the bottom of the screen), and turn it back once you begin drawing the kernel again at the top of the screen. No need to mess around with it while writing to VSYNC

[Sohl]

@RevEng, @Omegamatrix: Thanks, you've given me some good stuff to consider and try out!

[Sohl]

OK, "Beta 3" (http://atariage.com/forums/topic/237836-my-first-homebrew-2048-4vcs/?p=3230881) has the VSYNC control modified based on Omegamatrix's first sample code above. I still have some timing overruns when the game logic gets busy (usually when the grid is at least moderately full and a new move is processed), but there has not been any "easy" fixes for that so far. I may need to refactor my code a bit more to spread out the processing related to each move.

Edited May 4, 2015 by MLockmoore

[Thomas Jentzsch]

I still have some timing overruns when the game logic gets busy (usually when the grid is at least moderately full and a new move is processed), but there has not been any "easy" fixes for that so far. I may need to refactor my code a bit more to spread out the processing related to each move.

I had similar problems when developing Three.s. The problem is, that the run time of random number based loops is hard to predict. Then you have two options:

1. Make it more predictable: E.g. when you know, that the number of allowed values is limited during the game, change the logic a bit. If e.g. up 16 values are allowed at the start you do something like AND #$0f, later if only 8 or less values are allowed you change that to AND #$07. That way you reduce the odds for looping and increase the chance that the loop ends within your time budget.
2. Allow your logic to abort and resume. Then you check the timer while looping and abort the logic when the timer becomes critical. And resume the logic during the next timer phase.

In Three.s I decided for 1, because it is much easier to implement and not harmful to the game. It is not 100% failsafe, but I did the math and the chances for failing are very, very low. So I still allow an occasionally timer overflow to happen, but made it very unlikely.

[Sohl]

Thanks for the suggestions Thomas. I have a lot of conditional logic in both the code that checks to see which of the four move directions is allowed as well as the code that moves/merges tiles during a move. Depending on the occupation of grid spacing, some of this logic has "early out" and runs faster. Unfortunately, the worse case for these is too long. I think I can further break up the logic over more video frames. Tedius, but should still play fairly well.