THE PIT V2.05 - Bug fixes
                         ~~~~~~~~~~~~~~~~~~~~~~~~~

This is THE PIT v2.05.

This version was created to fix several bugs:

-------V2.0b--------------------------------------------------------------------
1) THE PIT V2.0 would not run correctly with DESQVIEW. V2.01 should fix these
   errors.

2) DOOR.SYS was originally read in from a copy created by TELEGARD BBS. The
   DOOR.SYS created by this BBS was in fact 180 bytes smaller than what should
   have been created. We have adjusted the read in of DOOR.SYS to match that
   created by WILDCAT.

3) A bug existed when a player possessed the CRYSTAL LENS and fought a blindness
   causing monster (Rainbow Dragon). The player would end up with more health
   upon killing the next monster than should have been allowed. It was a wicked
   result from a simple typo, but fixed nonetheless.

-------V2.01--------------------------------------------------------------------

1) The Pit V2.0b and earlier had a bug in the date function. Everytime a 2 digit
   date occurs (Ex. Changes from 9/31/91 to 10/1/91) players would find
   themselves locked out of the game.

-------V2.02--------------------------------------------------------------------

1) THE PIT V2.01 and earlier would only run on COM 1 if the SysOp was running
   GT POWER BBS. The SYSOP could edit the com port to the correct setting, but
   the game itself would always default it to COM 1.

-------V2.03--------------------------------------------------------------------

1) Discovered that PCBOARD.SYS was opened in "TEXT" mode instead of "BINARY"
   mode. This resulted in PCBOARD.SYS being read in correctly about 75% of the
   time. Other times users found themselves locked out of the game. It also
   had odd effects on the data being passed to the game. This should cure alot
   of the PCBOARD SysOps blues with THE PIT.

-------V2.04--------------------------------------------------------------------

1) Borlands TC, TC++, and BC++ programs had a flukie error in its EMUL.LIB
   (Math Emulation Library). It toggled a bit in LOW DOS memory (Why they do
   this I have no idea). But after speaking with BORLAND for about 5-6 hours we
   finally came up with a PATCH for it.

   This bug caused DESQVIEW to bomb anytime the PROTECTION LEVEL was set to a
   value greater than 0.

2) COM ROUTINES fixed. A reentrancy error in our com port interrupt code would
   cause errors on some modems. It never really affected us until we wrote the
   TERMS (EGA & ANSI). The speedy constant transfer of information with the
   terms resulted in lockups, and TIMEOUTS.

   We rewrote the routines and they should work alot better. I noticed that TIME
   OUTS on the TERMS immediately stopped occurring.

   Both the EGA & ANSI terms were rewritten to include these fixes as well.

3) SYSOP vs. PLAYER fixed. Found out that when the SYSOP vs. Player mode was
   turned off (By pressing F1) while in the middle of battle it would cause the
   game to hang.

4) DESQVIEW TIME SLICING. We added some desqview calls to our program that will
   make THE PIT give up time slices when it is in a WAIT STATE (Waiting for a
   keypress ect.).

5) /NOBAUD option added to command line. Some of the newer US ROBOTICS HST
   DUAL STANDARD modems, and the new HAYES ULTRAS no longer lock baud rates.
   Unfortunately, the modems use a free form baud rate adjustment approach. This
   does not allow the BBS to accurately know what baud rate the modem is
   actually at in any given instance. Thus the BBS will pass a DOOR FILE to our
   game that does not have a correct baud rate in it.

   Setting the baud rate will not allow some users to use THE PIT. Mostly 2400
   baud modems since they are not using a compression protocol to control the
   flow of information.

   If however we leave the baud setting alone the game will work fine. So the
   "/NOBAUD" command parameter make the game skip setting the baud rate.


   USAGE: PIT /NOBAUD

-------V2.05--------------------------------------------------------------------

1) COM ROUTINES FIXED AGAIN. Well once again our com routines required a little
   tinkering. Due to a time out in our character send routines the remote user
   would occasionally receive alot of SCREEN GARBAGE. This error seems to occur
   on high speed systems with a low speed caller (Thats why we missed
   it ourselves), but now we are running at near 100% again.

2) CHAT MODE ERROR. When alot of chatting occurred in the game, some pointers
   would get corrupted and end up locking the system up. This is more a result
   of a change in compilers than coding problems. But fixed nonetheless.

-------------------------------------------------------------------------------