Using variable number of HBLANK lines?

[jmchacon]

I noticed combat seems to generate an odd looking frame compared to specs as laid out in the Stella guide.

 

This is running in attract mode when I first turn it on and cycling through game select for a minute.

 

I see (for game 1) a frame of

 

VSYNC - 3

VBLANK - 45

Picture - 221

VBLANK - 3

 

Every 16th frame or so it changes to:

 

VSYNC - 3

VBLANK - 38

Picture - 221

VBLANK - 3

 

So the visible picture remains constant but # HBLANK lines jumps around. I see this as well on other game selections but on some it's even worse (like every 4th frame). Dropping in space invaders shows something similar. Reading through the Stella code it appears to handle this by working in some slop on VBLANK turning off to within some limits (with the additional jitter emulation should one want a rolling screen).

 

Did the TV just have enough slop in it's vertical hold that it didn't jump when the occasional frame did this as long as total visible picture remained constant?

 

Also there's barely any overscan here (3 lines worth) which seems at odds with the suggested 30 the Stella guide suggests? I know the TV can display 262/263 (ok, generally 242/243 with the minimum 20 lines of VBLANK).

 

 

[DirtyHairy]

This is not how Stella works As you have found, frame detection and management during gameplay happens in FrameManager.cxx. There are two parameters: the line count of the vertical blank region ("ystart" in Stella terminology) and the frame layout (NTSC or PAL). The progress of the frame is tracked by a state machine

• State 0: overscan ('State::waitForVsyncStart')
• State 1: vsync ('State::waitForVsyncStart')
• State 2: vertical blank ('State::waitForFrameStart')
• State 3: kernel ('State::frame')

The possible transitions are:

• 0 -> 1: vsync is enabled in state 0
• 1 -> 2: vsync is disabled in state 1 (or line count in 1 exceeds a threshold)
• 0 -> 2: line count in 0 exceeds a threshold
• 2 -> 3: line count in 2 exceeds ystart
• 3 -> 0: line count in 3 exceeds frame height (depending on the frame layout)

Both ystart and frame layout are either supplied as parameters for the ROM being emulated, or they are detected in a "preflight emulation run" before the actual emulation starts --- this is what FrameLayoutDetector.cxx and YStartDetector.cxx are for. So, if the values you measured were correct, Stella wouldn't display a stable frame either, there is no magic correction.I should add that the code was much more magic and slightly less stable in 5.0 though, that was one of the improvements in Stella 5.1.

 

I just dropped a bunch of debugging lines in FrameManager.cxx, and this is what I get from the state machine for Combat NTSC (MD5 4c8832ed387bbafc055320c05205bc08):

moving to state 0 after 212 lines
vblank 0 -> 1 @ 257
moving to state 1 after 14 lines
moving to state 2 after 3 lines
moving to state 3 after 34 lines
vblank 1 -> 0 @ 36

The number after the state is the number of lines spent in each state; the number after the vblank transition is the absolute frame line in which the transition happens (counted from the start of vertical blank). The pattern is perfectly regular --- I can't see anything odd.

Edited June 19, 2018 by DirtyHairy

[jmchacon]

Hmm...Ok, I might have something wrong with my timing then in my emulator. I'm not 100% convinced my PIA implementation is perfect. Could be on some frames it's not dealing with the timer quite right.

[jmchacon]

Heh...Yep..I completely misread part of the PIA docs and only had the timer registering 0 for a single clock no matter the multiplier. That doesn't work when a read of it takes 3 cycles and code is doing a BNE to test against it.

 

Fix that and I also see very stable frame counts/sizes in my own code. Good way to learn

[+SvOlli]

Hint: you can (mis)use the interrupt register for detecting the timer underrun. I typically do it like this:

 

lda #value

sta TIM64T + 8 ; enable interrupt on timer underrun

loop:

; [...do stuff...]

bit TIMINT

bpl loop

 

even though the interrupt line is not connected to the CPU, you can still use the registers even without getting an interrupt.