bolton@cg-atla.UUCP (Lee Bolton) (02/01/90)
Hello:
I've recently aquired ;-} a brand new shiny (well, matte putty)
computer. configured as follows:
Manufacturer: Motorola Computer Systems Model #PCP141
(really. no kiddin.)
Mother Board| Micronics 88290036 Rev B
CPU: Intel 80386/16 no cache
Controller: Western Digital Corp. WD1003-WA2 Rev 13
Floppy Drive: Toshiba FDK-82 5.25in. 1.2m HD
Hard Drive: Miniscribe model 3053 44.6MB
I/O card: Track Tenneco (I never heard of them either)
I/O II card: Courier 286 A0029540 REV.2
Memory card: Micronics MB105095 Rev B
(sockets for 2M, 1M installed)
RAM: Hitachi 80ns 256k x 1 static column
OS: Phoenix MSDOS 3.3
BIOS: Phoenix V2.1
Included with the system, was a utilities disk with 3 important
programs on it.
MICEMM4B.SYS a (sic) memory manager.
RAMDRIVE.SYS a disk emulator.
RELOCATE.EXE a ROM to RAM translator.
I have a whole mess of questions about this monster that
neither the dealer nor Motorola Tech Support have been able
to answer.
This is my CONFIG.SYS
shell=c:\bin\command.com c:\bin /e:2048 /p
files=24
buffers=16
device=c:\bin\nansi.sys
device=c:\bin\micemm4b.sys 0 (256) /ERROR
device=c:\bin\ramdrive.sys 256 /a
lastdrive=e
break=on
First, RELOCATE.EXE is supposed to copy BIOS from ROM to RAM.
neat. The little 4 page document is a bit too terse on the
subject. Like it doesn't happen to mention just what exactly
gets moved, or from whence to where. a couple of sentences
mumble about BIOS, EGA BIOS, and/or a 64K frame buffer??
Unfortunately, such incantations are much too techy for
this neophytes ears.
MICEMM4B.SYS is supposed to make the top 384K available as
extended memory, and RAMDRIVE.SYS is supposed to be able to
live there. MICEMM4B.SYS is supposed to take a pile of
parameters. First is a number describing a starting address
as counted in paragraphs from the bottom of what's referred to
as 'discontiguous memory'.
The second parameter is supposed to be the size of the pool to
be managed (in bytes).
I cannot get the ramdisk and the relocated BIOS to co-exist.
No matter how I set up the memory manager, it faults out
with a memory protection error when I invoke the relocator.
It's not unreasonable to think it possible to put BIOS wherever
it has to go and let the ramdisk have the rest is it?
Has anybody, anywhere ever heard of this system or these
routines? Does anyone know what's happening here?
Do there exist tools to accomplish what I want to on this
system?? I would even (horror) !-{ pay for them.
This all comes about because I got a bunch of utilities
that supposedly make MSDOS a bit more palatable to
Unix types like me. The documents for this shell clone advise
that I transplant COMMAND.COM to a ramdisk, as it gets called
a lot. sounds logical. But I don't think it wise to shove
COMMAND.COM into RAM if I have to take BIOS out. sort of like
cutting off a hand to cure a cut finger.
Would anyone like to venture an opinion regarding the relative
throughput of either method? Like, What does it cost to run
BIOS from ROM versus RAM? How much is saved by moving COMMAND.COM
to RAM? I'm sure that these questions have wider scope than
just my little travails here.
If you got this far, Thanks for your time.
--
R. Lee Bolton {uunet!ginosko,decvax,ulowell}!cg-atla!bolton
Agfa Compugraphic Division. (508)-658-5600 X5461| The brain...
200 Ballardvale St. Home voice: (508)-283-7980 | it's....Gone Jim.
Wilmington, Mass. 01887 data: (508)-281-5958 | just...GONE!william.pipher@canremote.uucp (WILLIAM PIPHER) (02/03/90)
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.uucpwilliam.pipher@canremote.uucp (WILLIAM PIPHER) (02/03/90)
********** continued from previous *********
RE: bolton@cg-atla.UUCP (Lee Bolton)
Agfa Compugraphic Division, Wilmington, Mass. USA
bP> Has anybody, anywhere ever heard of this system or these
bP> routines? Does anyone know what's happening here?
bP> Do there exist tools to accomplish what I want to on this
bP> system?? I would even (horror) !-{ pay for them.
Take a look at Quarterdeck's "QEMM 386" memory management utilities.
With a user-base in the 10s of thousands, documentation and technical
help is readily available. They're good, they work very well, they're
easy (only takes a day or two to figure them out :-) and they're under
$100 US. I recommend this as an easier solution to your problems,
although I obviously guarantee absolutely nothing.
bP> that I transplant COMMAND.COM to a ramdisk, as it gets called
bP> a lot. sounds logical. But I don't think it wise to shove
I don't think it's so important unless you're running a floppy-only
system. That's just an opinion. I think the BIOS SHADOWING
(relocation) is very much worth it, although not necessarily with
the utility you are trying to implement it -- sounds like a dog
to me. (No offense meant to my canine friends).
Goodluck. I have no connection with Quarterdeck or QEMM beyond that
of a satisfied customer.
--WmP--
---
~ DeLuxe 1.11a19 #3744 william.pipher@canremote.uucp