Category : Alternate Operating Systems - Quarterdeck DesqView, CP/M, etc
Archive   : QWAUG92.ZIP
Filename : XSTI.TEC
Quarterdeck Technical Bulletin # 233
by Quarterdeck Testing and Compatibility Department
Last revision: June 16, 1992
XSTI
When you boot your computer, do you receive the message "QEMM386: Disabling
Stealth because QEMM could not locate the ROM handler for INT XX."?
If so, one of the following problems exist:
a) You have loaded a driver before QEMM-386 which is grabbing
interrupt XX.
or:
b) A ROM is loading a handler for interrupt XX into RAM.
or:
c) You are using some XTs or PCs which you have upgraded to a 386
with an add-in, like an Intel "Inboard PC."
The solution to problem a) is to load the driver in question after QEMM-
386. If it must be loaded before QEMM-386, load HOOKROM.SYS before this
driver. HOOKROM is a device driver that comes with QEMM-386 that allows QEMM-
386 to find the eventual ROM handler for interrupts that are hooked by drivers
that must be loaded before QEMM-386.
The solution to problem c) is to add the parameters "XSTI=70 XSTI=74
XSTI=75 XSTI=76" to the QEMM386.SYS line of the CONFIG.SYS. A typical QEMM-
386 line in this case will look like:
DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=70 XSTI=74 XSTI=75 XSTI=76
The solution to problem b) is to 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 (see: "How Do I Find
the 'Appropriate Exclude'" on the following pages) to this same line in order
to keep QEMM-386 from mapping over the portion of the address space where the
ROM handler for interrupt XX resides. 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 below).
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.
HOW DO I FIND THE "APPROPRIATE EXCLUDE?"
You find the appropriate eXclude by excluding all the address space
occupied by ROMs, using the parameter FSTC, and doing an Analysis. The first
thing you need to do is locate all your ROMs. You can do this by looking at
the First Meg/Overview screen of Manifest. Those with non-Microchannel
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 Microchannel 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-386 line for a non-Microchannel machine is:
DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=F000-FFFF X=C000-C7FF FSTC
On a PS/2 or most Microchannel machines, this line will look like:
DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=E000-FFFF FSTC
where XX is the interrupt reported in the QEMM-386 error message.
Reboot your computer with this CONFIG.SYS. Stealth should work this
time. Use your computer for a while, then look at the QEMM-386/Analysis
screen of Manifest. You will see something like:
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
Consult the Manifest manual( under "QEMM-386, analysis of" in the index)
or QEMM-386 manual (in the "analysis" section of the "QEMM.COM" chapter),
where it will tell you that "I" indicates that this portion of the address
space has not been accessed, and that "O" indicates that this portion of the
address space has been accessed. The appropriate eXclude is for that portion
of the address space in the eXcluded ROMs where there are "O"s. In this
example (which presumes that the ROMs were in 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. The resultant QEMM- 386 line is:
DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=F800-F9FF
The FSTC parameter is used only during this analysis process; it should be
removed afterwards.
Because the last 64 bytes of the First Meg address space (in FFFC-FFFF)
is still addressed directly with Stealth, the last 4K piece of the QEMM-
386/Analysis screen will always have an "O" in it, whether an eXclude is
appropriate or not.
NOTE: This procedure isn't used to find INCLUDES in portions of the
address space NOT occupied by Stealthed ROMs. If you wish to experiment with
includes, then only a complete analysis, (as described in the "Analysis"
section of the "QEMM.COM" chapter of the QEMM-386 manual) will locate other
areas in the address space which can be included.
WHAT IF THERE ARE NO "O"S?
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.
TECHNICAL BACKGROUND
All you need to know to use the XSTI parameter is contained above. If
you wish to understand what you are doing, this section provides a brief
explanation.
WHAT DOES STEALTH DO TO INTERRUPTS?
The Stealth feature of QEMM-386 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-386 must divert all interrupts that point into
a ROM it Stealths. Otherwise, when an undiverted interrupt comes in, control
will pass to whatever QEMM-386 has mapped into the High RAM in that portion of
address space, rather than the ROM that originally resided there.
WHY QEMM-386 MAY NOT FIND AN INTERRUPT HANDLER AND WHAT MUST BE DONE.
If a program you have loaded before QEMM-386 or ROM (all ROMs load before
the CONFIG.SYS) loads an interrupt handler into RAM, then, when QEMM-386
loads, QEMM-386 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-386. 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, 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-386 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 QEMM-386 Stealths, the underlying code
there formerly returns.
You can get an idea where this interrupt is by looking at the First
Meg/Interrupts screen of Manifest: 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 the QEMM.COM chapter of the QEMM-386 manual.)
WHAT IF SOME OTHER PROGRAM COMPLAINS ABOUT STEALTH'S INTERRUPT DIVERSION?
Some programs, when they load, check 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-
386's code, not ROM, and may refuse to run. If such a program cannot be
configured to ignore QEMM-386's diversion of the interrupt in question, then
this interrupt must be XSTIed and the appropriate eXclude found, by the means
described above.
There is a class of programs that 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 use the ROM=C000-C7FF (or ROM=XXXX-YYYY,
wherever the video ROM resides) feature of QEMM-386 to have QEMM-386 perform
this same service without using any of the First Meg memory at all. 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.
STEALTH ON A PC OR XT
In addition to Stealthing all interrupts that point into Stealthed ROMs,
QEMM-386 tries to Stealth certain interrupts that traditionally point into
ROMs. On a PC or XT, there are only 8 hardware interrupts, while on a 286 or
386, there are 16. QEMM-386 tries to Stealth interrupts 70, 74, 75, and 76,
four of the software interrupts associated with the additional 8 hardware
interrupts of a 286 or 386. There are SOME (by no means all) PCs and XTs
whose ROMs incorrectly report (Interrupt 15, function C0, byte 5, bit 6) that
their machines have 16 hardware interrupts. QEMM-386 tries to Stealth the
above interrupts inappropriately on such machines, and must be told not to.
Because there are no interrupt handlers in ROM for these interrupts on a PC or
XT, no eXclude is necessary.
WHAT IS FSTC?
The purpose of the FSTC parameter is to make the Analysis procedure
accurate.
When QEMM-386 Stealths a ROM, certain tables have to be stored by QEMM-
386 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-386 won't
need to make copies of these tables in its own data area. QEMM-386 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-386 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 ROMs
address space for direct access by eXcluding the whole ROM. It is not an
appropriate parameter for a final configuration.
KNOWN USES FOR XSTI
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.
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 an interrupt vector points
to. This version of Wordstar 2000 was written in 1985. Newer versions
may not have this problem.
SUMMARY
The XSTI parameter is a parameter for which only the rare computer has a
use. Those who are loading QEMM-386 first in their CONFIG.SYS should only
need it in those cases mentioned above. Those not loading QEMM-386 first
should simply move QEMM-386 to the first line, since this may solve the
problem without even using XSTI. If a user decides to use XSTI, he or she
must look for the appropriate eXclude to return the ROM code for handling the
XSTIed interrupt to the address space it formerly occupied, because QEMM-386
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 technical note may be copied and distributed freely as long as it*
*is distributed in its entirety and it is not distributed for profit. *
* Copyright (C) 1992 by Quarterdeck Office Systems *
************************ E N D O F F I L E *************************
Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!
This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.
But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/