Xref: utzoo comp.os.os2.misc:493 comp.os.os2.programmer:370 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bywater!arnor!larios!db3l From: db3l@ibm.com (David Bolen) Newsgroups: comp.os.os2.misc,comp.os.os2.programmer Subject: Re: Fast a20 support??? Message-ID: Date: 20 Dec 90 15:46:51 GMT References: <90353.082842TACON019@ysub.ysu.edu> Sender: news@arnor.uucp (NNTP News Poster) Organization: Laboratory Automation, IBM Thomas J. Watson Research Center Lines: 75 In-Reply-To: TACON019@ysub.ysu.edu's message of 19 Dec 90 13:28:42 GMT In article <90353.082842TACON019@ysub.ysu.edu> TACON019@ysub.ysu.edu (Fred Ullom) writes: (I've muffled the "shouting") >We are having trouble with some new 386sx machines on our network. > >We talked to the network vendor and they said that some vendors are not >providing "fast a20" keyboard support in their sx boxes and the network >software requires this to operate in protected mode. > >Has anybody heard the term "fast a20" support or can tell us what this >is? Well, I can't say whether the "fast a20" support is your problem, but what I believe your network vendor is referring to is the use of address line 20 (hence "a20") that is used in 286-class machines to return from protected mode to real mode, since the chip does not support the operation itself. Without getting into much detail, the 286 chip provides a method for switching from real (addressing is done as with the 8086) mode into protected mode (new addressing with selectors and tables - only available on 2/3/486), but not the reverse. This is a problem for systems (like OS/2 and apparently your network software) that run in protected mode, but also want to switch to real mode occasionally to run programs that only work there. What was done on IBM's AT (and similar machines) to get around this is a method that effectively reboots your machine to get back into real mode. When the system wishes to return to real mode, it enables a20, then turns off the processor. An external signal (which had better show up - often, a periodic keyboard interrupt or similar signal is used) will turn-on the processor, but since a20 is enabled, the system software will gain control rather than the system doing a normal boot. Since all of the 80x86 chips start up in real mode, this effectively returns from protected mode to real mode. Unfortunately, this is a (relatively) slow process, because of turning the processor off and on again, as well as the delay while awaiting the external signal. I presume that the "fast a20" your vendor mentions is something which computer vendors have been designing into their boxes to decrease the wait for the external signal when a20 is enabled, thus decreasing the time it takes to make the context switch from protected to real mode. With all that said - I don't know why your network vendor is trying to do that sort of switching on a 386 based machine. Although the 286 chip doesn't provide support for getting from protected mode to real mode, the 386 (which the 386sx is compatible with) does. In fact, an example of the necessary code sequence is provided in the Intel System Software Writer's Guide for the 80386. So I wouldn't necessarily expect that any box designed around a 386 (or 386sx) would care about having the support for the a20 line. It could, but I wouldn't think it necessary. Of course, if your network software doesn't detect the 386 versus a 286, it may not function properly without the a20 support. It sounds like this might be happening, since your machine just reboots - part of the sequence to switch to real mode with a20. You might want to check with your network vendor about this because if they don't notice a 386 they should - besides being easier, the switching time is far less when using straight code on a 386 rather than the reset method on a 286. >We are also told that this problem will manifest itself on the sx box with >OS/2 running applications in the DOS compatibility box. I can't say for sure because I don't have an actual 386sx machine to test it on, but this is doubtful. OS/2 makes use of the better switching ability of the 386 chip when available, and doesn't need to use the a20 reset "trick", so I think you'd find the DOS box would run fine on your system. -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen / | Laboratory Automation, IBM Thomas J. Watson Research Center | / P.O. Box 218, Yorktown Heights, NY 10598 \ | - - - - - - - - - - - - M i t h r a n d i r - - - - - - - - - - - - | | Internet : db3l@ibm.com | Bitnet : db3l@yktvmv | | Usenet : uunet!bywater!arnor!larios!db3l | Phone : (914) 945-1940 | \-----------------------------------------------------------------------/