Mail Archives: djgpp/1997/07/26/12:01:37
You wrote:
>I am working with the PC frame-grabber board under DJGPP v1
>(gcc v2.6.3).
Off the subject: You really should upgrade. 2.01 is the current version and
it's much better!
>The board has memory of 1MB and is mapped into PC's address
>space at addresses 0xA00000-0xB00000. My computer has 8MB of
>memory. I access frame-grabber's memory with the expression:
>*(0xE0000000+0xA00000+i).
>It works fine but I was wondering why the access to memory mapped
>at 0xE0000000 was so slow.
Memory-mapped I/O devices are often much slower than the computer's normal
RAM. There are a few possible reasons for this:
1. Just plain slower memory, meaning longer access time
2. If the device is doing something else (i.e. reading a frame) your memory
access may have to wait, in order to avoid collisions.
3. Memory other that normal RAM is usually not cached. This is a Good Thing
when the memory is changed by something other than the CPU, because
otherwise the cache controller would never know about the change and keep
feeding you stale bytes.
>Why the access to the memory which don't have representation in the
>physical memory is so slow and why don't I get 'Segmentation Violation'
>when accessing that memory ?
In DJGPP v1 the device of adding 0xE0000000 to an address avoided
segmentation violations, AFAIK.
>If I changed the frame-grabber base address to the address which
>would overlap the physical memory (for example 0x700000) - should
>the access to the grabber's memory be faster ?
I seriously doubt it. Reasons 1 and 2 above depend on the hardware, and as
for 3, you don't want caching anyway.
>Should the ``FAT DS'' hack described in the Chapter 18.10 of the FAQ
>list (faq102.zip) work with go32 extender and GRX v1.03 library
>(which do not work in DPMI) ?
The "Fat DS" hack, AFAIK, only works in v2. There is a GRX package with v2
that does work under DPMI, since v2 uses DPMI exclusively.
HTH
Nate Eldredge
eldredge AT ap DOT net
- Raw text -