So then the 3D vectorbobs should have:
(128 rows*2 scanlines/row)+05 scanlines adjustment=261 scanlines. Your code says 262 scanlines? Didn't the docs say this is simply added?

Edit: Just looked at the manual again. It says it's a fraction of the character clock. Also looking at the vertical timings shows the following:
Nvsp = 16 x Tsi
Tadj = Nadj x Tsi

Seeing as reenigne multiplied the character clock by 2 to get 16(8 is used in my emulation, although halved when setting it's position), I assume Nadj is the amount of scanlines after VTotal+1 vertical character clocks before starting a new frame(Going back to Scanline #0)?

I don't see anything in the documentation of the chip about 1 being added to the value of the register, as it's programmed. It's used directly once the final clock has ended according to it's timings graph.

Your code loads the value 05h into the register. The commentary says it's 6 scanlines. But the documentation says 5 lines, as you're programming it. If it's set to 0, nothing is added, thus the vertical total(register 04h) times character height is your vertical timing.

So in fact, the timing used doesn't match the timing as documented, as the vertical total adjust is one scanline too small. Thus you end up with modes with strange framerates, which the camera has trouble with.

Anyone can verify this? I just looked at the chip documentation and timing and saw this strange timing issue. Although it might be something's misread here?

Edit: Double checked to make sure:
http://www.oldskool.org/guides/oldonnew/resou … ces/cgatech.txt

3D4h index 04h (W): Vertical Total Register Bit 0-6 Number of character rows in a frame. This is adjusted by the number […]
Show full quote

3D4h index 04h (W): Vertical Total Register
Bit 0-6 Number of character rows in a frame. This is adjusted by the number
of scanlines in a character (index 9) and the Vertical Adjust (index
5).
Note: this register is Read/Write on the CT82c425/6.

3D4h index 05h (W): Vertical Total Adjust Register
Bit 0-3 Number of scanlines added to the Vertical Total time.

This confirms it. The problem you're having is because the vertical total adjust register is programmed incorrectly. It's supposed to be the number of extra scanlines to be added. Nothing is said that 1 scanline is added to it as far as I can see. Thus vertical total has 5 scanlines added instead of 6 because you've programmed it wrong. Change the vertical total adjust to 6 instead of 5 to get the right screen height(262 scanlines at 59.72FPS).

superfury wrote:

Your code loads the value 05h into the register.

It loads 6 into the register. The low byte (5) is the register number, the high byte (6) is the value.

reenigne wrote:

superfury wrote:

Your code loads the value 05h into the register.

It loads 6 into the register. The low byte (5) is the register number, the high byte (6) is the value.

Whoops, looking at it again while keeping I/O order(low byte to first port(index), high byte. to second port(data)) in mind, you're right.

In that case, it looks like it's indeed generating a proper 59.97 FPS framerate.

Is this timing also applied to the detection screen? I think not, because it ends up one scanline short. Assuming all other timing is correct, that should be fixed by increasing the vertical total adjust register by 1 to obtain proper 59.97Hz timing(And, if needed, patching the used 'vertical scanline counter' used by 8088 MPH for tracking scanlines to use one line more each frame to keep it's timing correct).

Of course this expects the camera itself to be able to record 59.97Hz video. When this is the case and it still not works, then maybe it's a synchronization error? Like it(the camera) expects a frame to start, but the application is further ahead/behind because of the mode change or previous section of 8088 MPH?

Or maybe even more simple: because the timing of the detection screen is off by one scanline, the rest of the demo is off as well, which keeps accumulating until it reaches the vector bobs, at which point it's so far out of sync the camera can't synchronize anymore, at which point it gives up trying to decode correctly(or is simply off sync by the one scanline, reading data incorrectly), thus it gives the wrong input?

superfury wrote:

Is this timing also applied to the detection screen? I think not, because it ends up one scanline short.

Right - the detection screen uses multiple CRTC frames during the CRT frame, so it's easier to screw up.

superfury wrote:

Of course this expects the camera itself to be able to record 59.97Hz video. When this is the case and it still not works, then maybe it's a synchronization error? Like it(the camera) expects a frame to start, but the application is further ahead/behind because of the mode change or previous section of 8088 MPH?

Yeah, this is likely what's going on with the vectorballs. Monitors (and capture devices) are supposed to be able to self-synchronize, but perhaps there's a bug in the vsync handling of this capture device which makes it get into a confused state on some mode changes.

superfury wrote:

Or maybe even more simple: because the timing of the detection screen is off by one scanline, the rest of the demo is off as well, which keeps accumulating until it reaches the vector bobs, at which point it's so far out of sync the camera can't synchronize anymore, at which point it gives up trying to decode correctly(or is simply off sync by the one scanline, reading data incorrectly), thus it gives the wrong input?

When it's capturing correctly, the capture device's sync oscillators are locked onto the sync signals generated by the CGA card (in both frequency and phase). So there's nothing to accumulate.

reenigne wrote:

Yeah, this is likely what's going on with the vectorballs. Monitors (and capture devices) are supposed to be able to self-synchronize, but perhaps there's a bug in the vsync handling of this capture device which makes it get into a confused state on some mode changes.

You could try renaming the parts to change the order of the demo. If the sync-issue still occurs during the vectorbobs even when they are at a completely different place in time, then the issue is related to that part. If the issue happens at about the same time, but in a completely different effect, then it is more likely that the capture device's state is getting confused.

I've made a little recording of the latest x86EMU build running 8088 MPH(although audio is slightly earlier because it's manually started at around the same time as recording using RALT-F6, probably just a fraction of a second later than the recording):
https://www.youtube.com/watch?v=VJhpp2Rp_eE

There's still the problem with the Kefrens Bars going out of sync, but at least they show up fine (looking at the horizontal timing), as the overscan and active display seem to match their background colors now, because of the change in horizontal retrace vs horizontal total logic. The horizontal total now only resets the horizontal timing for driving the CRTC. The horizontal sync handles all other timing (VRAM, CRTC retrace, Scanline incrementing for both VRAM and CRTC).

The flickering of the images is also gone due to the last few updates. Also the credits now have less lagg due to better optimized rendering(mostly memprotect calls being simplified(removed and only checked when starting the rendering to/from SDL_Surfaces), making it much lighter on the CPU to execute). On my slow laptop (2.0GHz dual core CPU) it went from a small 5% CPU speed to 50-80% CPU speed, because of these optimizations. On this fast PC it's recorded on this is especially noticable as the credits have almost no lagg anymore (you only hear the sound stuttering a few times instead of each time text is drawn on the screen), and it seems only on regular intervals (due to CPU vs Audio thread synchronization probably).

Other things that have been optimized include things like the DMA transfers and CPU prefetch queue fetching memory.

Any luck with the recordings?

superfury wrote:

Any luck with the recordings?

I haven't done anything else with respect to investigating why the vectorballs effect wasn't captured properly. Since I'm not planning to make any more versions of 8088MPH it's pretty low priority. Eventually I hope to put together a capture device that can capture a continuous stream of data (doesn't have "gaps" during the vsync period). That will tell me for sure whether there's anything strange about the sync pulse structure on this effect.