Professional Soft Collection 1.02

home *** CD-ROM | disk | FTP | other *** search

/ Professional Soft Collection 1.02 / Professional Soft Collection 1.02.iso / qemm.80c / technote.qip / XSTI.TEC < prev next >

Wrap

Text File | 1995-11-04 | 16.8 KB | 366 lines

QEMM and the XSTI Parameter Quarterdeck Technical Note #233 Filename: XSTI.TEC by Quarterdeck Testing and Compatibility CompuServe: XSTI.TEC Last revised: 05/01/95 Category: QEMM Subject: Detailed information on the use of QEMM's XSTI parameter, which can be used when QEMM reports "Disabling Stealth ROM because QEMM could not locate the ROM handler for INT XX." Q. Why do I see this message when I start my computer? QEMM386: Disabling Stealth because QEMM could not locate the ROM handler for INT XX" A. There are three possible causes: 1) You are loading a driver before QEMM which is grabbing interrupt XX; OR 2) A ROM is loading a handler for interrupt XX into RAM. 3) You are using a computer which was upgraded to an 80386 with an add-in board, such as the Intel "Inboard PC." There are several potential solutions: 1) Load the driver in question after QEMM. If it must be loaded before QEMM, load HOOKROM.SYS before you load this driver. During installation of QEMM, HOOKROM.SYS is installed in the QEMM directory. Assuming that QEMM is installed in a directory called QEMM on your "C" drive, the new line would look like this: DEVICE=C:\QEMM\HOOKROM.SYS HOOKROM is a device driver that may be needed if you use the Stealth ROM feature and are loading one of your device drivers before QEMM386.SYS in the CONFIG.SYS file. Though it is usually best to load device drivers after QEMM386.SYS, there are some special drivers (like the ones that manage some 80386 conversion hardware) that must load before QEMM386.SYS. These drivers can obscure information that QEMM needs to enable the Stealth ROM feature, in which case QEMM386.SYS will post the above error message. Placed before QEMM386.SYS in the CONFIG.SYS, HOOKROM will gather the necessary information for QEMM386.SYS and prevent this special driver from interfering with the Stealth ROM process. 2) Add the parameter "XSTI=XX" (where "XX" is the number of the interrupt reported in the message) to the QEMM386.SYS line of the CONFIG.SYS, then add the appropriate eXclude to this same line in order to keep QEMM from mapping over the portion of the address space where the ROM handler for interrupt XX resides. (See "HOW DO I FIND THE APPROPRIATE EXCLUDE?" below.) It may also be possible to reconfigure your system in such a way that the ROM no longer redirects an interrupt into RAM. This is the case with the Invisible Network. (See "KNOWN USES FOR XSTI" near the end of this technical bulletin.) It is also possible that a program you are trying to run, or even your operating system, wants to have a particular interrupt remain unStealthed. XSTI, with the appropriate eXclude, is necessary to get your program, or operating system, working with Stealth ROM. 3) Add the following parameters to the QEMM device line in your CONFIG.SYS file: XSTI=70 XSTI=74 XSTI=75 XSTI=76 A typical QEMM line would look like this: DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=70 XSTI=74 XSTI=75 ... XSTI=76 (Note that the preceding two lines should be on a single line in CONFIG.SYS.) Q. How do I find the "appropriate exclude"? A. First, note that QEMM's Stealth Testing will find automatically the majority of circumstances that will require XSTI, and will make the appropriate exclusions or S-pages. If the conflict you experience does not happen as part of the boot process. You find the appropriate eXclude by excluding all the address space occupied by ROMs, using the parameter FSTC, and doing an Analysis. First, locate all your ROMs. You can do this by looking at the First Meg/Overview screen of Manifest. Those with non-Micro Channel machines and VGA video typically have a system ROM at F000-FFFF and a video ROM at C000-C7FF. Those with PS/2s or other Micro Channel machines typically have one ROM at E000-FFFF. Add-on devices, such as some disk controller cards and network cards, may also have ROMs, which you must eXclude as well. A typical QEMM line for a non-Micro Channel machine is: DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=F000-FFFF ... X=C000-C7FF FSTC (again, all on one line). On a PS/2 or most Micro Channel machines, the line will look like this: DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=E000-FFFF FSTC In the above examples, XX is replaced with the interrupt reported in the QEMM error message. Reboot your computer with this CONFIG.SYS. Stealth ROM should work this time. Use your computer for a while, then look at the QEMM/Analysis screen of Manifest. You will see a chart that looks something like this: n=0123 4567 89AB CDEF 0n00 OOOO OOOO OOOO OOOO 1n00 OOOO OOOO OOOO OOOO 2n00 OOOO OOOO OOOO OOOO 3n00 OOOO OOOO OOOO OOOO 4n00 OOOO OOOO OOOO OOOO 5n00 OOOO OOOO OOOO OOOO 6n00 OOOO OOOO OOOO OOOO 7n00 OOOO OOOO OOOO OOOO 8n00 OOOO OOOO OOOO OOOO 9n00 OOOO OOOO OOOO OOOO An00 OOOO OOOO OOOO OOOO Bn00 OOOO OOOO OOOO OOOO Cn00 IIII IIII OOOO OOOO Dn00 OOOO OOOO OOOO OOOO En00 OOOO OOOO OOOO OOOO Fn00 IIII IIII OOII IIIO Consulting the ANALYSIS section of your Manifest or QEMM manual, you will read that an "I" indicates a portion of the address space that HAS NOT been accessed and an "O" indicates a portion of the address space that HAS been accessed. You must eXclude that portion of the address space in the eXcluded ROMs where you now see "O"s. In this example (which presumes that the ROMs were located from C000-C7FF and F000-FFFF), the appropriate eXclude is "X=F800-F9FF", an 8K portion of the address space. This is the portion of the address space where the ROM handler for the interrupt XX resides. Our QEMM line, with appropriate excludes, would read as follows: DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=F800-F9FF PLEASE NOTE: The FSTC parameter is used only during this analysis process and should be removed afterward. Because the last 64 bytes of the First Meg address space (in FFFC-FFFF) is still addressed directly with Stealth ROM, the last 4K piece of the QEMM/Analysis screen will always have an "O" in it, whether an eXclude is appropriate or not. ALSO NOTE: This procedure IS NOT used to find INCLUDES in portions of the address space NOT occupied by Stealthed ROMs. If you wish to experiment with INCLUDES (in order to gain additional High RAM) you must perform a complete analysis as described in the ANALYSIS section of the QEMM or Manifest manual. Q. What if there are no "O"s? A. It is possible that there are no "O"s at all: this is because the ROM handler for interrupt XX has been replaced by a new interrupt handler and the one in the ROM is not being accessed at all. No eXclude is necessary in this case. Q. What are the known uses for XSTI? A. There are several known instances of a need for XSTI. In many cases, these parameters will be found automatically by QEMM INVISIBLE NETWORK: If you use the boot ROM on the Invisible Network cards, it loads 32K of code into the top of the conventional memory address space, and grabs interrupt 13. A much better solution than to use XSTI=13 and the appropriate eXclude is to disable the ROM on the network card and load IS2BIOS instead. This will give you 32K more conventional memory (since IS2BIOS can be loaded high), and you will not have the network card's ROM breaking up your high address space. MS-DOS 5 ON SOME ZENITH MACHINES: XSTI=18 and the appropriate eXclude is necessary to print on some Zenith machines. This is due to an obscure method used only in some Zenith BIOSes. A Zenith version of DOS 5 may not have this problem. WORDSTAR 2000 version 1.01: XSTI=15 and the appropriate eXclude is necessary. This is due to an ancient method of jumping directly to the code that an interrupt vector points to. This version of Wordstar 2000 was written in 1985. Newer versions may not have this problem. VIDEO ACCELERATOR DRIVERS: SPEED_UP.SYS is a driver that comes with the Orchid Prodesigner video card. It makes a copy of the video ROM in RAM in order to speed up your video. If it is loaded after QEMM on a system with Stealth ROM enabled, it refuses to load, complaining that someone else has taken Interrupt 10. If loaded before QEMM on the same system, Stealth ROM will be disabled because QEMM cannot find the ROM handler for Interrupt 10. You can solve both of these problems with XSTI=10. No exclusion is necessary because the video ROM is no longer being used. Speed_up.sys can then be loaded after QEMM and (and can be loaded into upper memory). However, we strongly recommend that you NOT load SPEED_UP.SYS, RAMBIOS.SYS, FASTBIOS.SYS, or any similar driver. Using SPEED-UP.SYS costs you 36K of memory. Instead use QEMM's ROM parameter, producing the SAME effect but using NO address space between 0-1024K. Technical Background ==================== All you need to know to use the XSTI parameter is contained above. If you REALLY want to understand what you are doing, keep reading. Otherwise, go sit out on the back porch and watch the sun set. Q. What does Stealth ROM do to interrupts? A. The Stealth ROM feature of QEMM allows you to map High RAM over ROMs by intercepting the interrupts that point into those ROMs and restoring the ROM into the Page Frame when the interrupt comes in, allowing the ROM's code to be run from the Page Frame. QEMM must divert all interrupts that point into a ROM it Stealths. Otherwise, when an undiverted interrupt comes in, control will pass to whatever QEMM has mapped into the High RAM in that portion of address space, rather than to the ROM that originally resided there. Q. In what cases might QEMM not find an interrupt handler? A. If a program you have loaded before QEMM or a ROM (all ROMs load before the CONFIG.SYS) loads an interrupt handler into RAM, then, when QEMM loads, QEMM will find this interrupt's handler not pointing into a ROM. An interrupt handler pointing into RAM cannot be Stealthed. If a device driver diverts this interrupt, you can load it after QEMM. If a ROM diverts this interrupt into RAM, you should see if there is a way to reconfigure the ROM so that it does not. On the INVISIBLE NETWORK, for instance, it is possible to reconfigure the network card (by means of a jumper) so that the ROM is no longer active and network services are provided by a program. In other cases, there may be a configuration program that performs this service. If you cannot reconfigure the ROM to stop diverting this interrupt, then QEMM must be told not to try to Stealth this interrupt. This is what XSTI=XX does. Since the new interrupt handler may eventually call the ROM's interrupt handler, the ROM's interrupt handler for this interrupt may have to be left in place. This is done by eXcluding the portion of the address space where the ROM's handler for this interrupt resides. When you eXclude a portion of the address space of a ROM that QEMM Stealths, the underlying code that was formerly there returns. You can get an idea where this interrupt is by looking at the First Meg/ Interrupts screen of Manifest, as it reports the beginning address of this interrupt. The acid test is to do an ANALYSIS with all the ROMs eXcluded, which will report what portion of the ROM's address space is being addressed directly. Typically, only an 8K eXclude is needed. If the handler for the target interrupt is being replaced entirely by the new interrupt handler, then the ROM's interrupt handler is never called. In this case, no eXclude is necessary. To be sure of this, you should still run an Analysis. (See the ANALYSIS section of your Manifest or QEMM manual.) Q. What if some other program complains about Stealth ROM's interrupt diversion? A. Some programs, when they load, check to see where the interrupt handlers they expect to use point. If an interrupt handler they expect to use is not pointing into a ROM, they think that an interrupt they wish to manage is already used by another program, and incorrectly assume that there is a conflict. Such programs will see Stealthed interrupts pointing into QEMM's code, rather than ROM, and may refuse to run. If such a program cannot be configured to ignore QEMM's diversion of the interrupt in question, then this interrupt must be XSTIed and the appropriate eXclude found, by the means described above. Some programs make a copy of the video ROM in RAM, and divert interrupt 10 (the video interrupt) into this new location for the video ROM's code. Such programs (RAMBIOS.SYS, FASTBIOS.SYS, RAPIDBIO.SYS are some examples) may refuse to load if interrupt 10 has been diverted. The best solution to this problem is to instead use QEMM's ROM= parameter, which instructs QEMM to perform this same service without using any addresses in the first megabyte of address space. If you wish to use such a program anyway, and it has the above complaint, then you must use XSTI=10. No eXclude is necessary, because such drivers usurp the video ROM entirely and INT 10 is never called again. Q. What is FSTC? A. The purpose of the FSTC parameter is to make the ANALYSIS procedure accurate. When QEMM Stealths a ROM, certain tables have to be stored by QEMM in its own data area. For a video ROM, this table occupies 12K; for a disk ROM, this table occupies 0.1K (If you have no explicit disk ROM, this table is in the system ROM.) When a ROM is being Stealthed, but the address in which the ROM resides is eXcluded, as with X=C000-C7FF, then QEMM won't need to make copies of these tables in its own data area. QEMM will automatically save memory by NOT making copies of the tables. This means that when you do eXclude the portion(s) of the ROM where these tables are stored, the ROM will be accessed directly. (This only holds true when you have used an eXclude.) This will cause Analysis to report that a portion of the address space is OK (when eXcluded) even though it would not be accessed directly were it not eXcluded. FSTC (FORCESTEALTHTABLECOPY) forces QEMM to make copies of these tables so that inappropriate eXcludes are not recommended for the above reason. FSTC should only be used when you are testing a portion of a ROM's address space for direct access by eXcluding the whole ROM. It is not an appropriate parameter for a final configuration. Summary ======= The XSTI parameter is rarely needed. If you are loading any driver OTHER THAN QEMM 7.0's DOSDATA.SYS before QEMM in your CONFIG.SYS file, move QEMM above this driver. This step alone may solve the problem without the use of XSTI. If you decide to use XSTI, you MUST determine the appropriate eXclude that will return the ROM code for handling the XSTIed interrupt to the address space it formerly occupied, because QEMM will no longer restore the ROM's code for the interrupt to the Page Frame and divert the interrupt there when it comes in. ****************************************************************** * Trademarks are property of their respective owners. * * This and other technical notes may be available in updated * * forms through Quarterdeck's standard support channels. * * Copyright (C) 1995 Quarterdeck Corporation * ******************** E N D O F F I L E ***********************