🚀 go-pugleaf

bolton@cg-atla.UUCP (Lee Bolton) 
bP>Orga: Agfa Compugraphic Division, Wilmington, Mass. USA

asks:

bP>        Included with the system, was a utilities disk with 3
bP>important
bP>        programs on it.

bP>        MICEMM4B.SYS    a (sic) memory manager.
bP>        RAMDRIVE.SYS    a disk emulator.
bP>        RELOCATE.EXE    a ROM to RAM translator.

bP>            device=c:\bin\micemm4b.sys 0 (256) /ERROR
bP>            device=c:\bin\ramdrive.sys 256 /a  << --- what is 'a'?

bP>        First, RELOCATE.EXE is supposed to copy BIOS from ROM to RAM.
bP>        neat. The little 4 page document is a bit too terse on the
bP>        subject. Like it doesn't happen to mention just what exactly
bP>        gets moved, or from whence to where. a couple of sentences
bP>        mumble about BIOS, EGA BIOS, and/or a 64K frame buffer??

Normally with a 386, the ROM bios can be copied to some address 
above  1 meg in extended memory.  Then, the superior memory 
management of the 386 is used so that the bios now in RAM appears 
to the system to be where it always is.  The effect of this is 
a) there will be less extended memory available for other tasks and
b) your computer could run faster.  Mine does. 

Usually this is set-up  defined in extended cmos registers, 
rather than by software, although Desqview QEMM uses the software
approach, too.  See if you can implement this Bios SHADOWING through
your system set-up configuration.


bP>        MICEMM4B.SYS is supposed to make the top 384K available as
bP>        extended memory.

I presume that you mean that MICEMM4B can place an expanded memory
page frame into some "space" between 640K and 1 meg.   If my 
presumption is correct, and if the driver is too stupid to find
its own address to map it's frame, you'll have to help.  Do you
have NORTON SI? (or similar utility)?  This is what mine says:

DOS reports 703 K-bytes of memory:

A search for active memory finds:
   640 K-bytes main memory     (at hex 0000-A000)   <<< space in use
   128 K-bytes display memory  (at hex A000-C000)   <<< space in use
    32 K-bytes extra memory    (at hex C000-C800)   <<< too small 
    84 K-bytes extra memory    (at hex CF00-E400)   <<< O.K. put page
   960 K-bytes expanded memory                          here CF00-DF00

ROM-BIOS Extensions are found at hex paragraphs: C800 CB80 CC00
                                                 
bP>        live there. MICEMM4B.SYS is supposed to take a pile of
bP>        parameters. First is a number describing a starting address
bP>        as counted in paragraphs from the bottom of what's referred to
bP>        as 'discontiguous memory'.

I have no idea what they might be asking for (number of paragraphs from
A000:0?  from B000:0?  from C000:0? who knows?).  An intelligent 
response would be to use CF00 (as per above example, or whatever), and
hope that that's what they meant.

bP>        The second parameter is supposed to be the size of the pool to
bP>        be managed (in bytes).

Presumably this is asking for the total size of extended memory to be
allocated to the expanded driver (I'm mind-reading again).  This will
be size of extended memory minus size of shadowed rom minus size of 
ram drive minus 10000 hex for the EMS page.

bP>        I cannot get the ramdisk and the relocated BIOS to co-exist.
bP>        No matter how I set up the memory manager, it faults out
bP>        with a memory protection error when I invoke the relocator.
bP>        It's not unreasonable to think it possible to put BIOS
bP>        wherever it has to go and let the ramdisk have the rest is it?

Should be OK.  I would expect that the ROM shadowing should be enabled
first, then the expanded memory driver, then finally the Ramdrive.  Try
specifying /E as an arg to ramdrive.sys, not '/a'.  This will 
place it up in  extended memory out of the way:

device=c:\bin\ramdrive.sys 20 128 /E

******** continued in next message ******************
---
 ~ DeLuxe 1.11a19 #3744  william.pipher@canremote.uucp