Messed around with this a bit more today.

Vbeplus kinda created some custom modes that “worked.” It doesn’t double scan or clock the pixels across the horizontal. This utility is meant to intervene for later cards with vbe3, but I’d thought I would try it.

It will run fastdoom like this. Duke 3D locks up shortly after launch.

Still interested in hearing from any of you that have tried low res VESA with the S3 805. It is an interesting beast.

Hardware bugs and multiple revisions of the chip… I wonder what the full story is.

Forcing univbe 6.53 to use their S3 vision868 settings for an S3 805 card seems to “unlock” low res vesa modes

The graphics are glitched similar to the older univbe 5.1 version.

Very interesting.

I wonder if they saw the glitches were happening while making the card and instead of fixing the faulty display modes they disabled them instead

Probably the reason the S3 805 doesn't support linear addressing is that it was designed for ISA (16-bit host interface), and possibly uses 24-bit addressing (16MB). Linear frame buffers are normally placed above 16MB as far as I know. Maybe you can have a look at the databook to find the answer.

VESA LFB on ISA is supported and supposed to be mapped into 15-16MB memory hole. Card also needs to be wired for it (MEMR vs SMEMR).
This card is wired for LFB support for example https://www.vgamuseum.info/index.php/componen … 346-s3-86c801-r
Not that one needs LFB for 320x200@256 VESA mode so thats not it.
I bet someone clevererer than me could recognize what the ram addressing problem is by the pixels alone.

Even and odd bytes are reversed in those screenshots. Basically any VGA card can do 256-color VESA banked modes as long as it has a bank switching mechanism. It's funny to see a broken VESA version of a standard VGA mode. Are there other VESA modes that do work?

Other VESA modes do work - including low res 320x200 at higher color modes.

While using univbe 5.1a configured for the 805, fastdoom can run in VBR mode fine. Attempting to run in VBD mode errors to the desktop saying that direct mode requires 8-bit color.

So I assume fastdoom must recognize the 805 and bump it to a higher color mode to mitigate the odd 256 color bug with vesa? I guess we would have to ask viti.

CkRtech wrote on 2026-04-22, 21:15:

So I assume fastdoom must recognize the 805 and bump it to a higher color mode to mitigate the odd 256 color bug with vesa?

Definitely not, it only checks modes supported. VBD is LFB, requires actually working linear framebuffer.

>fastdoom can run in VBR mode fine

Afaik from fastdooms perspective there is no difference between 13h and VBR, both draw to BACKBUFFER and copy in bulk.
VBD on the other hand https://github.com/viti95/FastDoom/blob/adb6f … bc/build.sh#L86 buildopts="-dMODE_VBE2_DIRECT" tries drawing (and reading in case of transparent sprites) to Video ram directly.

From video card perspective difference between 13h and VBR is ability to disable internal chaining (Chain 4). Chained mode Chains 4 bytes when accessing one byte making it unnecessarily heavier on cards bandwidth. VESA allows the VGA chip to disable that invisible chaining and internally map byte to byte. This is what makes M13SPEED tool work so well https://www.geocities.ws/liaor2/myutil/m13speed.html

From video card perspective VBD (linear) 320x200x8 is just that same VBR mode but mapped somewhere high in ram.

Afaik from fastdooms perspective there is no difference between 13h and VBR, both draw to BACKBUFFER and copy in bulk.

I suppose I was just thinking out loud about possibilities for Fastdoom to mitigate whatever may have been causing that odd byte swap-looking bug as bakemono mentioned. Using more colors does seem like it would be throwing more bytes at the problem in order to solve it - not to mention wreaking havoc on palettes.

It is interesting that while vbetest (banked) shows that byte-swap bug with univbe properly configured for the S3 805 when testing, Fastdoom does not exhibit the bug.

However if you override the chip to something like Vision868 (rather hacky...), vbetest (banked) shows that byte-swap bug once again... and so does Fastdoom.

Curious.

Sorry if it seemed I was shouting (BACKBUFFER), I was copying from fdoom sourcecode and only now realized how it looks 🙁

1#if defined(MODE_13H) || defined(MODE_CGA_BW) || defined(MODE_CGA16) || defined(MODE_CGA) || defined(MODE_CVB) || defined(MODE_HERC) || defined(MODE_INCOLOR) || defined(MODE_PCP) || defined(MODE_VBE2) || defined(MODE_EGA) || defined(MODE_CGA_AFH) || defined(MODE_CGA512) || defined(MODE_SIGMA)
2#define USE_BACKBUFFER
3#endif

one more possibility, since fdoom is copying Backbuffer its going to use 32bit writes. vbetest might be doing single pixel/byte or word writes thus different access pattern. fdoom VBD mode is definitely doing direct 8 and 16bit writes.

Does the card support Vesa 640x400@8? m13speed secret sauce is setting that mode and then manipulating CRTC to only display upper left corner or soemthing like that.

rasz_pl wrote on 2026-04-23, 17:18:

Does the card support Vesa 640x400@8? m13speed secret sauce is setting that mode and then manipulating CRTC to only display upper left corner or soemthing like that.

It does, and it works well with LFB.

M13speed, as noted by the readme, doesn’t seem to work as it isn’t a trident card. (I only tried it with banked mode 100h available via univbe.)

CkRtech wrote on 2026-04-23, 20:50:

It does, and it works well with LFB.

then there might be a chance?

CkRtech wrote on 2026-04-23, 20:50:

M13speed, as noted by the readme, doesn’t seem to work as it isn’t a trident card. (I only tried it with banked mode 100h available via univbe.)

Yes M13speed is trident specific, but the method might work on S3 if you get your hands on datasheet or disassemble univbe to figure out which registers are responsible for defining custom video modes

So I made a TSR to override a call for VESA Mode 0x163 (320x200x8) and instead use VESA Mode 0x100 (640x400x8), and I started tweaking registers to "make" a 320x200x8 VESA mode out of it.

The same override was used for Mode 13h just for the heck of it.

In short I got something to work, but it wasn't worth it.

It seems like tweaking the various registers for a low res 320 mode just never works quite right. At best, I was able to get it to double the scanlines (so 200 lines fill the entire 400 lines). However, halving the pixel clock to get it to stretch across the screen doesn't work. That may have been univbe's issue with refresh rates. I don't know.

Double scanlined without the dot clock tweak resulted in a duplicate 320 image side by side. If it was worth it, a scaler such as the OSSC Pro could handle this.

However!

Use of the linear framebuffer results in flickering. Whatever the cause, I assume this is why Univbe basically said "forget about it!" in their warning message regarding 320x VESA modes.

The biggest difference I could see was maybe 2fps with a Mode 13h substitution in Fastdoom.

Ultimately, a stripped down, fake VESA 320x mode on an S3 805 didn't seem to offer much benefit versus using Mode 13h. For other VLB cards - those that can have "native" 320x200x8 VESA modes with LFB support - they will see improvements in something like Fastdoom and Duke Nukem 3D.

For the S3 805 - a bridge chip from ISA 801 to VLB - the chip really seems like a hacky stopgap that led S3 to say, "let's just design another chip."