Hi Tom, Michael, not giving up on that one yet... Michael wrote: > On another front, it appears that Tom Ehlert has rejected the idea of > MONOUMB and VGAUMB options. As you may know, he has the overriding vote in > what gets added to EMM386...
Tom wrote: > I have seen VGA/EGA BIOS's that will touch a000 ... > while loading charactersets, etc. This is why my suggested implementation contains an int 10 wrapper which: > spoils EGA/VGA detection in int 10.12.bl=10 / int 10.1a00 > and int 10.11.bl!=30 for VGAUMB. You have at least two reasons to use VGAUMB / MONOUMB: One is because it gives you more UMBs as long as it is safe, for some generic boot disk. Of course you are supposed to put no Hercules graphics games or font loading on that generic disk. But just in case, int 10.11 *is* the loading charset interface, and is already blocked by the wrapper. Another reason to use MONOUMB or VGAUMB is because it is more convenient and safer than brute force I=b000-b7ff I=a000-afff. Well-behaved progs will avoid touching EGA/VGA because the wrapper spoils the EGA/VGA/VESA detection. So you crash less often in *UMB mode than in I=... mode. Of course the suggested *UMB mode is not for everybody everywhere. I myself like graphics modes and have enough UMBs anyway. Still, having *UMB on a boot disk which has some fixed collection of tools which want lots of UMB space is definitely better than using I=... on such a boot disk (possibly with some boot menu to select whether you dare to activate the I=...) and also better than not having enough UMB space. Next issue: Filling gaps in EMS 4 specs. Please do check my diff and give us access to a binary with it... Then I can check the pros (e.g. whether some MEM style tools here get happier) and the cons (e.g. how much the footprint grows - if most of the handler is in high memory, then it really does not hurt to have 4k higher XMS overhead in handle 0). I even offer to test those functions for which I happen to find no test tools manually, e.g. with DEBUG or by writing a test app. Trying to defend my implementations by group: - functions 49/4a: Just suppressed the "debug unimplemented functions" message for those, to make clear that they are INTENTIONALLY unimpl. - function 50.1: use segment addresses instead of page number: A small addition which fills a gap, why not :-P. - function 52: This is now a well-behaved implementation for a system which supports only volatile pages. Better than barking back "UNIMPL" at the caller for all subfunctions. - function 54: Full support for handle names (also affects the alloc and release functions, which now zap the name) will make the more verbose MEM tools happy. FreeDOS MEM probably uses no handle names simply because they were not available with previous EMM386. - function 55, map and jump: If you fix the jump, then things with EMS overlays can work better. However, as those things often do not live ENTIRELY in EMS, they could also just use map and then jump manually. Hmm... checked UiH... that one just seems to use functions: 41, 42, 44, 45, 47, 48, 4c. Another good candidate is mft (manifest) exe from QEMM: http://www.columbia.edu/~em36/wpdos/windowsme.html ... the exe extracts mft. exe, hlp and p*if. I the ~em36 guy is right, then we have good news: This real classic got freeware because Quarterdeck can show off the QEMM features in what MFT tells about you EMM. Dont try to do "First Meg" -> "Timings" on fast CPUs ;-). Testing in DOSEMU... diskette / harddisk 40:xx is 0, ser/par timeouts too. EGA structure pointer is 0, too. Any YES, it looks for handle names in "Expanded" screen. Even the expanded benchmark works, only expanded timings crash on fast CPU. - OS/E stuff: answering "already in use by OS" for functions 5b, 59.0 and 5d is more well-behaved than using the generic "NOT_IMPL" thing... - VCPI functions de08/de09: I think 386SWAT will be happy about debug reg access, at least if you run it in "do not intrude PL0" mode, but of course I cannot prove it without the functions being implemented. Other debuggers might be happy, too. In addition, my patch contains comment improvements and at least 1 bugfix :-). Phew. Eric PS: DOSEMU 1.2 does not implement functions 4f (partial map) and 55/56 (map and jump/call) either. On the other hand, it has full support for functions 54 (directory) and 5b (alternate map regs, dma), function 50.1, a well-behaved "all volatile" function 52, supports function 59 (get hardware info: raw page size 4k, 0 alt reg sets, no DMA chans, context save area is 2 bytes for each of the 4 16k pages), therefore supports OS/E access control function 5d... But no VCPI, sure. PS: MFT uses EEMS function 67.60 and many normal EMS 3/4 functions. At least: 41, 42, 43, 44, 45, 46, 47, 48, 4b, 4d, 4e.0/1/3, 54.0/2, 58, 59.0, 5b.3, 60 :-P ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
