cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/11/10/09:01:27

Date: Wed, 10 Nov 1999 13:56:29 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Updegrove, Timothy (Tim)" <tupdegrove AT lucent DOT com>
cc: djgpp AT delorie DOT com
Subject: RE: Allocating DOS memory in Windows
In-Reply-To: <2723E6389F55D311BDC200508B129547395A52@pai820exch003u.micro.lucent.com>
Message-ID: <Pine.SUN.3.91.991110135606.8611a-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 8 Nov 1999, Updegrove, Timothy (Tim) wrote:

> I'm programming a chip our group developed which is memory-mapped.
> I believe I'm programming it correctly.  In programming our chip, a
> descriptor is created in memory, the segment address of this descriptor is
> written into a register using memory-mapped I/O, and the controller is told
> to fetch the descriptor.

Now I'm *really* confused.  If you are programming a memory-mapped
device, why do you need the DMA techniques?  Memory-mapped devices are
either accessed via dosmemget/dosmemput (if they are mapped into
conventional memory, below 1MB mark) or by using the framework
described in section 18.7 of the FAQ (if the device is mapped above
1MB mark).

But in your case, you seem to tell that the device is mapped below
1MB, but still needs to be treated under Windows as if it were mapped
above 1MB?  Is this true?

> I don't believe the Windows driver is causing any
> problems, even though it is loaded.

What Windows driver is loaded?  Is this a driver specific to your
device?  If so, I'd guess that this driver is probably the reason that
you have to employ different techniques on DOS and on Windows.

> > > That is, the selector returned from allocating DOS memory under
> > > Windows doesn't appear to point to the same data as the returned
> > segment.
> > 
> > Please explain this in more detail.  How exactly did you arrive at the
> > conclusion that the selector and the segment don't point to the same
> > memory?
> > 
> >From Tim: I believe the selector and segment under Windows points to
> different memory areas because a logic analyzer on the PCI bus shows the DMA
> controller uses the same segment address in both cases but the data read
> from memory (the descriptor described above) is incorrect under Windows.

You need to read the memory using both the selector and the DOS
segment, in teh same environment (i.e. both under Windows in your
case), and compare the results.  This is the only way to make sure
that both addresses point to the same memory, as they should.

> Since I can write and read the memory area (the descriptor) using the
> selector in the program and from what I saw on the logic analyzer, I believe
> the selector and segment must point to different areas.

I find it hard to believe that this could be the case.  The selector
and the segment returned by __dpmi_allocate_dos_memory should *always*
point to the same memory, otherwise there's something terribly wrong
with the Windows DPMI host.

Did you try printing the base address of the selector returned by
__dpmi_allocate_dos_memory?

> > I think this is due to some bug.  But even if not, it should be easy
> > to find out from within the running program whether you run on
> > Windows, and employ the appropriate solution.
> > 
> >From Tim: I'm not familiar with what to check to see if Windows is running.
> Please send info if you know what to do.

Here's a code snippet that should be self-explanatory:

  dpmiregs.x.ax = 0x1600;	/* enhanced mode installation check */
  __dpmi_int (0x2f, &dpmiregs);
  /* Int 2Fh/AX=1600h returns:

     AL = 00:  no Windows at all;
     AL = 01:  Windows/386 2.x;
     AL = 80h: Windows 3.x in mode other than enhanced;
     AL = FFh: Windows/386 2.x
     anything else -- major version of Windows.

     We also check AH > 0 (Windows 3.1 or later), in case AL tricks us.  */
  if (dpmiregs.h.al > 2 && dpmiregs.h.al != 0x80 && dpmiregs.h.al != 0xff
      && (dpmiregs.h.al > 3 || dpmiregs.h.ah > 0))
    int windows_version = dpmiregs.x.ax;

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019