From: Newsgroups: comp.os.msdos.djgpp Subject: Re: DJGPP/NASM HELP!! Date: 15 Mar 1998 13:07:27 GMT Organization: Triode Internet Lines: 80 Message-ID: <6egjqf$ad6$1@hyperion.triode.net.au> References: NNTP-Posting-Host: xenon.triode.net.au Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk In comp.os.msdos.djgpp art socha 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.