Hi Michael, sure, my RAM is Memtest86+ tested okay... > I'd memtest were I you, in case of iffy RAM. Other than that, well, we > know RTM already has at least one stupid bug that FreeDOS kernel had to > work around.
Kernel? You mean the "XMS 2.0 clip to 0xfbc0 kbytes reported" thing? That would be HIMEM, not kernel... Or the "DOS version must have CX part zero" one? You always called that a "RTM32" bug, not sure if that is the same as RTM / DPMI16BI / Ergo. Probably the same origin, indeed. > >Now for my test results: RTM DOS extender spontaneously reboots if you > >have a specific XMS configuration and have no EMM386 or DPMI loaded. I found out that our 0xfbc0 clipping fixes MOST of the crash sources. The only other crash source are RAMDISKs. Both TDSK and XMSDSK (although the latter sometimes can work with the /t "alloc at end of XMS" - to keep low addresses un-alloced - option) enable the crash by their mere presence. The problem does not happen with the RAMDISK driver of Deskwork. If you know other RAMDISK drivers which I could test, let me know. Already compared the ramdisks a bit: TDSK 2.3 seems to be generally weak (e.g. the conversion size -> sector count is called in an endless loop if you select a disk size above 32 MB), but XMSDSK should be better... The boot sectors differ: XMSDSK has both 16- and 32-bit disk size filled in, "RAMDISK" (of Deskwork) only the 32bit one. RAMDISK has "FAT12" string, XMSDSK only "FAT ". XMSDSK has ...*1*8 geometry, RAMDISK has ...*255*63. OEM ID and LABEL differ. None of that seems to be relevant for the crash, at least not according to my test (edited the contents manually to make XMSDSK "boot sector quality" same as RAMDISK one before starting - or in the XMSDSK case - crashing Jazz Jackrabbit and the RTM DOS extender). To get the best of both worlds, you can combine FreeDOS HIMEM (allows up to 4 GB RAM while having XMS 2.0 clipping which protects RTM from being overwhelmed by "65535k XMS") and Deskwork RAMDISK (can be any size in FAT16 range, uses XMS 3.0, and is RTM compatible). However, it would be good to have a WORKING and really free and also, preferrably, open source ramdisk. Strange that TDSK and XMSDSK have, kind of, the same bug. But as I now tested with RAMDISK and found the crash being gone, we at least know that it is not a FreeDOS kernel bug. Note that RTM always works if you have a VCPI (e.g. EMM386) or DPMI (but not DPMIONE, somehow makes int 2f.fb42.1002 fail, "HPDA" problem?) provider loaded. Only the "use only XMS" mode has that strange xmsdsk/ tdsk incompatibility. Raw mode has no ramdisks (normally), so it is not overly relevant whether raw mode has problems ;-). Keep those "ramdisks other than tdsk 2.3 / xmsdsk 1.9i" URLs coming for some more tests (or test yourself and play a bit of Jazz or AuGoS), thanks! Eric PS: Thanks for the info, but what is the background? Descent is okay, works with DOS32a, so the bug is in RAW/XMS mode of DOS4GW itself... --> > No XMS properties matter. It also fails in raw extended memory without a > HIMEM driver loaded. Bug in either DOS/4GW Pro or Descent. No way to fix <-- Not really fix, but workaround. /max=... did not really help, so - ideas? ------------------------------------------------------- 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
