I know this is going to sound one-eyed but VDMsound is stupid and really poorly implemented by modern standards, mainly because NTVDM specifically sucks so much as to make the use of either or both to run DOS games in a WinNT environment a really dangerous and silly exercise. This is further compounded by the use of NOLFB and other such utils that directly access hardware. Anything that mucks about at ring 0 is just an accident waiting to happen.

I agree with the need for a proper 16/32bit WinG/early DirectX Windows solution for x64/x86 users though. An emulation layer of sorts would fulfill a niche need and would allow the use of many later Sierra Windows and a whole host of 'multimedia' titles from other companies new leases of life in XP and Vista but I think that having such a layer parse hardware calls and redirect them to real hardware is pointless. Even the most generic of AC97 chipsets does more than a real SB16 can and a real GUS is far more limited and prone to error than most of the emulated versions.

As far as the MT32 goes, after mucking around with MEGAEM back in the day and Munt more recently, I decided to get the real thing. I can't see much point to an LAPC or real MPU401 though.

As far as the MT32 goes, after mucking around with MEGAEM back in the day and Munt more recently, I decided to get the real thing. I can't see much point to an LAPC or real MPU401 though.

Once you go native MT-32, you generally don't go back. However, those few who only have an LAPC-I would not want to be left out of the mix, especially as CM-32Ls are equally rare. Supporting a real MPU-401 would not hurt and it is a very reliable midi interface. Why emulate it if you have the real thing? Of course, emulating the necessary functionality of intelligent mode is not processor intensive.

Replacing the DOSBox VGA emulation with a real S3 Trio64V+ is a bit slower than the emulated one... I had hoped it would get faster 🙁

That's seems logical though, current integrated VGA chipsets coupled with at least DDR RAM and modern bussing run rings around a Trio64V+ and whatever PC96 could muster, not to mention a decent NV 7600 or higher.

The problem seems to be that the VGA memory a0000-c8000 is handled as ISA even though it's on a PCI card.

A DOSBox or hardware supporting legacy standards problem?

The latter if it's true.

Hmmm.... It seems that bypassing emulation for video hardware is uneccesary, because emulation is still faster due to video card performance we have today.

How about GLide wrapper, though? I've never tried such thing, but is running 3dfx games on GLide wrapper faster than running on real 3dfx hardware?

Sound, on the other hand, is another thing. I think what GH is mostly concerned is sound issue --thus, adding a feature to bypass sound emulation when the real hardware exists is still a viable proposal (unlike video hardware). So there goes the DOS game, running on Win98 and real ISA soundcard, but bypassing the sound emulation because real hardware is detected.

But you'll not really bypass sound emulation....What's being run within DOSBox has to be passed out to the real device in some common denominator fashion. That's why DOSBox uses DirectX on Windows and Sound servers on Linux.

It's a fool's errand.

dh4rm4 wrote:

But you'll not really bypass sound emulation....What's being run within DOSBox has to be passed out to the real device in some common denominator fashion.

Why in a common fashion?

My guess is that DOSBox works like most other emulators do, in that it's like a game engine - it processes various functions/requests internally such as screen drawing, sound processing, input methodologies all to some sort of internal clock cycle. If one major aspect is passed out the 'engine' to real hardware. that aspect better not want any (or at least not much at all) feedback from the internals of the engine otherwise it'll bring down the overall performance as the engine waits for feedback from real hardware. real MT32 support in DOSBox works pretty much perfectly because the MT32 was generally treated as a one way device - MPU401 interface MIDI OUT plugged into MT32 MIDI IN. The only time the PC new much of what was going on with the MT32 was at initialisation stage, when SYSEXes were loaded and MIDI errorlevels can be sent back from the synth itself.

Soundcards that manage wave manipulation and real time MIDI Music effects are another matter entirely as they, their drivers and the game that utlise them often interact with the CPU and host system busses (such as in Bus Master modes) in use. This would be compounded even further if DOSBox had to wait for the game it's running to do this too - that is, manage the real soundcard hardware itself.

Going back to my point about engines, it's far smarter and overall more efficient for DOSBox to emulate sound and display hardware than it is to pass data out to and wait for data from the real thing.

That's pretty much what's hal's example of the Trio64V+ tells us - the legacy issues of real hardware slow down the performance of DOSBox's overall emulation.

About passing sound emulation to real hardware... it might not be such a joy because DOSBox timing is not steady in short-term. With the real VGA card games and demos had no chance to synchronize to the video frame.

Currently I only have solutions for I/O-Ports and Memory ranges, IRQ might be possible some day too but DMA would be the trickiest.
Maybe I'll try the YMF262 part of the sound card some time - should only need I/O resources.

Wasn't Creative's SB Link some sort of similar idea in hardware?

I got the impression now that games using the non-linear VGA memory modes do get a noticeable speed-up. It's also a nice debugging data source since the S3 BIOS and Windows 95 Trio64V+ work with it. We can see all the port and memory access (if somebody decides to finish the DOSBox S3 implementation).

Passing through the OPL hardware does give a performance improvement on my old PC (the fastest one with ISA slots).
It sounds a bit different here and there but nothing drastic.

Could you dump the s3 bios? I got several non-s3 ones working in dosbox
(elpin, nvidia, vgabios, phoenix iirc) but never found "the real thing".

I'd be happy if DOSBox would allow me to use true OPL & CMS chips.

Could you dump the s3 bios? I got several non-s3 ones working in dosbox
(elpin, nvidia, vgabios, phoenix iirc) but never found "the real thing".

I dumped IBM's VGA BIOS, mainly because the card used an EPROM and I wanted the option to replace it if it went south.

> I'd be happy if DOSBox would allow me to use true OPL & CMS chips.

Is this a general request or would you like to try out the patch?

I've sent the S3 bios to wd. Got a lot more computer waste too 😉

Is this a general request or would you like to try out the patch?

What patch was that? How does it work? I have a Sound Blaster 1.5 with CMS upgrade sitting in my rig just waiting for that happy day.

It uses the Porttalk driver to make holes in NT's abstraction. On Win9x it works right away.

http://home.arcor.de/h-a-l-9000/test/dosbox_hardwareopl.zip

Config options:

oplmode=hardware
hardwarebase=220

(Hardware I/O-address of your real soundblaster)