All right, new version is up, give it a spin. All features of the previous version are there, there should not be any changes visible from outside. The internals are completely redone. Harekiet started separating S3 code, I continued in that direction and got much cleaner implementation of driver code than before. The patch is finally layered properly -- CVS has those changes to paged memory access that I needed so the patch does not go to paging.cpp and cpu anymore. Almost everything is done in hardware/vga and ints/int10. There is one file change in gui (render_scalers.h) -- that was needed to enable 1280x1024 mode of newer ET4K cards and also to fix 1024x768 modes that were otherwise broken.
So, hit it hard and tell me if and where it breaks.

Why did you disable "zmbv"? Is it incompatible with svga?

Did I? Where? I did not do anything like that on purpose so it must be a bug. Remember, this is practically a complete rewrite of the patch so no wonder if I missed something.

Does not work anymore with newest cvs...

1patching file dosbox-cvs/src/ints/int10_modes.cpp
2Hunk #9 FAILED at 615.
31 out of 12 hunks FAILED -- saving rejects to file dosbox-cvs/src/ints/int10_mod
4es.cpp.rej
5patching file dosbox-cvs/src/ints/int10_vesa.cpp
6Hunk #1 succeeded at 124 (offset 3 lines).
7Hunk #2 succeeded at 410 (offset 20 lines).
8Hunk #3 FAILED at 426.
91 out of 3 hunks FAILED -- saving rejects to file dosbox-cvs/src/ints/int10_vesa
10.cpp.rej
11

Well, but on the contrary, I also cannot compile the latest CVS anyway... gives me out some stranger errors... kinda don't get it...

I've seen it mentioned somewhere that there are a couple files missing. Those patch failures are due to very recent changes in CVS (after I synced for patch) -- int10_modes is a fix for a minor error which I also fixed in my code but moved that chunk of code to vga_s3.cpp. The other one in int10_vesa.cpp is even simpler -- my patch attempt to remove non-functional piece of code which got update to different version of non-functional code. I don't know why that thing is there at all, probably some leftover from Harekiet's test code or something.

In your patch, around line 3214 the whole zmbv stuff is getting killed for some reason. After adding this back manually I was able to compile dosbox again and my normal testcase (win311 with tseng drivers) ran fine.
So there is something bad with zmbv

Whoops, so much for my new branching process (those familiar with Check Consistency feature in Perforce will recognize the rake I've stepped on). No wonder that patch file was somewhat bigger than expected. I had C_SSHOT disabled so I did not notice bad things going on.
Anyway, the updated version of the patch is up. Works fine with the most recent CVS, does not kill zmbv (although current vcproj is subpar, it needs to be adjusted to build zmbv.lib automatically).

EDIT: I've compiled a detailed list of changes that my patch does to CVS, in case if anybody needs to figure out what is there. See the attached file.

EDIT: Made a couple of small updates to the patch today. Make sure you are using version 20060204b.

hi, either your patch (dosbox-svga-patch-20060212.diff) killed compile for me or it is again not up to date with CVS. Some problems with dosbox.rc and dosbox.ico. Looking at the diff I see no reason that it messes with these files.

Did I miss some files again??? 😳 I thought I checked that. Well, I will fix it later tonight.

you remove dosbox.rc and compile fails then

Should be fixed now. I must've started my scripts in wrong order -- just rebuilding diff corrected the issue. That .rc file is not in VC.NET solution which is wrong, otherwise I would notice it before submitting the patch the first time.

well the ico is intended for release builds. As those are made with mingw it's only present there..

ratrace with cvs 😀
seems your patch is again out of date. Recent changes to vga_s3.cpp fails patching with your diff and then compilation.

Oh dear! The refreshed version is up. Not sure why the patching failed for you, patch utility is supposed to work with changes that minor (added comment line) but different ports of that utility may behave differently.

patch doesn't know what a comment is. It regards any change equally, there are no "minor" changes. Using some command line options, you can have it ignore whitespace, however. And using the command line, you can allow a certain amount of non-matching lines. These have to be passed on the command line, however.

super vga patch breaks Bio Menace.
When you climb a ladder, flickering screen may appear.

Indeed. I will take a look.

EDIT: 🤣 It does not break it, it actually fixes it! Believe it or not, but Bio Menace does exactly the same on real SVGA -- verified on Tseng ET4000 with 1MB. Apparently, it is one of those VGA games that broke on SVGA. The patch improves compatibility with real SVGA and triggers this behavior. Not to worry, it taketh it away but it also giveth. The game runs just fine in "pure VGA" mode with svgachipset=none.
I think I know which particular change in the patch triggers this issue but I am pretty sure that there are cases when that change also fixes stuff. I will look if I can find any. As the behavior is consistent with real hardware I would say that the patch is correct. This issue also completely justifies that "none" setting for SVGA chipset which I was not even sure about.

I see. I tried the game with s3.
Thanks for a test using real hardware.

Check this: http://www.3drealms.com/tech/biomenace.html#video. Apparently, the game was always known to have some issues with SVGA, and it has SVGA compatibility mode just for that purpose. It's probably slightly slower but the game is not particularly demanding, so it does not matter.

do you know how lowerbank works? only vga.h has it.
current svga patch is not compatible with cvs now.