Mail Archives: djgpp/1998/03/15/09:16:31
In comp.os.msdos.djgpp art socha <sochaxx AT flash DOT net> wrote:
> Ok, I finally got NASM to avoid using DJGPP's crappy looking unix-style
> assembler. It works great.
It's a matter of what you are familiar with, I doubt I'll ever
find inteL assembler to be as comfortable to write as 68k, but price
and performance dictates that 386 asm is what has to be written.
> Now to write to video memory. Obviously I'm using 32-bit pmode and need
> to access video memory. Now then, using TASM with DOS32(a 32 bit extender
> for asm programmers), i simply access video memory via
> mov eax,0a0000h
> mov [eax],15 ;plot a pixel in the upper left hand corner...
> 0a0000h as opposed to 16-bit segmentation 0a000h
OK, when running with virtual memory active, no address is truely
attached to any area of hardware. Any connection between 32-bit pmode
(386) addresses and 24-bit segmented (286) real mode addresses is
a convention of the virtual memory scheme being used. This makes me
think of another issue that irritated me recently, getting the package
DJGPP\CONTRIB\PDCURS22 to run without seg-faulting required that I
had a good look at the various dodmemput() and dosmemget() functions.
These are probably of limited use to an assembly language programmer
who is looking for speed but they are fine for text based curses
programs.
What I found strange about pdcurses is that the FAR_POINTER macro
added an offset of 0xe0000000 to the dos memory address for dosmemput().
This caused crashes in the sample programs (such as firework.exe)
right at the dosmemput() call. When I took out the 0xe0000000 offset,
no problem, it worked fine. Is this evidence of a conflicting scheme
that sticks a mapping into very high memory for direct writing to dos
memory? Is there any real standard here? -- I have seen several bizzare
suggestions turn up such as looping the memory pointers through full
circle to get low numbers out of high numbers.
Coming from a slightly different background to most DOS programmers,
it seems to me that you should make the MMU work for you rather than
against you. That's the whole idea of having source to the libraries.
What you must do is create a mapping between the hardware that you
want to use and some virtual memory space that you have easy access
to.
Calls such as __djgpp_map_physical_memory() are fairly close to
the ticket. Some older dpmi servers will fail with this though.
Servers running through a virtual DOS (such as Linux dosemu) may
refuse to allow some memory to be accessed at all but this suggests
that some hardware feature is not supported in the emulator (eg SVGA)
so it's pointless to run on such a system anyhow.
I would think that you can do a tiny bit better by having some
function like `alloc_map( length, offset )' that returns a pointer
to remapped memory but that pointer is also guaranteed to be unique
and not interfere with pointers returned by malloc() calloc() and
whatever. Once __djgpp_map_physical_memory() is doing most of the
work, writing something such as `alloc_map()' shouldn't be too difficult
and would give a solution that (should) make everyone happy.
It should also allow a program running in a virtual DOS box to have
a graceful way of dropping out when hardware access is denied or
not supported and it allows emulators to have a graceful way of redirecting
physical hardware access to emulated hardware.
How does the speed of the MMU remapping compare with other methods
of writing to real memory? I'm guessing it would be fast because it
is done by hardware.
- Tel
> this works fine with the flat mode in TASM linked with DOS32!
> however using NASM i keep getting a general protection error when it
> reaches the mov eax,0a0000h statement. doesn't make much sense to me
> unless NASM or DJGPP is protecting video memory from being written (and
> why this would be i don't know).
> anyway, if you can shed some light on this mystery it would help
> tremendously.
- Raw text -