Skip to content

Let the VESA 8-bit mode draw lines from the DAC palette #2494

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
May 18, 2023

Conversation

kcgen
Copy link
Member

@kcgen kcgen commented May 17, 2023

Previously the 8-bit VESA mode's line drawing routine wasn't doing DAC palette lookups. This adds an equivalent linear lookup routine, but adds palette lookup.

Fixes #2486

For VGA 640x480+ modes that 8-bit VESA is typically used in, rendering is still performed in bulk at the end of the frame instead of paced out per-line because so far we haven't seen games or demos perform DAC's palette effects mid-frame in 640x480+ modes.

@kcgen kcgen added the regression We broke something 😊 label May 17, 2023
@kcgen kcgen requested a review from Burrito78 May 17, 2023 15:42
@kcgen kcgen self-assigned this May 17, 2023
@kcgen
Copy link
Member Author

kcgen commented May 17, 2023

@joncampbell123 - thanks for your suggestion that the cause for the 7th guest issue was DAC related.

When @Burrito78 mentioned it didn't show up in the captures, I suspect it was alpha-channel related downstream from vga_draw in SDL main.

But indeed, adding palette lookups (just in the 8-bit VESA non HW-cursor mode) was sufficient. We're still not rendering per-line using the PIC timers here (and still using parts, which is enough - for now, anyway 🙂 )

@Grounded0
Copy link
Collaborator

Grounded0 commented May 17, 2023

Jane's ATF fixed in DOSBox Staging 8-bit SVGA LUT PR: 👍

https://www.youtube.com/watch?v=ON58W2GMgC8

@johnnovak
Copy link
Member

For VGA 640x480+ modes that 8-bit VESA is typically used in, rendering is still performed in bulk at the end of the frame instead of paced out per-line because so far we haven't seen games or demos perform DAC's palette effects mid-frame in 640x480+ modes.

How does this fix the 7th Guest problem then? Do we have a clear understanding of why and how the flicker happens and how this fixes it? Specifically, is this a proper fix for a well-understood emulation problem, or a workaround that fixes one specific game, and maybe by fluke?

Also, how can we test the VESA hardware cursor stuff for regressions? Does Win3.x use that feature?

@Grounded0
Copy link
Collaborator

Grounded0 commented May 17, 2023

We're basically emulating S3 Trio64 hardware more accurately now because we're actually using a lookup table to pick colours in the 8-bit palette:

https://anttipeltola.eu/docs/tech/s3_trio64_datasheet.pdf

Screenshot 2023-05-18 at 1 23 25

@joncampbell123
Copy link
Contributor

For VGA 640x480+ modes that 8-bit VESA is typically used in, rendering is still performed in bulk at the end of the frame instead of paced out per-line because so far we haven't seen games or demos perform DAC's palette effects mid-frame in 640x480+ modes.

How does this fix the 7th Guest problem then? Do we have a clear understanding of why and how the flicker happens and how this fixes it? Specifically, is this a proper fix for a well-understood emulation problem, or a workaround that fixes one specific game, and maybe by fluke?

Also, how can we test the VESA hardware cursor stuff for regressions? Does Win3.x use that feature?

Windows 3.1, 95, 98, and ME S3 drivers use the hardware cursor.

@johnnovak
Copy link
Member

johnnovak commented May 17, 2023

We're basically emulating S3 Trio64 hardware more accurately now because we're actually using a lookup table to pick colours in the 8-bit palette:

Huh? All VGA cards, or more broadly all devices with analog RGB output use some RAMDAC, usually with some LUT. That's not what the fix is about.

If you're referring to the "high and true colour bypass" path, that's different. Here we're essentially "pretending" for 8-bit modes that they're 24-bit true colour (stored as 32-bit XRGB8888 in memory, but that's an implementation detail).

Anyway, this becomes a bit theoretical because we're not emulating any display adapter 1:1 accurately anyway... I'm just curious how this fixes the problem, and what the actual problem is 😄

(An interesting curiosity: in earlier Amigas before they started using DACs, a resistor network was used to convert 12-bit RGB (4096 colours) into analog signals (source))

@kcgen kcgen force-pushed the kc/vesa-8bit-use-palette-1 branch from 50ebe93 to 2d4794d Compare May 18, 2023 02:52
@kcgen kcgen force-pushed the kc/vesa-8bit-use-palette-1 branch from 2d4794d to 8990019 Compare May 18, 2023 07:16
@joncampbell123
Copy link
Contributor

joncampbell123 commented May 18, 2023

We're basically emulating S3 Trio64 hardware more accurately now because we're actually using a lookup table to pick colours in the 8-bit palette:

Huh? All VGA cards, or more broadly all devices with analog RGB output use some RAMDAC, usually with some LUT. That's not what the fix is about.

If you're referring to the "high and true colour bypass" path, that's different. Here we're essentially "pretending" for 8-bit modes that they're 24-bit true colour (stored as 32-bit XRGB8888 in memory, but that's an implementation detail).

Anyway, this becomes a bit theoretical because we're not emulating any display adapter 1:1 accurately anyway... I'm just curious how this fixes the problem, and what the actual problem is smile

(An interesting curiosity: in earlier Amigas before they started using DACs, a resistor network was used to convert 12-bit RGB (4096 colours) into analog signals (source))

You'll find that the RAMDAC is still in effect in highcolor/truecolor modes. It still remaps values. The difference is that in highcolor/truecolor modes it remaps each channel independently (R/G/B). This is how SVGA cards from the late 1990s onward are able to offer those nifty "gamma correction/brightness/contrast" settings in all supported desktop modes. As a weird example, the Radeon framebuffer driver in Linux used to have a strange quirk where it relied on that remapping to render the framebuffer console using the first two "steps" of the gamma ramp. A side effect of this is that if you were writing code to try to draw images on the framebuffer, they came out all messed up because of that mapping, unless you were willing to fiddle with the colormap ioctls() to program a linear ramp, at the cost of making your Linux framebuffer console text and shell prompt dim colors.

@johnnovak
Copy link
Member

You'll find that the RAMDAC is still in effect in highcolor/truecolor modes. It still remaps values.

Oh yeah, that's pretty much a given, regardless of whether we're dealing with paletted or high/true-colour; something must still generate analog RGB signals from the digital values. There's just one extra lookup in the case of the paletted modes. There must have been such RAMDACs on all modern boards too until they completely dropped the VGA output; now it's all digital.

Related to the gamma lookup thing you mentioned, S3 cards also have this "black pedestal" bit; I guess they switch between output signal ranges similar to the full/limited HDMI ranges. Some S3 cards default to "black pedestal = on", which leads to washed out blacks on regular VGA monitors. None of my S3 cards do that, but I found some simple utils on Vogons that can switch the pedestal bit on and off. I can turn it on on some of my S3 cards, then I get washed out blacks 😎

I guess you can only do trickery with analog circuitry to convert from digital values to analog RGB purely with analog components like in the case of the Amiga if you need very limited precision (e.g. 4-bit per RGB component in the case of the Amiga).

@Grounded0
Copy link
Collaborator

@johnnovak can you sign off this PR already. That's what i'm mostly interested about. 😁

Copy link
Member

@johnnovak johnnovak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work @kcgen, merge away 🚀

@kcgen kcgen merged commit d3403e0 into main May 18, 2023
@joncampbell123
Copy link
Contributor

joncampbell123 commented May 18, 2023

You'll find that the RAMDAC is still in effect in highcolor/truecolor modes. It still remaps values.

Oh yeah, that's pretty much a given, regardless of whether we're dealing with paletted or high/true-colour; something must still generate analog RGB signals from the digital values. There's just one extra lookup in the case of the paletted modes. There must have been such RAMDACs on all modern boards too until they completely dropped the VGA output; now it's all digital.

Related to the gamma lookup thing you mentioned, S3 cards also have this "black pedestal" bit; I guess they switch between output signal ranges similar to the full/limited HDMI ranges. Some S3 cards default to "black pedestal = on", which leads to washed out blacks on regular VGA monitors. None of my S3 cards do that, but I found some simple utils on Vogons that can switch the pedestal bit on and off. I can turn it on on some of my S3 cards, then I get washed out blacks sunglasses

I guess you can only do trickery with analog circuitry to convert from digital values to analog RGB purely with analog components like in the case of the Amiga if you need very limited precision (e.g. 4-bit per RGB component in the case of the Amiga).

As far as I am aware, the "palette as gamma ramp" behavior remains standard even on chipsets that can do both VGA, DVI, and HDMI even well into the 2010s. My current laptop I purchased in 2019 with an Intel CPU (laptop display and HDMI port) clearly still has that feature because I can use the "xgamma" command on my Linux desktop to play with it.

My old Pentium 100MHz from long ago still has the S3 ViRGE PCI card I bought in the late 1990s, and I found the datasheet years later, I'll poke around and see if this pedestal bit exists there too. The Linux kernel seems able to talk to those cards still, evident by the fact that if I power it on and boot into Linux with a 1080p flat panel attached it is able to set up a 1920x1080 256-color framebuffer 😆 not bad for a late 1990s SVGA card!

@joncampbell123
Copy link
Contributor

joncampbell123 commented May 18, 2023

The funny thing about the Radeon case is that I ran into it long ago when I installed Yellow Dog Linux on an old PowerPC Apple PowerBook (you can dual boot Mac OS X and Linux on those!). The ones in the early to mid 2000s used ATI Radeon chipsets. We used to do video production in the late 2000s and we used it all the time to capture MiniDV tapes in Linux through all those Firewire ports Apple laptops used to have back then. It was an odd problem when I wrote my own code to draw on the framebuffer, though obviously programs like X-Windows and MPlayer were aware of it and did the colormap controls to compensate when you ran them.

@kcgen kcgen deleted the kc/vesa-8bit-use-palette-1 branch May 18, 2023 18:51
@johnnovak johnnovak added the video Graphics and video related issues label Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression We broke something 😊 video Graphics and video related issues
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

7th Guest FMV flickering
4 participants