lowerbank just pads the vga bank to be directly used without multiplications.
Use the old code if you don't need it.

I will update the patch tonight. The "lowerbank" implementation is definitely not compatible with my patch -- not all cards used 64K banks, PVGA1A had 4K. ET3000 had 128K banks but I don't think there is any software that ever used it. Saving multiplication there is not so much of optimization as it replaces multiplication with 16-bit memory access. On some platforms it may actually be better to multiply, especially as it can be done as register shift.

EDIT: The patch has been updated. Wow, almost five months without changes! And even this change was only because part of the patch functionality went into CVS. The thing seems to be quite stable and requires very little maintenance. I really should find some time and add something new to it. Maybe find a couple other fixes that can be added to CVS easily...
As I said, "lowerbank" implementation would not work nicely with this patch but the main feature of it -- removing multiply from per-pixel access -- is easy to add. A little nice optimization.
WHATVGA shows excellent compatibility for both ET4K and S3 chipsets. I did not try all modes yet but the only issue I've found was with the mode 0x118 on S3 -- cannot really have 1024x768x32bpp on 2M video RAM 😉 It crashes on CVS, works with severe artefacts with the patch, just as expected.

Just submitted yet another updated. I had a little time to spare last week so I finally got to a few rather minor issues. Here's what's new:
- S3 chipset now supports video memory size properly. Supported sizes are 512K, 1M, 2M, 3M, and 4M, just like the real chipset. Yes, 1024x768x32 works properly!
- Added some smarts to "videoram" setting in dosbox.conf file -- values <10 are interpreted as megabytes.
- Chained memory now works properly with banks. This fixes a lot of issues with PVGA1A and ET3K in WHATVGA.
- Forced non-standard chain4 in LIN8 modes for PVGA1A and ET3K. It's not exactly consistent with the real hardware but good enough for all practical purposes.
- Changed default value of SEQ index 7 for ET3K -- this was breaking WHATVGA very badly.
- Removed memory size support from ET3K, it was not working anyway.
- Fixed stupid bug that broke scrolling on PVGA1A with >256K of VRAM.
- Actually enabled 1M of VRAM for PVGA1A
Notes:
- ET3K: I've tried to verify my assumptions on real hardware. The way it looks, either my copy of ET3K is defective or the ET3K is just badly broken design. I've fixed whatever I could but I am not going to hack all the way through just to get WHATVGA completely satisfied. Besides, it does not run correctly on the real card either. Chain4 is seemingly standard but does not like analigned accesses to video memory, display timings are really quirky, memory size uses some side effect in memory controller behavior.
- PVGA1A: Both VGADOC and Ferraro mention that there are versions with 1M of videoram. This is not possible with just 7 bits of bank index. Either there are mislabelled C00 chips around or 1A allowed use of all 8 bits of bank index depending on implementation. I cannot check it and enabling 8 bits cannot break anything, so I did just that.

I have the ET3000ax and could do some tests on it.

Great, thanks! My ET3000AX seems to work ok in games but behaves very oddly in synthetic tests. In addition, it takes unusually long time during the system boot (~20 seconds) -- at first I thought that it is not working. I'll send you some tests tonight, let's see if your card produces more consistent results.

Could you give somewhere (at the patch on SF?) some more information as to which card supports how many MB of video Memory and what the default is if it is not specified in the conf file?

Yes, 1024x768x32 works properly!

wow, really? Cool. Also in Windows 3.x (and if yes which drivers work for the S3)?

It's been in my plans to write small documentation describing emulated features and limitations. I promise, I will do it one day 😊 For now, I might as well type in this small table

1Chipset                Supported ramsizes              Default
2S3 Trio64 764          512K, 1M, 2M, 3M, 4M             2M
3Tseng ET4k             256K, 512K, 1M                   1M
4Tseng ET3k             512K                             512K
5Paradise PVGA1A        256K, 512K, 1M                   512K
6VGA                    256K                             256K

Haven't tried Win3 in that resolution yet, let's see if I can find good driver.

EDIT: Tried Win3 -- not there yet. It switches to correct mode, draws background correctly, and then locks (?) while rendering the first window. I am not sure if I am using the best driver so YMMV. Overall, it feels like there is some tiny glitch in emulation, and it is definitely in video -- after all, ET4000 works just fine.

thanks for the table.

Does the Tseng support more colors now in Windows? (I'm on holidays so I can't verify)

Most stock Tseng cards were limited to 256 colors. There were "hi-color" capable cards (those with Sierra or similar DAC) but they were quite uncommon. Also, the way the DAC worked, those were inherently slow. It may be possible to emulate Sierra DAC but I don't see much value in it. I would rather figure out what's missing in S3. Right now it appears almost working (I am getting identical results with "recommended" 864 1.41b5 driver and last "official" 764 driver from S3 site 1.70.04) -- in all non-palettized modes there are these issues: a) cursor drawing is broken (not accounting for pixel format, drawing as in 8bpp mode); b) line, fill, and font drawing commands are ignored somehow (bitblt appears to be at least semi-working); c) screen coordinates for all commands are off (not sure, it just looks like y offset is smaller than it should be). Yes, that's a lot of issues, but comparing to what is already working it's not bad at all. It is also worth noting that the emulation behaves consistently across modes and drivers, always a good sign.

EDIT: Quick code check confirms at least issue (a) -- function VGA_Draw_VGA_Line_HWMouse is not only assuming 8bpp but it is hardcoded to 640x480. It's tedious but not hard to fix.
EDIT2: Fixing issue (b) will require writing some non-trivial amount of code in vga_xga.cpp. Issue (c) seems to be originated from the same function as issue (a). If I get some time I may attempt to attack those, unless Harekiet gets there first 😉

vasyl wrote:

If I get some time I may attempt to attack those, unless Harekiet gets there first 😉

He usually messes around with the CVS once every two years. You've got plenty of time 'til 2008!

Quick! Quick! I can hear him swimming back from the Bahamas!

Did not have much time lately, just got a few minutes. I have the hardware cursor issue completely fixed, see the separate patch on SF. Fixes the mouse coordinate issue as well, just as I expected.
The remaining issues related to accelerated drawing are not that simple. I've tried updating vga_xga.cpp -- it's not difficult, most of the code there is ready for this kind of update. The problem is that Windows refuses to call that code. There are couple of calls during the first frame draw and then nothing. I've added all(?) missing ports, still nothing. Looks like some piece of this puzzle is still missing. I am still looking into it so stay tuned.

CVS breaks the patch again 🙁

Broken by my own patches 😉 In any case, that was expected. The updated patch is up.

Thanks for the update!

and last "official" 764 driver from S3 site 1.70.04

How do you get this driver to install? All I get is a no start of Windows with the message "The selected display driver does not support the installed graphics chip"
And is it the "Trio64V+ (765) Drivers" or the "Trio64V2/DX -/GX (775, 785) Drivers" from the S3 site http://www.s3graphics.com/en/resources/driver … are_archive.jsp ?

Trio64V+, although OEMSETUP.INF refers to it as just Trio64V. I did not have problems with drivers refusing to run on emulated S3. On the contrary, I had some driver starting in the situation when it better should not have. I need to check -- I've done that in patched DOSBox, maybe it is more compatible with drivers than the main version. Dealing with multiple S3 drivers in Win3 is annoying -- each brings dozens of video mode lines, the SETUP.EXE eventually crashes if you have too many of these. If that happens, the only way to get it working again is to manually cleanup some OEM?.INF files from WINDOWS directory.
BTW, I have 16-bit color modes in Win3 practically working. There are a few minor glitches I still need to fix, and 32-bit modes -- that should not be too difficult.

If that happens, the only way to get it working again is to manually cleanup some OEM?.INF files from WINDOWS directory.

Now you tell me, after I've had to fix that myself yesterday 😀
Strange, I couldn't get that driver to run in neither plain dosbox nor in your patched one, but I'll try again tonight with a new set up Windows. Who knows what my years old Windows has problems with 😀

The complete patch for hicolor/trucolor support in Win3 is up on SF. Now that it's done, it's almost too simple 😉 Enjoy!
The accelerator is quite simple, I wonder if there were any DOS games using it.

Cool 😀
Looks nice, highly appreciated.

Looks very nice and it seems my one reason to run Windows 3.11, the game Inner Space works a bit better too (it slowed down on the combination of explosions sound and graphics).
The only thing I noticed is that the Norton benchmark looks funny.
I'll attach a picture of it running in 256 colors and 32k.

Dunno about Inner Space -- my changes should not affect 256-color mode in any significant way, could be one of register reads I've added. There was one minor optimization in DrawWait; using 32-bit values sometimes may be slightly faster than using 8-bit value on modern CPUs.
I will check Norton Benchmarks, that's a good one. The issue should affect other programs as well, so it definitely needs to be fixed.