What about video generation, one of the most resource demanding issues in DOSBox.

Not really.

My Glide patch will use Voodoo card natively if available, a wrapper is only required without one

I already tried this with a real S3 Trio64 and it is about the same speed as the emlated one. (and you get synchronization issues)

Very interesting, this could bode well for my ideal system.

I think it would be cool if we could just put a lot of the needed hardware into a PCI slot, (you can get some PCI 486 all in one boards.. 😉 and some how utilize them from DOSBOX.. Then DOSBOX just becomes our passthrough to the actual hardware.. 😉 now THAT would be cool 😀

If you think about it, DOSBox shouldn't have to do a whole heck of a lot in this department. It needs to find out what are the attributes of the video the game is trying to display, tell the native video hardware to set up a mode with the proper bit depth, palette and resolution, then send the video data to the hardware's frame buffer RAM. Most games do not change much beyond the palette, so the overhead from DOSBox should be minimized. I would think that the closer your hardware was to real VGA, the less emulating there would need to be. It seems less performance intensive for DOSBox to send palette register info to real palette registers than to send the full image having constructed the whole screen with the palette registers in software.

DOSBox shouldn't have to do a whole heck of a lot in this department.

Right, feel free to post your small diff here or at sourceforge.

Funny how you describe exactly what happens if you have the correct prerequisites (no scaler, 8-bit-capable video driver, fullscreen). All that happens then is more or less a plain copy, which isn't that expensive.

Okay, this is oversimplified, but it illustrates what wd already said in post #2: Video emulation is not at all resource-demanding. Unless you enable scalers, but then you asked for it.

Actually Thraka, that's been on my personal dosbox wishlist of ideas. I've long thought about having dosbox pass data between a networked machine with real hardware or just offloading the emulation. For instance, I have a real mt32 but only an ISA MIDI card. MIDI being extremely low bandwidth, and not even terribly latency dependent, it should be possible to use it for playback with DOSBOX across a network connection. Gigabit nics or even USB well exceed the 16MBs bandwidth of 16 bit ISA with only latency being a potential issue depending on the device.

ih8: there are many solutions for networked sound, video, and other hardware aspects. They are easy to use and more powerful than any simple dosbox-based solution. You should really use them instead of overloading dosbox with them.

It sounds like what you're referring to are for output datastreams over the network and not port commands, which wouldn't do. There's no changes needed for DOSBOX as far as MIDI goes, since it already does passthrough. What's needed is taking something like MUNT and add passing the MIDI commands it receives from DOSBOX over a network to a machine with a listening process(like MUNT again, but set for receiving) that finally passes to a real MT32 or emulates, rather than emulating from the sending machine. ie. typical client server. Or do you have some remote MIDI port handling software with windows and linux clients and servers in mind.(I'd end with a question mark but the key doesn't work..)

At least Linux has plenty of networked sound/video solutions that handle almost all data you can throw at it, including MIDI. There's no single software that does absolutely all, so I can't recommend any specific software, but networked media is a rather popular idea.

As for windows, I have not much experience there, but some things definitely work cross-platform, and there probably are distinct windows-only solutions.

Well, it pays to look again, found a gpl'd currently windows only project: http://www.linuxsampler.org/ethernetmidi/
I havn't set it up yet. Now just need to find similar for GUS and OPL/SB and I'm set.

Actually, it might even be possible to get it to work in Linux now by using WINE or QEMU/etc. Another thought for remote GUS and SB, besides port accesses, would need to pass DMA and IRQs.