After about an hour of messing with source I have found something particularly interesting about the game I used as an example -- Eric the Unready. Apparently, the way it attempts to identify hardware is not completely correct, so it misidentifies DOSBox as some Trident variation. As a result, it tries mode 0x5d for "XGA" and 0x5b for "SVGA" (I completely forgot about that option). Guess what, by adding
{ 0x05b ,M_EGA16 ,800 ,600 ,100,37 ,8 ,16 ,1 ,0xA0000 ,0xA000, 128 ,663 ,100,600 ,0 },
to ModeList_VGA in int10_modes I got "SVGA" completely functional. "XGA" is not as easy because it requires changes to bank control. Similar patch for 5d will just result in black screen. I will dig a little more. The entire SVGA detection routine in that game just does not seem right.

Interesting!

I wondered why SVGA wouldn't work for those three games (you certainly refer to Eric, Spellcasting 301 and Gateway 2) while it does with Death Gate, Shannara, Mission Control and Crosstime Saloon.

They probably fixed SVGA detection in later games. Eric, S301 (I mistakenly wrote 201 in the original post), and Gateway 2 were released about the same time, so no surprise if all three are broken in the same manner. I can run Eric in 800x600x16 with no problems now with that hack, but 640x480x256 is not that easy. I cannot tell exactly which Trident chipset did game "find" in DOSBox, and Trident went through a few generations of "interesting" hardware (according to VGA registers on 8800CS mode 13h was not 320x200x256 but 640x200x16 with some non-standard memory scheme -- things like that). So, I don't know how to fake bank switching yet. I will post my finding if I get anything.

Well, did not get far. I am still not sure how those games are detecting SVGA hardware -- they must be using non-standard (and incorrect) way to do it. I've managed to spoof different revisions of Trident chipset by returning appropriate values in read_p3c5 (index 0xb) but still did not get far. The games are trying to switch hardware into separate read/write banks, not sure if the feature is actually used. I've trapped bank switching but even hacking that to s3 bank switch did not get anywhere -- the game exists after the intro while being switched to hacked video mode.
Noticed another little issue, this time it is a generic bug in CVS tree. In file misc/mouse.cpp this line:
Bit16s xratio = 640 / CurMode->swidth;
is incorrect as it results in xratio=0 in all modes wider than 640 causing crash a few lines later. This is rarely travelled code path but it gets executed when Eric the Unready shows any dialog box. Both alternative calculations suggested on that line are better although I have this feeling that this code is going to change in the future anyway.

Me again, posting the final findings. I've got Eric running in 800x600x16 without code hacks -- there were three legitimate bugs in current CVS that prevented that before (1173098, 1173099, 1173197), although the last one is closer to feature request than to a bug report. The other mode (640x480x256) is a problem. With the first bug on the list fixed the game enters the mode but a) does not draw copyright notice in the intro; b) exits immediately after the intro (leaving the system in non-text mode). Now, I don't think this is a problem with DOSBox -- VirtualPC shows exactly the same behavior! VPC emulates essentially the same video hardware which suggests that there is a problem with the game itself. It is not a problem with VESA implementation in DOSBox -- one of my hacks mapped Trident extended mode to S3 extended mode and it was doing exactly the same.
All of this raises the original question in my first post -- was S3 really the best choice considering DOSBox goals?

Just to answer your question: IMHO yes. S3 is a good foundation for future development (win 3.1 runs in 256 colours), seems to be easy enough to emulate, and is widely known from the mid-90s on.

About that text problem: Try looking at src/ints/int10_put_pixel.cpp, INT10_PutPixel. It doesn't yet have support for some SVGA modes, so any drawing via BIOS (that could be text) is silently ignored. You can take a fix for that from my latest hq2x patch on sourceforge, search for that file. Of course, it may be a totally different problem... 😉

Thanks for the tip but it did not work in this case. There is something else fundamentally wrong with those three games in the way they handle VESA. If I get more time I may be able to trace it. As I pointed before, the issue is reproducible under VirtualPC.
As for Win3.1 in 256 colors, I had that with ET4000. More, with Sierra DAC I could get 16-bit color on that chipset. Easy enough to emulate? Well, now that it's working, yes, it's easy. Just looking at VGADOC, I would've picked something else in the first place... S3 is definitely not the simplest one. My point is that it would be good to have that part modularized in some way. After that little hacking I've done in the last few days, it does not seem to be that difficult. The only issue I encountered is that S3 is single read/write bank architecture, most other chipsets support separate banks. Other than that, it's easy: while trying to figure out that bug in Eric the Unready (and actually following red herring there) I was able to hack pretty belieavable Trident chipset that WhatVGA accepted, in some 30 lines if not less.

well the s3 is fine enough i would say
There were more things involved then only the VESA capabilities.

Replying to Qbix's messages from two threads at the same time. You may think that I care only about "three buggy games." No, that's not it. I use those as an example, and not the very best example even IMO. Any pre-1992 game that claimed SVGA compatibility would support Trident, Tseng, or Paradise (WD) but not S3. There were not that many games of that class, I admit. ISA bandwidth was just not sufficient for any game-like video updates. In Legend's case it did not matter so they used it. "Productivity" software is completely different matter. Deluxe Paint IIe, ChiWriter, very old versions of Word or AutoCAD -- those fall in that category. Yet another topic is demos. A lot of demos are written specifically for ET4000 -- I think that was mentioned in some thread on one of the forums already.
Please don't think I am critisizing anything -- I am most definitely not, I am just trying to help. Every time I ask about something I perceive as an issue, I am also trying to provide solution.

I referenced it in the S3 trio documentation thread. I'm curious to hear what canadacow has to say since he coded the s3 emulation. Even if everyone doesn't want it I may play with et4k emulation for myself. The et4k was released in 1989, same year S3 was founded. Tseng Labs was founded in 83. ATI bought them in 97. A fan page! "Tseng Labs Unofficial HomePage" http://tseng.ckp.pl/ 😀

Searching for tseng info I ran across an old anecdot of using s3 vs tseng in win3.1(search for tseng): http://home.earthlink.net/~regina-r/maintain.htm

ih8registrations wrote:

Searching for tseng info I ran across an old anecdot of using s3 vs tseng in win3.1(search for tseng): http://home.earthlink.net/~regina-r/maintain.htm

🤣. The S3 video cards were one of the most highly supported video cards under Windows 3.1. The issue mentioned seemed more life a software/driver incompatibility than anything hardware related and it didn't even look like they spent that much time troubleshooting the issue.

"oh no! My videos and animations are locking up!"
"Replace S3 PCI with Tseng ISA"
"Hey it works! COOL! Let's leave it alone!"

Your first and second sentence are incompatible:) Supported, highly even, ='s sans(lack of) driver incompatibilities; that is, functioning. But not to be side tracked, software vs hardware isn't being debated, just support, via hardware & software; and without lifting a finger, the old tseng just worked.

I'll pose this question to you: To get dawn patrol to work in dosbox, would you rather:

A: find a boot image, pass arguments to dosbox to run with that, add a config.sys option for emm386 in dosbox.conf that's needed to run the generic vesa driver, run the driver after booting dosbox(can also tell it to run in the conf file), select generic vesa driver from the config menu, run the game.

OR

B: select et4000 from the config menu, run the game.

I really don't find A all that bad once set up, but B is easier.

As for the tangent of their troubleshooting, they didn't describe what they did, in order to conclude anything, but they did express their preference for the newer faster card if it would only have worked for them, so I have to disagree with your description of how that went:)

added a comma.

Here's an idea,
Why don't you let the Dosbox authors worry about Dosbox, and what direction they are going in ?
Dosbox, works fine as it is. It's a brilliant, FREE, piece of software that just works.
It doesn't need some hotshot coming in here and suddenly thinking he can turn water into wine, or whatever.

I absolutely love dosbox, and it works for almost ALL of my 2000+ dos games I own.
Qbix, and the mods do a wonderful job here, when they put up with some of the most stupid, mundane questions ever. As well as those who just whinge, moan and whine at Dosbox.
But then there are those who Think they know what and where Dosbox should be doing and going, should quite honestly either shut up, or go and write their own Dos emulator.

Quite frankly, even though I just sit in the background now, I'm quite appalled what goes on these forums, lately. Qbix and the mods actually bend over backwards to help some people, yet get little praise, lately.

Sorry for the moan, but it had to be said. 😠

Agreed but on the other hand there's no hurt in suggesting things. That's one of the many reasons these forums stand for. The best thing I think it's the freedom of expressing each other's opinions while keeping it civil.

PS - We all know there are several types of criticisms. Some of them are more constructive than others. We should hear out all of them, though.

You know CraigG, it helps to mosey on over to the sourceforge site to look at the code updates and patch section to see who the contributers are along with the registered developers; not to mention reading the thread that you are replying to understand that one, it isn't criticism, and two, no one is demanding the code be written for them. You wouldn't want to look foolish.

I'm all for Suggestions, but not for demands.

Ok, perhaps this topic was just a suggestion, it's just the tone suggested otherwise.
Some of the posts in the Dosbox wishlists, are pretty much spot on, apart from a few, but most of them really add something to Dosbox. I think this is great, and ideas are great. But not questions as to Why Dosbox does this, but not this, regardless of who they are.

But the ET4000, wasn't as great as some of you suggest. I had one made by Cheetah ? I'm pretty sure it was a company with a Big Cat name. But it was nothing special. Ok, a handful of games have a ET4000 Vesa driver, but is all this really worth it for a few games ?

You wouldn't want to look foolish

I'm not the one running around this forum posting the so-called Short-Commings of Dosbox.

Here's an idea. Why not keep all this to yourself, until you can put up something that Proves what you are getting at ?
Until then, I'll reserve judgement.

Well, we have something in common, because I'm not running around proclaiming the so-called Short-Commings of Dosbox either! Wow! That this hardware is faster than that hardware is meaningless in the context of dosbox because everything is emulated in software. All that matters are programs that were written to make use of xyz hardware. Like the non-VESA SVGA access to hardware which we've been discussing(I did suggest you read the thread). I've got an idea too! Try to understand that you are in a development forum, in which developers will discuss developing and things having to do with such. In this particular development forum, emulating hardware and topics therein(like discussing the merits of emulating a particular piece of hardware).

I've got an idea too! Try to understand that you are in a developers forum, in which developers will discuss developing and things having to do with such. In this particular developers forum, emulating hardware and topics therein(like discussing the merits of emulating a particular piece of hardware)

I only ever read the developers forum, simply because I enjoy reading what the developers are saying. It makes for a much more enjoyable experience, than reading the constant whining from people about why Dosbox is slow on their 10-year old piece of junk.

Like I've said, I am under the impression that the TONE is wrong in this topic, NOT the idea. Although, again like I said, I still think Dosbox is fine as it is.

IF, someone can come up with something that improves Dosbox, in any way big or small, then I'm all for that. I just don't think this is the right way.

Oh, and just because this is a developers forum, doesn't mean non-developers can't post here.