http://www.osdever.net/FreeVGA/vga/vgafunc.htm
http://www.datasheetcatalog.com/umc/1/ (um487, um587, um6845xx)
ftp.yars.free.net/pub/doc/ Hardware/Video/Banshee_2d_spec.PDF
www.versalogic.com/Support/Downloads/pdf/69030bg.pdf
http://developer.intel.com/design/graphics/mo … ts/ds_65510.htm
http://developer.intel.com/design/graphics/mo … ts/ds_65535.htm
http://physio.phys.szote.u-szeged.hu/bbalazs/ … b/lcd/65545.pdf
http://www.google.com/url?sa=U&start=2&q=http … eet.pdf&e=10313
developerpit.com/voodoo3.pdf
intel has 810 & 855 datasheets at their site(they bought c&t chips).

Used to find cirrus datasheets everywhere; now can't find them anywhere.

The attachments are info from datasheet via google cache because the pdfs are now gone.

Updated patch is up on SourceForge 😀 . It integrates all changes mentioned in this thread plus some cleanups/improvements. Sorry, still no Virtual Pool and Paradise chipset support 🙁
Thanks for those links, those are good. There are still a few things that remain unclear. I'll just continue experimenting.

BREAKTHROUGH! Just one hour after I've submitted updated patch I finally found why Virtual Pool did not work. More, I've got it working in 640x480!
My previous theories were wrong. There was very simple bug in my code, typical chicken-and-egg problem that silently crippled chipset emulation. For those that are curious -- in file vga_svga.cpp functions VGA_SetupAttr_SVGA and VGA_SetupSEQ_SVGA were never called. The call context assumed that chipset type is known but the context was reached before that. The fix is to force those two calls from VGA_SetupSVGA (same file). It is not a clean solution, I am working on a better one, but it works. I've also figured out fixes to make Virtual Pool correctly recognize ET4K, those are minor and unrelated. Not as important as that other fix -- there is manual override in Virtual Pool. Well, I tried to fix those when I noticed that some code does not get called when it should. The rest was easy.
BTW, Virtual Pool really should be played in 640x480! 320x200 just does not do it justice.

Oh Happy Day! I've been waiting for Virtual Pool to be fixed in DosBox for a loooong time! Sweeeeeett. Good work!

As for Paradise chipset, I've spent the last hour hacking some basic implementation of PVGA1A. It's not going to be that simple, some core logic needs to be changed to accomodate very flexible banking scheme (two independent banks, bank size is not the same as bank granularity). However, I've got Wonderland working in 800x600 already -- it is using 16-color mode and does not do much SVGA magic if any. So, the primary goal is already achieved. WHATVGA correctly identifies my implementation as PVGA1A, even shows correct VRAM size but 256-color modes are still garbled due to incorrect mapping. In addition, Eric the Unready (non-VESA compatible version) also works fine in 800x600 in this driver. I will try to fix 256-color modes to the point where WHATVGA likes them. I don't have particularly good test cases for that chipset so any suggestions are welcome.
On the side note, Wonderland somehow does not gain that much from 800x600 mode -- Magnetic Windows allow user to configure it to great extent. It's not like Legend's games which become very crowded on 640x480 screen.

Great work.
Virtual snooker also works in tseng 640x480 although it did already work with VESA 640x driver. 1024x768 tseng 4000 accel driver partially works but it shows mostly artefacts on screen (game menu is working).
VGA modes with tseng emulation still produce white&black vertical strips in both virtual snooker/pool.
Have fun with paradise 😎

Speaking of differences, the tseng emulation doesn't have big lags in pirates gold that the s3 code has.

This is somewhat odd but I have a theory: S3 is single bank card, Tseng is dual bank one. The game is targeted to dual bank and uses some regular memory buffer to emulate dual bank behavior on single bank hardware. Clumsy but not entirely unexpected. I just did not expect that there are games in which this effect is actually noticeable.
On the [not entirely] unrelated news, I've got Paradise driver working in 256-color modes without big difficulties. WHATVGA works correctly, same for DPIIe. I don't have dual bank implementation (the really tricky part of that driver) but I don't have test cases for that anyway. Observation: in early games developers did not understand how to use those quirky features of chipsets so they did not use them; in late games they had to support multiple cards so they targeted more or less common functionality, leaving quirks unused again. I've noticed this with Tseng, I am seeing it with Paradise. What that means is there is not that much work to get a driver to very good compatibility level but there is much more work to bring it to excellent level, and the difference is rather small.

found a really good resource: http://www.mcamafia.de/pdf/pdfref.htm

ps/2 tech ref manuals! Models 50/60/80 were the first PCs with vga(released at the same time). Other than empirical testing, the ultimate authority. They don't have the first editions from 1987, if they were even published at that time, but later updated editions from 89/90/92.

Just tested a built with this patch and ran Windows 3.11. The S3 Trio driver does not accept the S3 Trio card as such.
"The S3-based display driver you selected has detected a non-S3 graphics chipinstalled. To work properly, please install the appropriate S3-based graphics card."

That's great! Now, I wonder if Win95 will work with that driver -- Win95 actually accepted Win3 video drivers. The feature was removed later but it was quite useful in the beginning. I used Win3 ET4K driver on Win95 myself.
I am planning to do one more update (hopefully, this week, if I have time) and implement "overflow bits." Almost all SVGA chipsets (and even VGA core chipset) had those but the current implementation is somewhat hardwired. I will see if I can clean it up and extend without breaking anything. Now, if I only can find anything that used any of these...

uhm, you might have only read the 1st sentence. I tried to run Win 3.11 but it wouldn't because the S3 Trio driver didn't recognize the emulated card as a S3 Trio.

No, I just misunderstood what you were trying to say. So, it's not that the new driver is working but that the old one does not. I never tried to run Win3.11 on DosBox so I don't know if it ever worked or not. So, are you saying that I broke it or that I haven't fixed it? I tried not to touch S3 implementation as much as possible but I would be surprised if I broke something after all.

ok, I thought you added the S3 Trio 64 "graphics card" to the emulated computer. The card emulated without your driver is not a S3 Trio but a "S3 864".
So when I tried that built with your patch I tried to use the drivers for the trio and that gave the error message.
I have to try your patch as standalone now, it seems, to see if the normal Dosbox S3 emulation got broken by it (I think some other patch prevented me from boot with the "old" S3 drivers).
Hope I could clarify stuff, since I'm not so sure the above stuff makes sense 😀

I see. A few S3 chipsets carried Trio name, I am not sure if 864 was one of them or not. I will check reliable sources and clean up naming if needed. Thanks for pointing at this. Video chipset selection is confusing as it is, no need to make it more confusing by assigning incorrect names.

I double-checked and it looks like DOSBox emulates Trio 64 (aka S3 764). Changelog refers to that, source code comments refer to that, the implementaiton looks that way (some Trio-specific acceleration is there). WhatVGA reports the card as Trio 64.
My guess is that there is some feature still missing in that implementation that prevents Win3 driver from working properly. What software did you use that identified the card as "864"? This may be important -- this way we may be able to identify that missing feature and make Trio implementation way more compatible.
I probably should try ET4K driver with my build, it may have some chances. If not that one, I have PVGA1A at reasonably working level (could not implement separate banking on that one but did not find anything that uses that either).

wouldn't that be in that one port for which a patch was on sf.net ?

You've lost me. What part are you referring to as "that"? If it is about improved S3 compatibility, I don't see open patches for that. There is CRTC patch but that one is generic for all VGA chipsets. If it is about ET4K -- my patch is there, I am still working on it but most of the work I've done after the last submission is code cleanup, very minimal functional changes. If it is about PVGA1A, it's not on sf.net yet but it will be in a few days.

I only thought it was a S3 864 since the Windows drivers, that were recommended for it in one of the early "windows in dosbox" threads, were the 864 drivers.
The trio drivers I used were those I kept on an old CD, from the time I actually had a real Trio 32 on my computer 😀
(if those are of interest to anybody, I can attach them)

was it this "thread"? 😉

http://dosbox.sourceforge.net/site_images/win/win311.png