Mail Archives: djgpp/1999/11/11/15:01:28
Eli,
Thank-you so much for continuing to help me. I was out for 2 days so I
didn't see your response till now. I'll be at Comdex in Las Vegas next week
so after Friday, it will be a little while until I respond. See below for
my embedded answers.
> ----------
> From: Eli Zaretskii[SMTP:eliz AT is DOT elta DOT co DOT il]
> Sent: Wednesday, November 10, 1999 6:56 AM
> To: Updegrove, Timothy (Tim)
> Cc: djgpp AT delorie DOT com
> Subject: RE: Allocating DOS memory in Windows
>
>
> 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).
>
From Tim: I called it a DMA controller because hardware transfers the data
once descriptors are setup. It really is a memory-mapped device.
I didn't know about dosmemget/dosmemput, I was using _farpeekl and _farpokel
which have worked fine up to this point. Could this explain my problem?
They were used for writing and reading the memory-mapped registers, which
works fine in DOS and Windows, and these functions were used to read and
write DOS allocated memory, which has a problem. I'll try using
dosmemget/put but it may have to wait a week.
> 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?
>
From Tim: the device is mapped above 1MB but I allocated buffer space for
descriptors in DOS memory. Should _farpeek and _farpoke be used above 1MB
for the memory-mapped area and dosmemget/put used to read and write the DOS
allocated memory (this is what I'll try)?
> > 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.
>
From Tim: Yes, the driver is loaded for this card in Windows. It is
possible that the driver is getting in the way. However, the program works
in Windows (with the same driver loaded) when the extra DPMI steps are
included.
> > > > 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.
>
From Tim: now that you taught me about dosmemget, I can use this function to
check the same memory area using the DOS segment.
> > 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:
>
From Tim: As a last resort, I'll use this check. Thank-you. It looks like
a nice thing to know even if I don't use it now!
> 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 -