TheGreatCodeholio wrote:That's also what I had in mind! I always thought that what DOSBox was missing (and what modern LCDs and TVs are hiding from you on VGA inputs) are the overscan border that you used to be able to see on VGA monitors. Also that DOSBox's focus on the active picture area isn't very helpful when you're trying to write and test custom modesetting code. It doesn't show you how a VGA monitor would position the active area based on the blanking parameters you programmed. So you'd think everything was fine until on real hardware your VGA monitor shows the picture halfway off the monitor!
What's worse, DOSBox does not actually emulate the full screen timing. It seems to just grab the effective width/height of the screen area, and that's it.
I encountered this a few days ago, when I tried to run this prod: http://www.pouet.net/prod.php?which=65292
Apparently it was written against DOSBox, and never tested on real hardware.
The code to set up the 80x50 and 80x100 tweaked textmodes was really sloppy, and did not program the vsync area properly. DOSBox didn't care, but this is what happened on real hardware: https://youtu.be/E1B8yO3kJ-U
Because they only reprogrammed the number of visible scanlines, the vsync area just shifted upwards, and your frame was just shortened, causing multiple frames to appear inside a single image on the monitor.
Another, unrelated, issue here is that they also used the AT-based CMOS timer and second interrupt handler.
DOSBox doesn't care about that. It would be nice to have more control over what hardware your configuration does and doesn't have.
An 8088-class machine will not have such AT-hardware, so you should be able to disable it in your configuration.
TheGreatCodeholio wrote:Actually Scali that's an interesting point. As far as I know the raster bars can't extend into the blanking area of the VGA (or maybe, some SVGA chipsets allow that?). I'm not so sure about CGA.
Well, I'm not entirely sure what happens on RGB interfaces, since they have separate lines for syncing and for colour.
So I think in theory they could just leave the background colour on at all times.
I'm quite sure VGA doesn't do this though, from what I recall on CRT screens, the VGA border was only a few pixels wide, and if you used the dials on your monitor to shrink the image, you'd get black around it.
CGA RGBI extends the border much further, basically full overscan. EGA probably does the same, since it uses the same RGBI interface.
I do see black if I turn my screen all the way to the right, but I'm not sure if that's because the RGBI is turned off for a small part of the screen, or if it's just because my screen is so far out of whack that the signal simply doesn't reach that part of the CRT anymore.
With CGA composite, there is just one signal, so the colour has to be turned off during horizontal blank, to sync the screen, as far as I know.
On a C64 you'd get the same thing, but the debug view in Vice is just that: debug. It just visualizes the full width of the scanlines, so you can see what cycle-timed code does even in those places, even though you probably could never get that part on screen from a real C64.
TheGreatCodeholio wrote:But since the DOS program can reprogram those CRTC parameters anyway there's no reason I know of that you can't just extend the overscan border all the way out to the point that it sits right against the h/v retrace area, effectively removing the blanking area.
Hum yes, that is an interesting point. I wonder if reprogramming the VGA registers changes the border size, and if so, how does it respond?
That's something that would need to be tested on real hardware.
I know on CGA that if you use a smaller window tweakmode, the background colour still extends to full overscan.