-
-
Notifications
You must be signed in to change notification settings - Fork 172
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
Conversation
@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 🙂 ) |
Jane's ATF fixed in DOSBox Staging 8-bit SVGA LUT PR: 👍 |
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? |
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 ![]() |
Windows 3.1, 95, 98, and ME S3 drivers use the hardware cursor. |
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)) |
50ebe93
to
2d4794d
Compare
2d4794d
to
8990019
Compare
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. |
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). |
@johnnovak can you sign off this PR already. That's what i'm mostly interested about. 😁 |
There was a problem hiding this 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 🚀
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! |
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. |
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.