🚀 go-pugleaf

In article <1990Sep1.090154.4095@EE.Surrey.Ac.UK>, chung@surrey.ac.uk (L N Chung) writes:
> In article <XPKPTCP@dri.com> frotz@dri.com writes:
>>
>>It uses what memory is available between 640K and 1M (actually
>>the first segment above 1M) to load itself, drivers, system
>>structures and TSRs. 
> 
> Can it load everything above the 1M mark? My problem is that the Everex card
> can only fill memory extended memory starting from 1M. In fact we have now
> got 1M extended memory and 3M expanded memory on the card. However, there is
> *no* memory between 640K and 1M. Will I be able to get more than 600K out of
> the DR-DOS?
> 
Yes, if you have a 386. Possibly otherwise. With a 2Mb 386 and Hercules
graphics card, I get about 800Kb available, with a VGA I get about 620Kb
available (with "reasonable" balance between speed and memory size).

On a 386 with more than 1Mb of RAM, it can map memory down into any gaps in the
640K-1Mb region. Not all software likes going there, of course, but most will.
Some 286 chip sets also let you do this, but none that I have tried yet. 

Even if you only have a common-or-garden-variety 286, with more than 640Kb of
RAM, DR-DOS can use some of the first 64Kb above 1Mb, by saying it is segment
number FFFF (i.e. within the first 1Mb area), but it only loads about 37Kb of
its own kernel there, not your programs (still, you do get a bit more memory
left at the bottom then). A few old AT motherboards seem to loose the extra
384Kb, though (so if you can't use it for Extended, you can't shove the kernel
there either). Also, some 1Mb 386's seem to insist such RAM can be only be used
for some purposes, limiting what DR-DOS can do with it.

And on old 8088 machines, DR-DOS still usually gives you more memory than MS
DOS 3.30, partly because it is more code-efficient, it seems, and partly
because you have a lot of control over memory use. It will make better use of
EMS (and extended) than DOS 3.30, but about the same as DOS 4. 

> If we use window3, and load himem.sys, will DR-DOS stop loading drivers, etc
> to memory above 640K?
>                
You can choose in config.sys whether device drivers are loaded "high" or not,
and you can specify whether programs (e.g. TSR's) are to be loaded high, and
whether upper memory should be turned on or off during execution. There is a
special note mentioning using DR-DOS with windows3 and a few other 386-specific
programs that comes with the software (but I haven't tried it yet).

> "shadow ram"...
Shadow RAM takes up the same memory space as the ROM it copies and replaces. It
seems a good idea, but it is not always worthwhile shadowing video rom, since
some loadable drivers bypass that code anyway. 

All in all, DR-DOS 5.0 seems a very nice product, especially if you have a 386
with a bit of memory you are wondering how to put to best use. The user
interface is very good, well, compared with what has come before, from the
installation process to the command interpreter and on-line help (why didn't
they do that before??). But there are some limitations (really minor, but
someone's got to mention them). [Please read these understanding that, on
balance, DR-DOS is easily the nicest little o/s for a PC you can get, IMHO]

(1) You don't get a great deal extra below-640K ram on a "normal" (non-C&T)
286, only 37K plus what you get from having less buffers and more
memory-efficient FASTOPEN code, etc (say, about 60Kb more than DOS3.3). Still,
that's important to some people who can't otherwise install a network driver
and still run some big DTP software, etc.

(2) Some software doesn't like going up above 640K, e.g. DECNET DOS can have
problems if particular modules (like DNP) are loaded high, and MARK and
RELEASE can give problems unless high memory is turned off. That's not really
DR-DOS's fault, though. The sort of problems are assumptions in old software
that the world ends at 640K, and that if a vector points above 640K it must
still be pointing to BIOS ROM. The system has a too-common habit of freezing
until you work out what can and cannot work; again, that might not be DR's
fault.

(3) The screen-oriented editor is much nicer than EDLIN, and very similar to
Wordstar and Turbo's interactive compiler editors, but it lacks decent global
search and replace options, and defineable keys (F1 is "Help", but no other
function key is used). 

(4) The system call that returns the capacity of a disk fails if that disk is
JOINed.

(5) Trying to do: DEL *ABC*.* returns an error message, which is better than
MS/PC-DOS (everyone know that bug? it does a DEL *.*), but it would have been
better to fix the wildcard matching problem, since some software assumes the
system calls to find a file matching *something* will return everything.

(6) Their disk caching software slows down access times (it sounds like there
are too many disk seeks being done for each access), although in other ways the
caching system is very good (you keep good transfer rates with 1:1 controllers,
and good software compatibility, and Norton's SI disk test returns very good
performance figures).

(7) Not all commands have on-line help (e.g. COPY and other internal commands).

(8) The FILELINK program doesn't handle modems, and you have to keep going
back into the program after each command, but is still a valuable tool.

There may be a problem with the way it gets the date and time from the CMOS
clock, but it might be my hardware - if anyone notices any strange behaviour,
I'd be interested to know.
 
Mark Aitchison, Physics, University of Canterbury, New Zealand.