Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

freedos and cwsdpmi with djgpp under Linux?

148 views
Skip to first unread message

rickb...@gmail.com

unread,
Aug 17, 2009, 3:39:40 PM8/17/09
to
I built a djgpp app using a debian Linux version of djgpp (gcc version
4.2.2) in http://www.by.kernel.org/pub/debian-cosy/dists/lenny/local/binary-i386/
The end of my Makefile looks like:
i386-pc-msdosdjgpp-stubify $(PROJ).exe

My CONFIG.SYS is:

DOS=HIGH
BUFFERS=20
FILES=30
LASTDRIVE=Z
STACKS=9,256

I run "cwsdpmi.exe -p" then run my app but it can't find XMS, this
command fails:

regs.x.ax = 0x4300; /* EXTENDED MEMORY SPECIFICATION (XMS) v2+ -
INSTALLATION CHECK */
__dpmi_simulate_real_mode_interrupt(0x2f, &regs);

If I add this to my CONFIG.SYS:

DEVICE=HIMEM.SYS

The above passes but when I try to alloc memory via:

regs.x.ax = 0x0900; /* Allocate extended memory block */
regs.x.dx = size_pg_align / XMS_BLOCK;
__dpmi_simulate_real_mode_procedure_retf(&regs);

it fails. Can anyone shed some light on this?

Thanks very much.

Rick Bronson

DJ Delorie

unread,
Aug 17, 2009, 3:47:28 PM8/17/09
to dj...@delorie.com

Are you running your app in a dos window under Linux, or on a plain
DOS machine?

Rugxulo

unread,
Aug 17, 2009, 6:00:46 PM8/17/09
to
Hi,

On Aug 17, 7:39 pm, "rickbron...@gmail.com" <rickbron...@gmail.com>
wrote:


>
> I built a djgpp app using a debian Linux version of djgpp (gcc version

> 4.2.2) inhttp://www.by.kernel.org/pub/debian-cosy/dists/lenny/local/binary-i386/


>   The end of my Makefile looks like:
>         i386-pc-msdosdjgpp-stubify $(PROJ).exe
>
>   My CONFIG.SYS is:
>
> DOS=HIGH
> BUFFERS=20
> FILES=30
> LASTDRIVE=Z
> STACKS=9,256
>
>   I run "cwsdpmi.exe -p" then run my app but it can't find XMS, this
> command fails:

This isn't really related, but I wonder why everyone always wants to
run the DPMI server resident beforehand, esp. since DJGPP apps will
load it as necessary anyways. In other words, I never do that, I just
let the stub load CWSDPMI (found in my %PATH%) if needed.

> regs.x.ax = 0x4300;  /* EXTENDED MEMORY SPECIFICATION (XMS) v2+ -
> INSTALLATION CHECK */
> __dpmi_simulate_real_mode_interrupt(0x2f, &regs);

Right, you didn't have XMS loaded.

>   If I add this to my CONFIG.SYS:
>
> DEVICE=HIMEM.SYS
>
>   The above passes but when I try to alloc memory via:
>
> regs.x.ax = 0x0900;  /* Allocate extended memory block */
> regs.x.dx = size_pg_align / XMS_BLOCK;
> __dpmi_simulate_real_mode_procedure_retf(&regs);
>
>   it fails.  Can anyone shed some light on this?

CWSDPMI is probably hogging all the RAM. If you use EMM386, it will
use paging and this won't happen. Try JEMM386.

http://www.japheth.de/Jemm.html

P.S. I wonder if you know why you're trying to use XMS. Typically
that's unnecessary. DJGPP is tightly integrated with pmode, C/C++
(mostly), and DPMI. Anything else is doing something a bit odd. (Are
you trying to use DMA or something like that??)

Charles Sandmann

unread,
Aug 17, 2009, 8:51:19 PM8/17/09
to
> regs.x.ax = 0x0900; /* Allocate extended memory block */
> regs.x.dx = size_pg_align / XMS_BLOCK;
> __dpmi_simulate_real_mode_procedure_retf(&regs);
> it fails. Can anyone shed some light on this?

cwsdpmi allocates the largest XMS memory block available
when it starts up. If there is only one block, it takes it all.

If you absolutely need an XMS block, you need to
"prepare" for it before running CWSDPMI (such as
allocate the block you need, allocate a second tiny block,
release the first block).

If you need an XMS block for another purpose (such as
a DMA buffer) - consider using DOS memory if it is large
enough, or just using a DJGPP allocated memory block
and using something like the code in
http://clio.rice.edu/djgpp/cwsdma.zip (or cwsdma2.zip,
I don't remember the difference anymore) to get the
physical addresses of the associated memory blocks.

rickb...@gmail.com

unread,
Aug 18, 2009, 1:04:56 PM8/18/09
to
> Are you running your app in a dos window under Linux, or on a plain
> DOS machine?

A plain DOS machine running FREEDOS.

> In other words, I never do that, I just
> let the stub load CWSDPMI (found in my %PATH%) if needed.

I've tried many number of methods to make this work. I picked just
one above.

> If you absolutely need an XMS block, you need to
> "prepare" for it before running CWSDPMI (such as
> allocate the block you need, allocate a second tiny block,
> release the first block).

I don't suppose you have an example of this method?

Basically I need a 1 Megabyte DMA buffer for a PCI card that has DMA
capability.

I got both cwsdma.zip and cwsdma2.zip, thanks for passing those
along. When I run #2 I get:

Allocated 8M DMA buffer at DJGPP address 0x93b00, physical 0x113b00
Virtual: 0x1000 Physical: 0x100000 Size: 0x13000
Virtual: 0x91000 Physical: 0x916000 Size: 0x1000
Virtual: 0x92000 Physical: 0x914000 Size: 0x1000
Virtual: 0x93000 Physical: 0x113000 Size: 0x1000
Virtual: 0x94000 Physical: 0x115000 Size: 0x7ff000
Virtual: 0x893000 Physical: 0x114000 Size: 0x1000
Virtual: 0x897000 Physical: 0x915000 Size: 0x1000

Looking at the Physical address, it's apparent that they are not
contiguous. If I used XMS would I get a contiguous one?

Thanks very much for all the help!

Rick

Charles Sandmann

unread,
Aug 18, 2009, 11:33:34 PM8/18/09
to
>> If you absolutely need an XMS block, you need to
>> "prepare" for it before running CWSDPMI (such as
>> allocate the block you need, allocate a second tiny block,
>> release the first block).
>
> I don't suppose you have an example of this method?

Not immediately, it's on a CD someplace (using TC if
I remember correctly). In a pinch it could be done with
debug.com :-)

> Basically I need a 1 Megabyte DMA buffer for a PCI card that has DMA
> capability.

OK!

> I got both cwsdma.zip and cwsdma2.zip, thanks for passing those
> along. When I run #2 I get:
>
> Allocated 8M DMA buffer at DJGPP address 0x93b00, physical 0x113b00
> Virtual: 0x1000 Physical: 0x100000 Size: 0x13000
> Virtual: 0x91000 Physical: 0x916000 Size: 0x1000
> Virtual: 0x92000 Physical: 0x914000 Size: 0x1000
> Virtual: 0x93000 Physical: 0x113000 Size: 0x1000
> Virtual: 0x94000 Physical: 0x115000 Size: 0x7ff000
> Virtual: 0x893000 Physical: 0x114000 Size: 0x1000
> Virtual: 0x897000 Physical: 0x915000 Size: 0x1000
>
> Looking at the Physical address, it's apparent that they are not
> contiguous. If I used XMS would I get a contiguous one?

XMS would make it contiguous. But in the example above, you have
a nice big chunk. If you look closely at the physical addresses you
can see it's actually even more contigous than it intially appears.
Potentially you should allocate the memory using sbrk() instead of
malloc(), then immediately touch it all (in sequence) to make sure
it is contiguous. Or do your own scatter/gather.

(note that chunk 1 -> chunk 4 -> chunk 6 -> chunk 5 -> chunk 3
-> chunk 7 -> chunk 2 is all contiguous).

Advantage of doing your own internal allocation and mapping
is that it does not depend on XMS (it will work in raw mode
without XMS, or even with EMM / VCPI loaded and no
preparation program). But if you only need 1MB, and allocate
2MB you can probably find a nice contiguous 1MB chunk
someplace without even bothering to map.


Charles Sandmann

unread,
Aug 18, 2009, 11:52:42 PM8/18/09
to
>> Allocated 8M DMA buffer at DJGPP address 0x93b00, physical 0x113b00
>> Virtual: 0x1000 Physical: 0x100000 Size: 0x13000
>> Virtual: 0x91000 Physical: 0x916000 Size: 0x1000
>> Virtual: 0x92000 Physical: 0x914000 Size: 0x1000
>> Virtual: 0x93000 Physical: 0x113000 Size: 0x1000
>> Virtual: 0x94000 Physical: 0x115000 Size: 0x7ff000
>> Virtual: 0x893000 Physical: 0x114000 Size: 0x1000
>> Virtual: 0x897000 Physical: 0x915000 Size: 0x1000
>>
>> Looking at the Physical address, it's apparent that they are not
>> contiguous. If I used XMS would I get a contiguous one?

Wait a second here ... Note the text allocated 8MB buffer @ 93b00
The rest of the virtual/physical descriptions are for most of
the rest of your image (0x13000 at start of memory, some
stack at 0x916000, expanding down, some malloc increase at
0x113000). So expecting that you want 4KB aligned memory,
allocating 8MB, then rounding up to nearest 4MB page
0x94000 - you get 4MB - 4KB of buffer to play with.
(the other strangeness in memory layout has to deal with
sbrk setting boundaries around the memory block).

So it appears you have the 1MB buffer you need here.


rickb...@gmail.com

unread,
Aug 19, 2009, 1:59:01 AM8/19/09
to
I seemed to be making some progress using Rugxulo's suggestion of
using http://www.japheth.de/Jemm.html

Using this seems to get me my contigous 1 meg without scatter/gather.

Thanks again for all the help!

Rick

0 new messages