joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.66k stars 378 forks source link

Hardware Passthrough #1146

Open KormaX-of-DOS opened 5 years ago

KormaX-of-DOS commented 5 years ago

Hi!

Because you intentionally target DOS as an underlying OS for DOSBox, you do something noone did before. Now there are things which are extremely useful on DOS but impossible on other systems, or, if they are possible, shurely a nightmare to implement. That is direct passthrough to the real hardware. Since DOS users mostly use DOSBox to emulate legacy sound cards on modern hardware, such as HDA integrated audio chipset or AC'97, it would be a great feature if one shouldn't sacrifice the performance at the same time. Emulating a whole computer is very hungry for powersources, so it would be useful if at least some hardwares were just used from the real computer. Primarily the video card. Emulating a VESA compatible card with 1024x768 resolution results eats up so many CPU cycles that playing the game is actually impossible, even 800x600 is bad. I can chose to play at 640x480 which is only good enogh, or I can play at a beautifully fast and smooth 1024x768, 1366x768, or even 2k resolution, but in total silence. No in-between variations. If there were an option in the config file for the HX extender version which simply forwards the real video memory or VESA BIOS, mots of the performance could be preserved, because DOSBox souldn't render the video with the CPU generating an SDL output. I wasn't even a problem if in this special mode the menu wasn't visible if there were either a hotkey to switch to a different mode, or one would just termninate DOSBox and restart it in a different mode to have menu. This is possible, because the client of HX is a regular DPMI client, so it can directly call BIOS or DOS int-s or access the upper memory.

A second thing is less important, but I would like to report the issue: the network adapter driver is a good thing, but does not work on DOS currently, because only a TCP/IP stack is provided by HX. It's not very important, but a different passthrough method sould be implemented on DOS to work, or the real packet driver should be visible from within DOSBox, so the client could use it directly. (Optionally letting the clien program to access the real system would be very likely a good option on DOS for features otherwise hard to implement)

Thanks for your work on DOSBox-X!

Regards: KORMOS Krisztián

yksoft1 commented 5 years ago

However VESA itself is not fast enough under 1024x768+ for gaming applications even if you have a modern CPU. You would need to use 2D acceleration feature of the display card.

Some use cases of DOSBox-X, for example PC-98 emulation, emulation is always required for graphics.

KormaX-of-DOS commented 5 years ago

VESA is more than enough for games designed that way. Blood, for example, has no access to my graphics card but the legacy programming interfaces of the sVGA line. Blood queries the VESA modes and even the widescreen high resolution modes work with fast and smooth animation. It's just beautiful, 1366x768, for example. But I do not have sounds. From inside DOSBox(-X), I have sounds on my HDA chipset thanks to HX+, but I sacrifice performance. If the game could communicate with the real VESA BIOS from inside DOSBox-X, I could have both the performance AND the sounds. A lot of DOS games are very happy with VESA on bare metal, but is restricetd to low performance within DOSBox due to the resource-hungry videocard emulation. Which is the output in sdl which is then converted to VESA, which is then fed to the real video card with the same CPU, which sould execute the game at the same time :D Even lowres games can suffer visual glitches sometimes when scrolling, but that is a minor issue. For higher resolutions, it would be really REALLY useful.

sikthehedgehog commented 5 years ago

Huuuuh I'm pretty sure VESA at high resolutions is fast enough for 2D applications (which a lot of DOS games were). You need to make sure to render in system RAM and only copy over the final result to video RAM though (since, indeed, the video bus is slow, but at least still fast enough to do a single copy of the entire framebuffer at full framerate).

Needless to say this is only feasible in protected or long mode, but if you're dealing with those resolutions your software is probably new enough to be using it anyway.