News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

DOS extender problem

Started by Gunther, July 11, 2013, 01:48:32 AM

Previous topic - Next topic

Gunther

Andreas,

Quote from: japheth on July 25, 2013, 03:18:58 PM
you'll need to tell more details about the XMS status. My guess is that your machine has one or two "memory holes", caused by ACPI, which then results in scattered XMS memory blocks.

Attached is tool XMSSTAT ( binary + source, was included in jemm ), which will display the XMS status.

I'll check the XMS status and post the results.

Steve,

Quote from: FORTRANS on July 25, 2013, 10:04:37 PM
Hi,

   Well, mostly.  As a curiosity, OS/2 has been updated and is being
sold as eComstation.

http://www.ecomstation.com/

Aside from being interesting, and it works, I am not sure why
most people would care.  I use an old OS/2 Warp system more
than the eCs system I have.

Regards,

Steve N.

Nothing offending, I've used Warp 3 and Warp 4 in the 90s for a long time and it was a good operating system with rock solid preemptive multitasking. The only point was the driver question for new hardware. And again, the DOS emulation was very good.

Gunther
You have to know the facts before you can distort them.

Gunther

Andreas,

that's what xmsstat brings.


XMS call address: 020A:00CF
XMS version: 3.0
HMA handled by XMS host, HMA is allocated
largest free memory block (v2) in kB: 65535, total free: 65535
largest free memory block (v3) in kB: 3627508, total free: 3640652
XMS handle table at FFFB:CC90, handle cnt/size=48/10
XMS handle array at FFFB:D58E

no handle region            size(kB) locks flags
--------------------------------------------------------
  1 D58E   00110000-00110FFF        4     1 02 used
  2 D598   DD793000-DD796FFF       16     0 01 free
  3 D5A2   DE07A000-DED3DFFF    13072     0 01 free
  4 D5AC   DEFF2000-DEFFFFFF       56     0 01 free
  5 D5B6   00111000-DD78DFFF  3627508     0 01 free
--------------------------------------------------------
                              3640656
free handles: 43
no UMB handler installed


Gunther
You have to know the facts before you can distort them.

japheth

Quote from: Gunther on July 26, 2013, 12:17:23 AM
that's what xmsstat brings.

Thanks! As I did suspect, there are a few "holes" in XMS memory. I edited your list a bit to make it more clear:


  1 D58E   00110000-00110FFF        4     used
  5 D5B6   00111000-DD78DFFF  3627508     free
           DD78E000-DD792FFF       20     ACPI
  2 D598   DD793000-DD796FFF       16     free
           DD797000-DE079FFF     9100     ACPI?
  3 D5A2   DE07A000-DED3DFFF    13072     free
           DED3E000-DEFF1FFF     2768     ACPI?
  4 D5AC   DEFF2000-DEFFFFFF       56     free


I doubt that ACPI really needs 9100 or 2768 kB of memory, but somehow those memory ranges aren't free to use on your machine.

However, this is of course no excuse for hdpmi to fail. I checked the program source ( it has been a while since the last time ) and did indeed found a "quirk". Attached is a modified version of HDPMI32 which has a good probability to work with your original program.

If you can test it, please tell the results and if it works, I will add the modifications to the standard hdpmi included in HX.

Gunther

Andreas,

it seems that you've found the little quirk. The program can now allocate the entire reported free memory block. Works fine. Thank you.  :t

Gunther
You have to know the facts before you can distort them.

japheth

Quote from: Gunther on July 26, 2013, 04:54:49 AM
it seems that you've found the little quirk. The program can now allocate the entire reported free memory block.

Thanks for the feedback!

HX has been updated with the modified HDPMI.

Gunther

Hi Andreas,

Quote from: japheth on July 28, 2013, 03:58:54 AM
HX has been updated with the modified HDPMI.

that's good news; thank you for the fast bug fix and update.

Gunther
You have to know the facts before you can distort them.