Date: Sat, 26 Jul 1997 09:00:55 -0700 (PDT)
Message-Id: <199707261600.JAA29611@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: tcho AT polbox DOT com
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: Mem mapped device questions
Cc: djgpp AT delorie DOT com
Precedence: bulk

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