> >todo.txt emm386.txt and emm386.lsm are all outdated
> Not my file, not my file, and fully up to date.
Sorry. Did not mean to annoy you. So: Tom, could you update those files?
> And DOS/32A unhappy with too much memory...
As I have only 192 MB of physical RAM, I cannot reproduce the 256 MB
limit problems :-). However: You write that DOS extenders can use XMS,
VCPI, DPMI and raw (if no HIMEM/EMM386/DPMI loaded) memory. So: Would
any of the common DOS extenders (pmode/w, dos/16m, dos/4gw, cwsdpmi,
rtm / dpmi16bi, dos32a, which ones did I forget?) have a problem if
you were going to limit the amount of allocateable VCPI memory to the
amount of allocateable EMS, namely 256 MB? I mean, would all DOS
extenders be able to allocate extra RAM from XMS when they find out
that VCPI "only" offers them 256 MB? Would of course only affect the
non-outdated DOS extenders. Things like Jazz Jackrabbit (RTM) would
not gain anything from having more than 256 MB RAM available anyway...
(There cannot be more than 64k 4k pages of EMS, which equals 256 MB).
I know, you limit EMS size to 32 MB by default, because programs can
get confused if you have more (afair?), but then I still have the same
suggestion: Would any DOS extender get annoyed if only 32 MB of VCPI
memory are available and further allocations have to be taken from XMS?
> I can't run Lemmings [3d] on my machines, period.
Yes, I know. Only telling you my test results. You miss a weird
3d variation of the classic Lemming game that way ;-). By the
way, loading DPMIONE makes the Lemmings 3d hang-at-exit go away,
I think I will investigate that one further. Loading DPMIONE is
no real option as programs which use RTM (Jazz Jackrabbit, AuGoS)
just refuse (no messages) to start while DPMIONE is active. But
maybe I find other methods to make it work without DPMIONE...
That Raptor (DOS/16M) not enough memory (XMIN) error showed up
again, and yet again using RAP /? made it go away. No idea why,
but as long as it works... :-).
Things which I will have to check better: How to make RTM-using
programs work in "only HIMEM" case without having to use a very
small (31M or so) /max=... value. In particular, I wonder why it
did not help to use /x2max32... Maybe I better allocate 64 MB to
Bochs and debug a bit... Other issue is DOS4GW in "only HIMEM"
case which crashes if too much RAM is free, too. Will at least
try to find the maximum value for that one. That :24d7 crash GPF
offset seems to be typical for it.
And, by the way: DOS32A did indeed exit without de-allocing a
locked XMS handle for me once, but I could not reproduce and it
only happened while DPMIONE was loaded. Strange. 50+40 MB were
blocked that way. If more people have problems with dangling
allocations, I could write an XMS handle zapper (use at your
own risk, of course ;-)). For EMS, an alloc/list/dealloc/map
interface is even present as part of the DEBUG user interface.
So... let me see... Asking Tom to update the docs. Asking me
myself to try to figure out Lemmings 3d, RTM-blocked-by-DPMIONE,
Raptor DOS/16M sometimes-XMIN, RTM-versus-32MB-versus-X2MAX32,
DOS4GW versus too much XMS problems. Quite a few. Will probably
only manage a part of them. But you are right, problems are
mostly on my side now, and for what you could test and debug,
you have done a very good update in that 0.01 version step :-).
PS: While DPMIONE is loaded, Descent reported 3.9 GB virtual
(swapfile), even though I have at most 300 MB free on all DOS
partitions together. So DPMIONE creates swap out of blue air :-).
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Freedos-user mailing list