Date: Wed, 10 Nov 1999 13:56:29 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Updegrove, Timothy (Tim)" cc: djgpp AT delorie DOT com Subject: RE: Allocating DOS memory in Windows In-Reply-To: <2723E6389F55D311BDC200508B129547395A52@pai820exch003u.micro.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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;