Being STEALTHy with QEMM

[clark@tomcat.gsfc.nasa.gov (Tom Clark -- W3IWI)]

For those of you running NOS under DesqView/QEMM, who have upgraded to
DV 2.4x and QEMM 6.0x (I'm currently using 2.42 & 6.02), and who are
using an Ethernet controller like the 3C503 -- you may be interested
in what I have found.

In QEMM 6.0x, QuarterDeck has added the new "stealth" feature to try to
place more RAM in the A000:0 to FFFF:F block. I have spent an agonizing
couple of weeks trying to make it be stable on tomcat.

Tomcat is a 386-33 that uses a motherboard with the C&T "OPTI" chipset
to manage the cache. The BIOS is a 1989 AMI version which has hooks to
configure both te normal CMOS RAM and an XCMOS area that diddles parameters
for the C&T OPTI chips. During the course of trying to get it to work
reliably, I think I have diddled each and every XCMOS bit!

Here is what I found:

(1) My Paradise VGA card totally barfs if I set the OPTI XCMOS area to try
to shadow the video area. The main shadow and "256k extended" shadow
works fine.

(2) The only way I have ever found to get the Clarkson 3C503 driver to work
with NOS in DV is to load the driver in a DV window with a batch file that
brings up the driver and then NOS. The driver cannot be loaded in native DOS
either high or low. In my case I have the 3C503 board RAM at DC00-DFFF and
use the IRQ5 interrupt. I found it necessary to declare (in the OPTI XCMOS
setup) that the 64k block D000-DFFF was not to be cached.

Following that, I founf the following CONFIG.SYS to work reliably to load
QEMM 6.02:

   DEVICE=C:\QEMM\QEMM386.SYS R:2 RAM ROM ARAM=DC00-DFFF
          X=B000-B0FF X=FD00-FEFF XSTI=0D ST:F

Obviously the ARAM tells QEMM to ignore the 3C503 RAM area. The two X
exclude areas seem to make the system be more stable, but I won't vouch
for them being mandatory. I found that the ST:F Frame version was more
reliable (although on my 386 at home, ST:M works fine and makes for a
64k larger high memory space).

(3) The "magic" seems to be the XSTI=0D obscure statement. Here is what
QuarterDeck says about XSTI:

> EXCLUDESTEALTHINT=xx (XSTI)
>     This parameter directs QEMM-386 not to
>     grab the software interrupt xx (specified
>     in hexadecimal) when the Stealth
>     parameters are in effect.  It is intended
>     to be used if you have a program that
>     refuses to start up if it detects that a
>     particular interrupt is not pointing to
>     the system BIOS or to 0000:0000.  The
>     XSTI parameter will cause system failures
>     if the specified interrupt is ever called
>     and eventually executes at the BIOS
>     level, as QEMM-386 has given up managing
>     the interrupt.  This parameter is
>     unlikely to be useful in any but the most
>     extreme situations.

Why is it 0D? If you look at MessDOS documentation [or easier still
run MFT (Manifest) and look at (F)irst Meg (I)nterrupts (F3)], you will
find that INT 0D = IRQ 5 (neither of which have anything to do with the
interrupt vector number which you assign to the packet driver).

Without the XSTI=0D in the QEMM load statement, that interrupt is "owned"
by QEMM/DV; including the XSTI statement seems to mean that QEMM/DV do
nothing to interrupt the hardware interrupt from the ethernet controller.
Despite the stern warnings in the above quote, it works!

Voila! All the flaky problems went away and the system seems (so far!
knock on wood!) as solid as a rock.

With XDV loading DV high, MessDOS 5.0 loaded low, FILES and BUFFERS
high and a disk cache in Extended memory loaded high, I end up with
570+k DV windows. A timing test on an FTP transfer to one of my Unix
machines had NOS doing PUTs at 90 kbytes/sec and GETs at 30 kbytes/sec
with anonymous ftp users logged onto tomcat.

73, Tom