Michael Devore <[EMAIL PROTECTED]> writes: > Of course, I should say enabled here, rather than disabled.
I think "disabled" is correct, assuming "disabled" is a synonym for "closed". (As in, the gate is closed, so it does not pass anything, so the A20 line is "disabled" and fixed at 0.) Actually, I think the terminology is confusing. As long as we both know what we mean :-). > Ultimately, though, the basic question is can we always a assume a > known A20 state under all the potentially external to- or pre-HIMEM > environments? The whole point of the A20 mechanism is to provide support for ancient software which assumes the A20 address line is always zero. So any machine, whether real or virtual (VMware/Bochs), which supports the gate at all must initialize it to the "closed" state. After all, ancient software does not know about the gate to begin with, so it could hardly be expected to close it! Only modern software which actually wants to use A20 could even know about the gate. So it is that software's responsibility to open it. So only a machine which does not support the gate at all could initialize it to "open". It might be reasonable to say that HIMEM64 "owns" the A20 gate, and therefore must be the first program to manipulate it. If this fails to work under some emulated environment, that environment is arguably broken... I just took a peek at the memdisk (from SYSLINUX) code, and it disables the A20 gate before booting the virtual machine. I think. I can test under memdisk and VMware if you want to give this a whirl. Your call. - Pat ------------------------------------------------------- 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
