Hi, I installed the 24 March 2004 version of EMM386 and the test results are very promising, although I still do not know why you have to use HIMEM instead of FDXXMS (did not test HIMEM64. EMM386 binary is 30706 bytes). If you use FDXXMS, system crashes as soon as UMB/XMS is used because IP wraps around at offset -1. With all configurations including DR DOS EMM386, BITDISK crashes (part of TDSK package, a small alternative to TDSK).
My caches (LBAcache, CDRcache) work, even if loaded to UMB. The CTSLOAD and UNEATABLE demos work. The S3 Virge chip 3d demo just shows a black screen (the self-highloading 4k TSR for VBE2.0 support detects only 2 MB RAM but creates a 3.5 MB framebuffer for this 4 MB card with VBE1.2 BIOS which I used for the test: 3.5 MB is okay because 0.5 MB seem to be reserved for 3d). Even the Intel ISA/PCI PnP Manager for DOS (stays TSR for Windows 3...) works even after loading EMM386. I found 2 BUGS in COMPINFO: It tries to do CPUID even if CPUID is not present, and if CPUID works, it ignores the result and just ASSUMES that a TimeStampCounter (RDTSC command) is available. Descent works, but I only tested with DOS32A (with DR DOS EMM386 and FreeDOS, default DOS4/GW would crash on some PCs...). Shareware 1.x version. Shooting gallery partially works: Mouse buttons are treated wrong with this Trust Ami Mouse 97 (with scroll wheel which I mapped to cursor keys in DOS but for which I did not find Linux drivers!). At least I can tell you now that the game generally works (in xDOSEMU 1.1.3.7, the MCGA detection fails). The freeware DOS version of AuGoS, the automatic Go player, works. An old version of PC Config (new versions are freeware) failed with an illegal instruction in "cmp [bx],0xfc80" where EBX is 0x0001ffff, interesting. Maybe it tries to figure out wrappability of pointers beyond 64k boundary. The high half of EBX is spurious, I think (after running CPULEVEL or my tool to enable CPUID on Cyrix M1 (which have hardly any features: FPU, dbe, cmpxchg8b, no TSC and no MMX etc.!) or similar software, most regisiters just stay as they are "upper half wise" until another program changes the upper half again). One time HIMEM hung during PS/2 detection, could not reproduce. By the way, there is a spelling error... it must be "machine", not "maschine". I think EMM386 should include the detected A20 state in the crash dump, which should be sampled right before starting the dump. The idea: Probably FDXXMS does not wait long enough until the A20 state really changed. Hm. It should not allow state changes at all while EMM386 is loaded, right? Maybe EMM386 already tries to ensure that but some lock count overflow spoils it. Infamous Jazz Jackrabbit (test case for "DPMI16BI is not compatible to all RAMDISKs that I know in FreeDOS, including XMSDSK, probably for all XMS drivers ...") works fine with FreeDOS EMM386 now :-). UMBPCI DMACHK reports that the page frame is "write protected" and that the UMBs all do not support ISA-DMA! I did not enable VDS but count on the DMA chip simulation instead. Strange. Raptor shareware 2d scrolling space shooter (known for containing some problematic "wait for SoundBlaster" in DOSEMU) works okay with EMM386, too. Lemmings 3d demo / shareware version (contains only the practice levels and one level per difficulty level) does NOT work with EMM386 but I remember that it worked with DR DOS EMM386. It does, like UNEATABLE, allocate some EMS for the wavetable sound simulation. I think L3D wants more memory than UNEATBLE. The L3D loading process tells that it allocates 3 MB EMS but then it tells either that it did not allocate enough (although I tested on a 32 MB system where 16 MB got allocated by EMM386 and all my software only uses XMS - more specifically 6 MB LBAcache, 3 MB CDRcache, 100k FreeCOM) or it tells "EMS error, unable to access load area". Maybe an EMS test tool would be a good idea, similar to HIMEM /TEST. Maybe VCPI memory is taken from XMS instead of from the allocated and locked 16 MB of "XMS for EMS usage"? According to the readme, Lemmings 3d needs 430-560k of DOS RAM plus depending on nothing (interesting, only DOS RAM hunger changes with sound config) 3 MB of EMS. They even recommend EMM386,SYS 3072 in the readme, so it does not look like it wants more RAM for VCPI at all? Maybe it only stores textures in EMS. By the way, SciTechSoft has made their SciTech Display Doctor (formerly UniVBE) for DOS freeware by now. Very cool. This is a TSR which provides VESA VBE3.0 services for many graphics cards, including very old VGAs. Can be combined with VBEHz or my VBE3FAST tool to modify refresh rates... Eric. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
