ah, nice, thanks

You can also find them here. (freeware)
http://ykhwong.x-y.net/bbs/zboard.php?id=usef … no=9&category=1

The Tseng Vesa driver from ykhwong's site doesn't work with Crusader, the Univbe from SciTech's Display Doctor 6.53 works (the older stand alone Univbe from Scitech's site doesn't work as well).

Another update to my patch. This time I've fixed hi-res 16-color video modes (not Tseng-specific fix). Win3 works in 1024x768x16 without glitches, so does DPaint. Should I enable 1280x1024x16 in Tseng driver? There were a few cards that supported that mode.

Yet another CVS refresh, this time dosbox.cpp got changed. Having UMB is nice, though. Brings back memories about that eternal search for perfect config.sys 🤣
There is compilation issue in current CVS (file src/debug/debug.cpp) which I've already reported as a bug. It affects only builds that have debugger enabled.

Having UMB is nice, though. Brings back memories about that eternal search for perfect config.sys

This search could be quite short if you owned a 286. Apart from those NEAT boards which could do next to everything using UMBs was restricted to the 386+. Well, sorry for posting a bit off-topic.

A little note, just before anybody else notices this. Current version of the patch causes DOSBox to crash in WHATVGA testing 16-color modes if any SVGA chips is enabled (works if svgachipset=none). This is not a bug in the patch but just a result of very peculiar way WHATVGA is doing things colliding with some limitation in EGA memory model in DOSBox. I am working on the fix. I could not find anything else affected by this issue, the way WHATVGA is doing things is quite unorthdox in this case.

EDIT - I've identified the problem. It is very basic but will require some time to be fixed properly. For those curious about details, DOSBox allocates 2M for VRAM statically but for paged modes it is not that simple. Every pixel is rendered twice: once in "latched" area, and once in linear memory starting at 512M. The copy in latched memory belongs to emulator, the other copy is to speed up output (otherwise each pixel would have to be reconstructed every frame). At this point there are problems already. a) if emulated card has >512K of VRAM those copies will overlap causing corruption; b) Each byte in latched memory produces four bytes in linear memory. For 1M latch memory it is 5M total, that's buffer overflow and crash. Normally, none of these would happen as the largest emulated mode is 1024x768x16 is less than 512K. Enter WHATVGA. The first thing it does it attempts to write over all available memory even if current video mode requires but a fraction of it. There are reasons to do so but the tecnique was not commonly used in games if ever. Simple workaround would be to increase allocation and offset to the second copy but it is wasteful and ugly. I will play with reimplementing allocation as dynamic (if you waste, waste only as much as you have to) and making offset dynamic.
This issue is not a high priority at the moment as it only affects WHATVGA and no games I know of. It would become real issue if I tried to implement 1280x1024x16 mode -- that would immediately exhibit corruption.

EDIT 2 - At this point I have it practically working but it will take some time before I submit an update. Two reasons: the amount of RAM for correct emulation is just too high and this precision is rarely needed so I will have to implement some way of selecting "simplified" mode; there is something funny going about S3 -- WHATVGA cannot decide if it has 2M or 4M and attempts to set write bank to >31.
On the other hand, Tseng driver renders all tests in WHATVGA without any glitches for the first time (run WHATVGA in 0.63 or CVS and scroll in any second mode test and you will see what I mean).

Has anyone managed to get Pinball Illusions working in either of the SVGA modes? I can't get it to actually initiate the correct resolution full screen, and when I play it in a window (which does look pretty good), the flipper animations aren't right... I suppose "tear" is the right word for it.

Any pointers appreciated.

That game seems to hack SVGA registers to literally create its own video mode. Unfortunately, the resolution of that hacked mode does not correspond to any real fullscreen resolution so the switch fails. It's fixable but not implemented yet (should really pick the next larger resolution and use part of the screen). Item for wish list? As for tearing animations, that's just DOSBox video not being fast enough. On my system it's not that bad but definitely noticable.
A little status update on that 16-color modes. I have everything implemented and it seems to be working correctly. 16-color modes bank switching can be turned on and off through dosbox.conf -- in most cases it should really stay off as it takes huge amount of RAM. Strange behavior of WHATVGA in S3 modes is probably fault of WHATVGA itself, it seems to like 1M video RAM the best. I will do more testing and update my patch some time over the weekend.

Hi guys,

May I suggest a couple of testcases for your SVGA patch?!

Can you please try 'Trucks' (by Microfolies) and/or 'Loderunner: The Legend Returns' (by Sierra On-Line) if possible? Both are SVGA games, that I cannot get working in dosbox, with or without using Vasyl's great patch...

The attachments show a few screenshots of the games. Trucks uses some 16bit (vesa) mode that 0.63 does not support, but the game can be started using ykhwong's latest CVS version (with Vasyl's patch). Unfortunately, the screen looks completely garbled. Different SVGA chipsets have slightly different results, but I wasn't able to make it any better than this.
Lode Runner is somewhat different as it works exactly the same in 0.63, as in a release with the SVGA patch; only half of the screen is visible.

Kindest regards,

Ronald

New version of the patch is up. 16-color hi-res modes now work properly. That actually required quite a bit of work to get right but now WHATVGA works as it should and Win3.11 runs in 1280x1024x16. I finally got to one of my todos -- implementing extended overflow in CRTC -- and found that those overflows were pretty much left unimplemented in S3 as well. 1280x1024 mode required proper implementation of these.
Some notes regarding WHATVGA. All supported modes work great in Tseng 4000 driver, both primary and secondary tests. Everything will work with svgachipset set to "none." However, in all other chipsets (ET3000, PVGA1A, and S3) secondary tests appear broken. This is not a bug in DOSBox or WHATVGA, it is a result of interesting limitation common to all of these chipsets. The secondary test depends on "Display Start." On emulated S3 this register has 19 bits (as on the real hardware), but the amount of video memory is 2M. As a result, the display window cannot be moved beyond half of vram. I have no idea why WHATVGA does not take this into account. Very similar thing happens on other cards, just with fewer bits. ET4000 is the only chipset that had enough bits in that register to address all of its memory.
There is one glitch in WHATVGA left: on ET4000 DOSBox may crash after testing mode 1280x960x16 (but not any other mode). It looks like some bug in the renderer that causes it to access past allocated memory buffer. This is low priority, it does not affect anything besides WHATVGA.

Regarding those mentioned test cases. I don't have Trucks but from the description it looks like it uses 16-bit color which is not well supported yet (and only S3 is capable of it). I will try to check Loderunner, the issue looks like something I might've fixed with this current version.

vasyl, I was wondering if you might have some kind of feature matrix/speadsheet that you keep for your own reference to know what is supported by the various SVGA chipsets that you're developing emulation for. I ask because your last post mentioned that certain things are only possible with ET4000 or S3, and I thought it might help people figure out which chipset might be best to use with a given game.

Also, what level of VESA emulation does DOSBox (official or your own versions) support? For VESA games, is it comparable to the hardware specific emulation you're working on?

Thanks for all the hard work 😀 I'm looking forward to seeing it become part of the official CVS source.

Yes, I was thinking about that. Right now we have chipsets from three distinct generations: PVGA1A and ET3K is the first wave, ET4K is mature SVGA, and S3 is video accelerator. Not many people remember the differences. It would be nice to have human-readable documentation.
S3 supports VESA 2.0 natively. All other emulators don't have any VESA support in DOSBox but work with VESA TSRs (UNIVBE, TLIVESA, etc.) There is not much advantage or disadvantage of using VESA if you have that choice. It is used to query system capabilities like available video modes, bank size, available memory, but not much beyond that. You are not going to have more speed from it.
Speaking of VESA. There is something very strange about Tseng VESA TSR called TLIVESA1.COM (but not TLIVESA.COM). It installs and then tries to switch to video mode 0x3D (1280x1024x16) making it quite inconvenient to use with my latest version of the patch. I would hate to disable this mode just because somebody at Tseng had odd sense of humor. I will see if I can detect that particular utility running and disable it just in that case.

Speaking about Lode Runner: The Legend Returns, there is a bug in int10_modes.cpp (repeated in vga_tseng and vga_paradise in my patch). It looks like mode 640x480x256 is supposed to have 8x8 characters, not 8x16. To get the game to draw properly on emulated S3 look for mode 0x101 definition in int10_modes.cpp and change 80,30,8,16 to 80,60,8,8. Similar patch in vga_tseng will fix et3k and et4k. I cannot say anything about pvga1a, the VESA driver I've got is not working well -- probably due to emulation lacking some features.
With the change the game will draw properly but it seems to have some problems with keyboard.

As you know I don't deal with most of the vga hardware part unless it's bug fixes.
Maybe it would be an idea to "extract" most of the bugfixes into a seperate diff.
I admit I haven't looked at your patch lately, because I didn't have much time. (let alone a pc with internet acces)

Yes, I have noticed. That's why I've submitted those minipatches for Wari and Overkill before. I will submit this one as well but only after some research -- I believe there are other modes that have incorrect font size in mode table right now. I've tried to split my patch into smaller parts but it did not work well, too many dependencies, and most parts were not fixing anything by themselves: for example, dual-ported memory can only be used by "other" SVGA chipsets (that is actually very simple change and I may try to separate it).
So, who is going to handle VGA changes and when? I understand that not everybody would want to touch that mess of PC video hardware. Looking at the work I've done lately, I can really see why. But it is an important part and it needs to be covered.

Well, Harekiet used to work on VGA. I have even heard he was working on 16 bit VESA support etc. But he does not seem to be around...
@QBIX: Would not it be possible to establish another developer who would take are about these things? Like "vasyl" who clearly understands it and has shown his abilities...

Mirek

Would not it be possible to establish another developer who would take are about these things? Like "vasyl" who clearly understands it and has shown his abilities

That would make sense.

I'm not really a DOSBox dev (official or otherwise), but I agree with mirek and Dominus. I guess it would partly depend on how open Qbix would be to integrating vasyl's SVGA support into the official DOSBox CVS source in the near future, due to the problems vasyl described with integrating into plain CVS his fixes to the normal VGA emulation.

Meanwhile, the patch that fixes Lode Runner The Legend Returns is up at Sourceforge. I was not completely right with the workaround I've suggested before. It is not easy to find info on font sizes in different modes. After some research I've found that there is no consistency across chipsets so there must be something else. That something else appeared to be broken function 1130h in int 10h. Simple change, LR:TLR is playable. Requires VESA mode, S3 is fine "as is," others will need VESA TSR.