I was very used to moving data from and to video memory in real mode when a VGA mode was set. That was not a big deal, because you didn't have to switch banks and conventional memory was more than enough for a double buffer. For some reason, I quitted my interest in graphic applications when SVGA enviroments became standard and today I find myself trying to make a simple game for DOS, but under a SVGA mode. I've got a problem.
Calling interrupt to switch banks is very slow and I never get to copy the full screen before the vertical retrace is over. In addition, I don't have enough memory in the first 640K to hold a double-buffer, so I'm forced to switch pages with XMS or EMS unless I make up my mind to work in protected mode (that I'm not used to) with a DPMI or something. XMS/EMS page switching is very slow as well.

1) Is there any way I can trick this out in real mode?
2) Suppose I'd get to work this under protected mode. Can I get the video memory all lineary accessible in just one block so that I can avoid having to call bank switch routines (for anyway, these VESA routines seem to be realmode only)?

I hope you guys can help me with this (and I'm sure you can, because you're all genia)... BTW... remember I'm not such a genius when you reply Thank you very much in advance!

I think the bottleneck is the 16-bit code. DPMI already runs under protected mode so I sugest you make your code for 32-bit protected mode and do away with both the 16-bit and the DPMI stuff. That will give you the best possible performance.

If you really still want real mode then you have few options, paging is not active in real mode so you can only get the lower 1meg+64k-16 bytes. The next best is a v8086 task under DPMI (or similar) but you are still then using only 16-bit code.

PS: Don't waste the 32-bit CPU by using only 16-bit code

I agree with revolution, forget realmode go to pmode and ether go to and from pmode to realmode for int's etc, or write your own Pmode int's.

First is your vesa banked only ?, if so you will need to switch to realmode and back, this can be done much faster than you would think.
Here is a demo that switch to realmode for mode switching, could easy be changed to bank switching.
Will run from dos, but will need vesa2 unmodded, theres also unrealmode
http://www.dex4u.com/demos/DemoVesa.zip

PS: Also search for "CdPod" in the OS Dev part of the forum.

tmt pascal uses dpmi (in general) and vesa (for graphics). search for tmtp350d.zip in google. it can use both banked and linear modes, there are also some demos for comparing perforamnce of several modes.

if you want to learn something about vesa, look at www.vesa.org/Public/VBE/vbe3.pdf or search for ralph brown's interrupt list.

bank switching never will be fast. triple buffering with linear addressing mode should give best performance.

or maybe your routines are inefficient? look at www.majuma.xt.pl for some examples

Never read from VESA video memory...
Just write... and use a system RAM buffer to read from
Enable LFB if available inorder to avoid bank switching
Use custom bank switching and do not use BIOS calls
Use 32bits protected mode if possible

> 1) Is there any way I can trick this out in real mode?

Yes, but it is a bit advanced. In true real-mode the "unreal" mode could be used to directly write to the VESA linear frame buffer and alloc a double/tripple buffer via XMS in extended memory.

However, such a thing will work in real-mode, but almost never in v86-mode (emm386 or windows DOS boxes).

On V86-mode, when a V86 monitor (EMM386) is active, using EMS memory for double/triple buffers should be faster than XMS memory since no memory copy has to be done, but there are big differences in speed among the monitors.

To speed video memory write access ony might set the MTRRs on P3+ cpus.

Guys, first of all... THANK YOU very much! What you tell me, really helps and I have downloaded the files and checked the sites. Still, some of the things you suggest are not very clear to me. I'm not an absolute newbie at assembly, but neither am I as good as most of you in this site can be.

Revolution: I agree with you that 32bit would be great. The only thing I don't want to do is abandon DOS, so that's why I referred to DPMI. As long as I can program this for DOS, I do like 32bit mode. Bad thing is I am not use to PMode programming, but I'd like to learn. The lower RAM is what I use most of the time, but yes... it's not really an option. If I knew more PMode, I'd certainly not think of standard real mode at all for this purpose. Your point is good.

Dex4u: This is a TNT2. As far as I know, it's VESA 3, so I believe it must have a way to be worked upon in PMode and without banking. What I'd like to know is how and if I am right about that. I'd like to write my own routines, but... wouldn't that make things hardware-dependant? I don't like having to call ROM routines, but that's the only way I know that all cards will do the same thing. I think I must be wrong at this point. Am I?

Donkey7: What I already had is FreePascal, but again, I'm not used to it. I have some problems trying to use the "asm" blocks. It doesn't take somethings. I'll try TMT. Another thing... site looks great, but I'm afraid I don't speak Polish (That's Polish, isn't it?)

Bogdanontanu: That is exactly what I'd like to do. If you (or someone else) could write a short FASM source that did all that, I would be enormously thankful.

Japheth: Is "unreal mode" same as "real flat"? I understand double buffer, but I'm not 100% sure I know what a tripple buffer is, other than what it sounds like. I know real flat is very convenient, but requires EMM not to be loaded. It would be great to have an EMM driver that could be loaded and unloaded on the command line at any time. Not sure about what the MTRPs are... but I'd like to do something that would not require as much as a P3. A Pentium (1) requirement, I believe, would be acceptable for a small project as mine.

Cas: look also at the kelvar from the Examples section of this website. It uses the truly unreal mode and VESA (both banked and linear).

You should also with that card have LFB, if so you can assembly the code in my link as a mz exe and run it from dos.
Note: It must be real dos not wins dosbox, but you best bet is kelvar.

PS: May be you could look at hobby OS as the answer to your problem, as there will give you a easy way to implement your game in high res vesa.

Dex4u OS, Solar OS or Menuet OS, are worth a look.