Yet another LBAcache DEVEL release: Auto-RAMsizing / percent fixed

Hi all, at:
http://www.coli.uni-sb.de/~eric/stuff/soft/ lbacache-12nov02.zip
you now have yet another release of LBAcache devel.

Featured updates:
- see 10nov02 version
- see 11nov02 version
- local stack is now always enabled (300 bytes), option STAK is ignored
  but still allowed for compatibility
- If DOS version is 5 or newer, LBAcache will automatically make its DOS
  memory footprint smaller until it fits the available RAM when it detects
  that it would not do normally. It will then print a bunch of "..." - the
  more dots, the more XMS RAM stays unused (the XMS footprint will stay the
  same size: Only LBAcache will no longer USE the remaining part of the
  allocated XMS, because it had no room to allocate the needed tables in DOS
  RAM).
  You are supposed to reduce the BUF nn argument nn value until no dots are
  printed anymore. Otherwise, you allocate more XMS than you actually use.
  This is especially useful when you use LOADHI with LBAcache, or DEVICEHIGH.
  Be warned: If DOS version is < 5, the controls are disabled even for the
  LOADHI case. In theory, I could do the controls in that case, but I doubt
  that anybody uses LOADHI on DOS < 5 nowadays. It is impossible to do the
  controls for DEVICEHIGH if the DOS version is < 5.
- I have removed the ROUNDING of the human readable "percentage of hits"
  display. Now it is less accurate but at least it works.
- As said, memory reallocation now finally works: You can do "LBAcache STOP"
  in the "several instances" case without crashing now... The instances are
  resized to minimum size then but not completely removed. When LBAcache
  instances are in the right order in RAM, you can even completely remove
  several LBAcache.COM instances (THIS did work all the time, only resizing
  was broken). LBAcache always succeeds in releasing the used XMS, but it does
  NOT release the DOS memory allocated by LBAcache.SYS instances (I believe
  this would be impossible!?)
- Apart from some fine-tuning of the screen output, no other important new
  features yet. Still working on an efficient XMS slot management, the
  current version performs much worse than I like it to do. But I have some
  ideas on how to improve FINDBIN and NEWBIN in BINSEL.ASM alread :-).

PS: I am still looking for suggestions for things like screensavers, games,
other fun stuff that I could include in MetaKern. For those that want a
menu that offers: FreeDOS, A:, B: and C: but that do not have another DOS
installed in parallel to FreeDOS (MetaKern normally shows TWO menu items
for DOS, as this is what it was made for in the first place. It is a menu
that allows you to boot either of TWO DOS versions on the same disk).
The "menu entry filling game/..." should fit 0.5k. If it fits 20k after
compiling in C:, we can think about making a 0.5k version in ASM :-)). Okay,
with Turbo C, I should say 10k or less. Get MetaKern from the same directory
as LBAcache, mentioned above.

Eric

PPS: LBAcache.com takes about 4.0k of RAM plus 0.5k for each 256k of XMS
it uses. You can use "LBACACHE DRV D BUF 42" to cache disk 0x81 (not to
be confused with D - you can also write LBACACHE DRV 1 BUF 42, by the way,
to avoid this ambiguity) and allocate 42*256k = 10.75M of XMS. Default is
to cache all harddisks. Add the FLOP option to cache floppies as well, but
read the readme carefully to learn about the dangers of doing so. You can
use LBACACHE DRV NULL BUF 10 FLOP to allocate 2.5M of XMS and only cache
floppies, no harddisks.