DOS ain't dead

DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? (Developers)

posted by RayeR , CZ, 17.07.2011, 02:06
(edited by RayeR on 17.07.2011, 14:50)

> What about making it in real mode and use INT 15h/AH=87h instead?

I don't know if this function works with some linear adress or physical address. Also it may happen that I will need move >32kB and work even with larger data structures so I don't want loose the advantages of PM.

Next I simply want to know how should I correctly use DPMI mapping function.And nobody on djgpp google group neither here can tell me...

BTW even Microsoft cannot do their ACPI job well (quote from CoreBoot wiki):

Windows XP or Server 2003 setup might fail with an error message such as: "An
unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\
setup\arcdisp.c" The value 805262864 varies, and is the physical address, in
decimal, of one of the ACPI tables. The error message is displayed when a 1024
dword page table array used by setupldr runs out of space. This table is used
for mapping various physical addresses, such as those of ACPI tables (a
separate table identity maps the lower 16MB used by setupldr code and data).
Setupldr only looks at ACPI tables (FACP) to determine make and model of the
system. The make and model of the system is needed when setupldr scans the good/
bad bios lists contained in txtsetup.sif. The good/bad bios lists are used to
bypass installation of the ACPI enabled kernel on certain systems known to have
ACPI problems. The code loop that scans the lists creates a new mapping each
time it reads an ACPI table, and never frees mappings. The code uses FACP OEM
ID to determine the system model. The code sequentially reads tables listed in
the RSDT array until the FACP is found. Each read consumes one page table entry.
If more that 4 tables precede the FACP in the RSDT array, the 1024 entry page
table array will run out of space before the good/bad bios list processing
completes. BIOS can work around this Windows XP/Server 2003 limitation by
placing the FACP early in the RSDT array.


DJGPP/CWSDPMI seems to not support unmapping function so it may happen also there but mapping is freed when program exit...

int __dpmi_free_physical_address_mapping(__dpmi_meminfo *info);
Please refer to the DPMI Specification (DPMI Specification) for
details on DPMI function call operation. Also see the DPMI Overview
(DPMI Overview) for general information.

DPMI function AX = 0x0801 (DPMI 1.0 only). Not supported by CWSDPMI and
Windows.

---
DOS gives me freedom to unlimited HW access.

Complete thread:

• DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - RayeR, 13.07.2011, 14:58 (Developers)
  • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - Japheth, 14.07.2011, 09:15
    • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - RayeR, 14.07.2011, 15:09
      • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - Laaca, 15.07.2011, 12:47
        • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - RayeR, 17.07.2011, 02:06
          • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - RayeR, 17.07.2011, 14:47
            • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - RayeR, 02.08.2011, 13:08
              • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - Rugxulo, 05.08.2011, 22:25
                • DJGPP - Mapping small blocks of physmem beyond 1MB - __dpmi? - RayeR, 06.08.2011, 11:56