It is natural and expected that no two "70 Hz" video modes will have the same exact 70 Hz refresh rate value.

I have two SpeedStar 64 adapters, one is like this:

The vertical refresh frequency ends up being derived from the video pixel clock, which is defined on a modern card like this by PLL frequency numerator and denominator I/O register values that are programmed by the card's Video BIOS into the mode table for each video mode. Then further horizontal and vertical video geometry parameters (active, border, blank, front porch, sync, back porch for horizontal and vertical) for each mode turn the pixel clock into a specific resulting vertical refresh value.

For example, the 720x400 text mode 03h on my copy of the card is 70.092... Hz:

320x200 Mode 13h on the other hand is 70.229... Hz:

or Pinball Fantasies, which is also "70Hz", is 70.405... Hz:

The 320x240 60Hz Mode-X on the other hand on my copy of this card is 59.835... Hz:

Every physical copy of a card will of course have slight % variations, so values on your card will be +/- a couple of Hz different than the above numbers.

Note that these numbers like "59.835..." do not accurately/precisely capture a refresh rate, but refresh rate really is an infinitely irrational fractional number - an approximate measurement of a physical process that takes place, driven by a clock source, hence the ...

Because every video mode uses its own distinct video geometry parameters (active, border, blank, porch, sync, porch), even if the identical pixel clock PLL parameters were used, it is physically impossible to have the same vertical refresh rate down to the Hz for different output video mode. I.e. it is expected and natural that every video mode will have a unique vertical refresh rate that is not the same across other modes, like 70.092 Hz or 70.229 Hz.

In other words, every mode that is supposed to be "70 Hz", will have its own "70 Hz", unless they have identical video geometry parameters and identical PLL source - (which effectively just makes them the same video mode, maybe differing only by bit depth or text vs graphics mode scanout parameters).

However, it is likely not the refresh rate number changing that requires a resync on the receiving end, but it is the video mode geometry parameters changing, that will have to trigger a mode resync. Moving between 03h text and 13h graphics for example would do that. It sounds like your first OSSC sync issues would have been due to OSSC getting confused by video mode changes, and having to resync as result.

The second issue with the KVM dropping video sync when the video mode is not changing smells to me like it could be max. pixel clock or max. vertical refresh rate limitations of the KVM device. If the pixel clock you are feeding to it is relatively high, can you try lowering the OSSC upscaling settings so that a lower pixel clock will be sent to the KVM? Maybe that might avoid the sync issues, if it is operating at its limits. It could also be that the KVM is not ratified for 70 Hz video input usage in general, so it is hitting luck whether it's syncing or not in general at around ~70Hz vertical refresh rate.

Yea, I misspoke on Mode-X, forgot that's 60 Hz. No issue there. What's odd is that the same exact game (ie. Keen4) can be both problematic at 70.24 Hz and work fine if it just randomly syncs at 70.08 or 70.16 Hz when it first starts up. Text modes at 70.24 Hz seem unaffected and work fine.

Why would the same game, making the same mode change from text mode to 320x200x256, display these occasional dropouts at 70.24 Hz, but work fine at the lower frequencies? Again, the sync frequency appears random on game start and will be one of those 3 values.

Specs on the DKVM-4 indicate 1600x1200 max resolution. Product is from the early 2000s. I have other VGA adapters (PCI NV TNT, PCI CL-GD5446) that work completely fine with the KVM at these resolutions and up to 800x600 (32-bit color). Cables are all same, etc.

ahyeadude wrote on 2024-12-30, 01:50:

Yea, I misspoke on Mode-X, forgot that's 60 Hz. No issue there. What's odd is that the same exact game (ie. Keen4) can be both problematic at 70.24 Hz and work fine if it just randomly syncs at 70.08 or 70.16 Hz when it first starts up. Text modes at 70.24 Hz seem unaffected and work fine.

Why would the same game, making the same mode change from text mode to 320x200x256, display these occasional dropouts at 70.24 Hz, but work fine at the lower frequencies? Again, the sync frequency appears random on game start and will be one of those 3 values.

Specs on the DKVM-4 indicate 1600x1200 max resolution. Product is from the early 2000s. I have other VGA adapters (PCI NV TNT, PCI CL-GD5446) that work completely fine with the KVM at these resolutions and up to 800x600 (32-bit color). Cables are all same, etc.

This kind of behavior does sound to me like a possible situation that could happen when maximum bandwidth is exceeded. When a PLL sync is attempted beyond the high end of the supported range, there can be some amount of resonance/quantization/aliasing that is taking place at the synchronization end, that can make it look like some exact frequencies don't work, but then bumping a bit higher again works, then bumping a bit higher no longer works, and then a bit higher again works, until everything fails. I.e. it might not be a hard limit that frequency >= x no longer works at all.

Even if the device indicates a max 1600x1200 resolution, they quite likely might mean 1600x1200@60Hz, since 1600x1200 resolution was used already in the era when 60Hz was normalized. So try to be specific to find a mention of 1600x1200@70Hz in the data sheet, or see if lowering the upscaled resolution in OSSC makes any difference.

Another thing that might cause issues at overclocked pixel clock speeds can be the actual pixel content in the image that is being synchronized to. For example, this specific screenshot is part of the video signal unit test suite that we use for CRT Terminator sync/upscaling support:

What makes this image special is that it uses heavy dithering, so the image line varies pixel by pixel, causing effectively maximum amount of noise interference inside the device as the image rapidly flickers on every pixel.

Stepping away from the "too high pixel clock" hypothesis, another guess could be the specialty of Keen that it uses a non-black VGA border, e.g. that above Keen5 image is actually like this on the wire:

so it might throw off a more modern VGA sync device that might expect that the VGA border should be all black, and never anything else. You could try a selection of other DOS VGA games that keep the border all black.

I replaced the 14.31818 MHz oscillator with a NOS part and that fixed it. Maybe it had a weak or noisy output or something. I wish I had a scope to confirm.

Idk if it is actually relevant but you're correct about the ossc maxing out at 60Hz in 1600x1200. That's the limit of the digitizer chip

Yea, I'm only using a 2x scaler on 320x200 mode 13h. 1280x800 is the resolution of the output from OSSC.

Maybe I wasn't clear in my post. The KVM is a VGA KVM. So, VGA Card --> DKVM-4 --> OSSC --> Monitor (DVI).