Do you set a proper fullscreen video mode? Unless you set a fullscreen mode with the exact same format as your back buffer surface, Windows has to convert your frame to whatever format the screen uses (probably 24-bit RGB) on each flip, which is costly.
Getting to vesa/svga modes from v8086
Virtual mode is basically a CPU emulation mode for real mode code. You still need to explicitly switch to it before calling any real mode code (like BIOS interrupts).
Well I use SDL1 so I assume it does it right. I ask for [email protected]/* */ and that's the resolution and colour depth I have on windows98. Still, the performance is exactly the same whether I have a window or fullscreen
It only does it right if you ask it right. How do you create the window and set video mode? How do you put your frame onto the screen?
gFrameBuffer = SDL_SetVideoMode(640, 480, 8, SDL_SWSURFACE | SDL_FULLSCREEN);
Then the game draws shit into gFrameBuffer and at the end
SDL_Flip(gFrameBuffer);
If I replace SDL_Flip with simple memcpy to some buffer in ram it works about 2 times faster. I looked up the SDL1 source and it doesn't seem to do anything bad, it just uses the window API to put the stuff on the screen which seems to slow things down.
Then don't use Windows at all, do it pure DOS. You're coming at this from a modern mindset where everything needs a driver, but back then the hardware was the API. If you're using VESA BIOS and the original SoundBlaster then you don't need anything other than disk access. The additional effort in DOS extenders was staying compatible with other software like Windows, it was literally harder than not bothering with compatibility (see: Ultima 7).
But it sounds like you'd be /way/ better off with SDL on Linux if there's not a reason you absolutely needed DOS or Windows. You could even have the whole 'distro' packaged as an executable that bootstraps from DOS using loadlin. I did that a long time ago for a demo using svgalib and mikmod. IIRC I had it boot directly to my code rather than init so I was the only program running.
I wanted to do something like that. Can you say some more ? I want the svga lib since sdl supports that. Would I get .mod playback?
Start by getting a feel for Linux. A basic Debian install with no X11 for example. You'd be doing video through SDL/svgalib which is pretty direct and will map the ram for you. Audio would be through ALSA and is again pretty direct. You could either mix it yourself like in DOS or use a library that takes care of the mixing. You might like OpenAL as the interface is very much like doing SoundBlaster coding but with two buffers rather than autoinit DMA and it's low faggotry unlike gstreamer. If doing it yourself, be aware that mixing well is a surprisingly difficult math problem and you might be surprised how far away from the quality you expect today your own efforts will be.
Next make a stripped down Linux distro that just includes your program and dependencies. Embedded tutorials will help but getting it really small is a dark art. But you probably don't need really small anyway - a 64MiB squashfs partition is enough for a full debootstrap without stripping anything. Just make sure it's not running other services that could steal your CPU time.
Then look into booting the resulting blob via loadlin. I last did that like 20 years ago so you'll need to look into it. Note that you'll need to reboot afterwards as it completely replaces DOS but that's probably fine for you.
Btw, the advantage is that you'll have an entirely modern 'stack' and toolset to do programs for old computers. Doing real DOS development is not nearly as easy. I'm 39 and used to do some demoscene stuff back then and had a lot of fun, but holy shit are you guys spoiled today with the stuff you have available.
Let's pretend someone booted freeDOS. How would you go about finding hardware memory adresses for components like a ssd or a special hard disk? To write a driver that is.