Mail Archives: djgpp/1998/01/05/12:18:33
On Mon, 5 Jan 1998, Anthony.Appleyard wrote:
> (0) Due to the nature of the work I must set up a screen display
> in an array and then bulk copy it to screen (in a 256-color mode:
> VESA 0x101, 0x103, 0x105, 0x107), by dosmemput()'ing it 0x10000
> bytes at a time to the graphics screen address 0xa0000 etseq. Is
> this the fastest way to copy bulk matter to the graphics screen in
> djgpp?
Using `dosmemput' and `movedata' are the fastest ways of moving large
buffers. Both of these functions use essentially the same code in
v2.01, so they have the same speed (in v2.0, `movedata' was faster).
> (1) In djgpp v2 how fast are farpokeb() / farpeekb() compared to directly
> writing to / accessing ordinary char variables?
First, for tight loops use `_farnspeekb' and `_farnspokeb' after
setting the selector once: this is faster.
The relative speed of the farptr functions relative to accessing
memory depends on your PC bus speed and the speed of the memory-mapped
device (in this case, the VGA) that you are accessing. My experience
is that accessing VGA is about 10 times slower than memory accesses,
on most garden-variety machines.
> (2) When a PC program runs in protected mode with 32-byte
> addresses, when it accesses a variable (if it is not swopped out
> onto disk at the time), does it genuinely access extended memory
> directly?
Yes.
> or does it have hidden time overheads due to DPMI / EMS / XMS / etc
> interrupt routines swopping extended memory areas in and out of
> conventional memory so the program can access them?
You are obviously assuming that DPMI memory is accessed by constantly
remapping it into some window in conventional memory. This is false.
What happens is that the logical address that your program generated
(like when you take the address of a variable foo by writing "&foo")
is transparently translated into a physical address by the CPU's
memory-mapping hardware, and the resulting 32-bit physical address is
put on the address bus. (The address translation doesn't consume
additional cycles, in case you wonder.)
> (3) A djgpp v2 program has an array of e.g. 1 to 4 megabytes. If I
> access or alter elements in it here and there at random rather than
> in sequence, am I thereby wasting much time making DPMI etc
> repeatedly swop memory segments about between conventional and
> extended memory?
No, see above. Memory is NOT mapped into conventional memory before
it is accessed.
> (4) If a program runs in real mode and accesses extended memory by directly
> calling the interrupt `AX=0x8700, int0x15' to swop memory segments between
> conventional memory and extended memory, could that program be safely called
> from Windows (3.1 or 3.1.1 or 95 or NT)?
It depends on the amount of extended memory that the DPMI server
and/or Windows let DOS programs use. For example, Windows 3.X take
this amount from the PIF file for the DOS box. I wouldn't count on
this to work in all environments. I also don't understand why do you
need this at all, since you have DJGPP.
> (5) If a program runs in real mode and accesses the graphics
> screen pixel values at address 0xa0000 etseq, is that access
> genuinely direct? Or is it via hidden interrupt routines which
> access the screen's RAM by reading and writing ports? Ditto re
> accessing the text screen?
Memory-mapped devices such as the VGA are accessed by driving the
system bus with the physical address of the video memory (0xA0000 +
offset). When the on-board address decoding logic of the VGA sees an
address that is inside the range of its addresses, it reads the data
from the bus when it is put there after the address.
No hidden interrupts and no ports are involved in all this.
> What is the speed of accessing screen RAM addresses compared to
> accessing ordinary RAM addresses?
See above. It's usually several times slower than accessing memory,
since the bus operates at a fraction (typically 1/4) of the CPU speed,
and every access to a memory-mapped device takes about 2 bus cycles.
> (6) What C or C++ compilers are there which compile into real mode? How to
> get them? I have `Small C', which compiles into real mode but as far as I can
> find only onto a .COM file, not an .EXE file. I have Borland C++ version 45
> for Windows: it can compile for DOS or for Windows, but apparently
> always into protected mode.
DJ Delorie has announced availability of a 16-bit version of GCC.
Look it up in the DJGPP mail archives at
http://www.delorie.com/djgpp/mail-archives/.
A related question is do you really need a real-mode compiler? If
speed is what you are after, that's not the way to get it.
- Raw text -