VOGONS


First post, by superfury

User metadata
Rank l33t
Rank
l33t

Anyone knows what the exact difference is between the levels of black (RGB(0,0,0) black - RGB(255,255,255) white) between actual blanking and non-active display against the active display definition of "black" (driven by an active display DAC output level)?

UnIPCemu currently displays both as the same range, but as far as I can find out, they're not exactly the same on a real video card's output (mainly active display being a bit above zero on the RGB lines, while the blanking/retrace have true black (0V))?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 1 of 3, by Battler

User metadata
Rank Member
Rank
Member

If SVGA monitors use the same specifications as (non-Japanese) NTSC, then blanking would be at 0%, while the active display (black to white) levels would be at 7.5% to 100%. But I'd look up actual (S)VGA documentation for that instead, perhals look up the voltage range and convert it to %, and then from there, converting to 0-255 should be easy.

Reply 2 of 3, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie

Looking at some RAMDAC datasheets I don't see anything that would indicate a difference between blanking level and RGB(0,0,0) level. VGA/SVGA (unlike CGA) isn't based on TV formats and uses separate sync lines so there isn't any need for separate blank and black levels on the VGA cable. Some monitors might turn off the electron beams during horizontal and vertical retrace to avoid artefacts if the brightness control on the monitor is turned up, but that's a monitor implementation detail and not anything to do with VGA/SVGA standards.

Reply 3 of 3, by superfury

User metadata
Rank l33t
Rank
l33t

I've already implemented said option for active display in UniPCemu's current commits.
It also helps seeing where the active display is actually positioned on the screen, as you can see where the active display is starting and ending and where it's not outputting any pixel data (to see if output is indeed correct).
Some display resolutions still seem to end up having too large or small front/back porch, causing the active display not to be centered on the screen somehow? That's especially clear when using high resolution with higher color modes (like ET4000 800x600x16bpp), where the front porch looks double the size of the back porch somehow?
The display is still rendering 1600x600 timings(doubled timings), but the end horizontal/vertical retrace/blank postitions aren't suitable for it(built/setup for half the required range in this case), causing it to have far too short a period to actually retrace, causing retrace to end too early, plotting overscan pixels for the next scanline instead of waiting more?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io