How fast would a graphics library that worked like this be?
When you call one of it's graphics functions, it wouldn't actually draw whatever immediately, instead it would add it to a to-do list. Then when you call the execute function it switches into protected mode and does everything on the to-do list using a linear frame buffer (which is faster, simpler and easier), then switches back to real mode.
Switching to protected and back would add a lot of overhead (or would it? Does anybody know?), but it could be faster if you didn't call the execute function too often and use a large buffer for the to-do list.
What do you think?
I think the library would only be faster if the buffer functions for the to-do list are FASTer than the calling of the function itself. Only then, the time compensated by the Execute function will become available.
Moreover, the execute function would be very large for support for everything, so it has to be fast too.
But when you got the functions, I think it would be very fast. I'd like to see the library when it's finished!
Not sure what the overhead would be either, but as long as you could switch in/out 60 times a second without eating too much time, it would work.
The XMS driver has to switch into protected mode to access XMS memory, doesn't it? That doesn't seem to slow a program down much. Ok, maybe I'll try it.
I've written both protected (a little) and real mode asm before, but I've never had to switch modes manually, I'll have to read up on the fastest way to do that. I hope this isn't out of my league.
Afaik, XMS and PMode aren't different concepts. You don't have to switch into PMode to access XMS, as XMS is an older concept than PMode.
Also, to access &HA000 segment you need to be in real mode. What are you intending to do in PMode? (excuse my lack of info
)
Oh I know that XMS and pmode memory are not the same thing. I just figured that HIMEM.SYS must be switching into pmode if it's accessing something outside what the CPU can address in real mode.
As long as you're in a flat memory model, you can access the first megabyte, including &HA000, right?
AFAIK, no. Mind that &HA000 is just a window to your video card memory. In PMode, that can be mapped to anywhere, depending on your programs memory needs. That is, your screen won't always begin in the absolute addres &H000A0000.
When I first tried DJGPP (a 32 bit, PMode C compiler, GCC port), before knowing Allegro, I did my GFX "by hand" (poking to segment &HA000 and stuff). A short tutorial which came with the compiler told that to access video memory, the DOS extender (which ran the PMode application) had to switch back to real mode, so they encouraged to use buffers so we only had to switch once per frame, saving the time used to switch from a mode to another.
I've extracted this piece of text from DJGPP site (
http://www.delorie.com)
Quote:10.2 Accessing the video memory
Q: I try to access the video memory at 0xa0000, but my program crashes with SIGSEGV....
A: Absolute addresses of memory-mapped devices are mapped differently under DJGPP than what you might be used to under other DOS development environments. That's because DJGPP is a protected-mode environment, in which you can't just poke any address: that's what protected mode is all about! To access such absolute addresses, use the so-called "farptr" functions like _farpeekb and _farpokew; they are described in the C Library reference. See more details on using "farptr" functions to access absolute addresses in low memory, below.
[...]
Basicly, memory is protected and you can't access it "directly". You have to communicate with OS (in this case with the DOS extender) to gain access to certain areas. That's why the fastest thing you can do is switch to real mode: this unprotects the &HA000 segment and you can directly poke into it.
Quote:But those still ain't fast enough? That's when to break out the near pointers. Basically, you can address the DOS area with your default DS, it's just that it's protected from you. But you can change that with __djgpp_nearptr_enable(). What's the catch? It turns off ALL memory protection on the DOS memory area (first 640k)! Use at your own risk.
#include <sys/nearptr.h>
char *screen;
if (__djgpp_nearptr_enable() == 0) return ERROR; /* could happen */
/* You must recalculate the screen pointer every time you enter this mode
because __djgpp_conventional_base can change when you malloc/new and other
misc stuff. */
screen = 0xa0000 + __djgpp_conventional_base;
screen[0] = 1;
screen[1] = 1;
/* etc. */
__djgpp_nearptr_disable();
Each of those screen moves is one instruction, of course. And screen is a honest-to-god [19] pointer, that you can memcpy to and from, or whatever. (Hint: If the length of a memcpy is fixed, and -O1 and up is turned on, memcpy becomes an inline rep movsl (rep movsd in TASM notation).)
Extra Note: __djgpp_nearptr_enable() is SLOW. Call it at most once per frame, and preferably just once at startup. While you're still debugging, though, you might want to turn it off and on per memory access.
Again, I don't understand what you want to do in protected mode with the GFX: You can have 32 Mb in your videocard memory, but only 64 Kb are mapped in the &HA000 segment. What are you gaining?
Anyhow, I encourage you to try it and tell us your experiences.
This stuff about &HA000 was just a side discussion, a tangent.
The main idea here is that I could switch to protected mode to use a linear frame buffer for VESA graphics, which you can't do in real mode. This would not in any way involve &HA000, unless the graphics lib were to support VGA as well.
Nice to know. I'm now curious about something... A "frame buffer" means that you'll be accessing your video card memory directly?
Yep, no windowing required. Much simpler, easier, and faster.