Hello Eric,
It is normal that older types of queries return simplified
descriptions of the state of the world, compared to newer
types. So you could say it is the "fault" of DOS to not
use the full BIOS list of areas. But as you already know,
the int 12 or 40:13 method has worked fine for 40 years.
As far as I know, since its inception, int 0x12 has always referred to
the amount of _available_ contiguous conventional RAM starting at 0:0.
It has always been a given that the memory reported by int 0x12 is
actually _available_, no ifs, no buts.
int 0x15, ax = 0xe820 was only introduced in later BIOSes.
(Anyway, practically speaking, one can probably work around this
0x5800:0 problem with an extra DOS utility or device driver. But to me,
it still feels silly to even have to do this.)
(1) the CMOS settings are out of whack;
(2) some RAM chips have gone bad; or
None of those would have been likely to be REPORTED in a
memory map. Of course if you can change CMOS settings in
My thinking is this:
(1) If there are only 352 KiB of contiguous memory starting at 0:0, then
int 0x12 should really, really, _really_ just report that there are "352
KiB" of such memory, and leave it at that. If it does not, then I
(still) consider that to be a bug.
(2) int 0x12 and [0:0x413] might have got their information from the
CMOS --- while int 0x15, ax = 0xe820 was getting its information from
some other place. If so, then perhaps one can fix this by simply
writing the correct base memory size into the CMOS.
Thank you!
--
https://gitlab.com/tkchia :: https://github.com/tkchia
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
