Mail Archives: opendos/2000/12/02/04:25:03
----- Original Message -----
From: "Matthias Paul" <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
To: <opendos AT delorie DOT com>
Sent: Friday, December 01, 2000 10:51 AM
Subject: Re: Optimizing CONFIG.SYS...
> On Fri, 01 Dec 2000 Patrick Moran wrote:
>
> > Why do you need those buffers? There are caching programs
> > available for CD.
>
> I have just been asked in private conversation, which CD caches
> are avialable. I'm probably not up to date, as I have only tested
> CD-Quick so far. Can you recommend any?
No I can't, I have never used one. I just don't see any reason to speed up a
CDROM drive. If it is for some game, I just fully install the game on the
HD, then I save the save games and delete the game if I get tired of it, I
can always install it later and pick up where I left off. If I install
WINDOZE, I just copy the files from the CD to a temp directory on the HD and
install from the HD. I just cannot see wasting memory and resources for a
slow CDROM just to make it a little faster. I have a 4X and my brother has a
24X. I really do not notice any difference.
> > If those things actually spun at 24X or 36X they would probably
> > fly right out of the drive!
>
> In the April issue of the c't magazine there was an article where
> they reported about CDs that broke in 36x and 40x drives due to
> the high centrifugal forces. I'm still not completely sure if this
> was meant seriously or as an 1st April joke... ;-) But anyway,
> from the noise the produce I can image almost anything happen... ;->
>
> > What environment are you talking about then? The 7K?
> No, the 112 byte environment. The 7 Kb is the size of the
> resident driver when it uses DPMS.
>
> > According to the LIM 4.0 specifications, those 4 16K blocks DO NOT have
to
> > be contiguous. They can reside in different areas, but I have yet to see
an
> > EMM386 do that. Also you are not restricted to just 64K frame, you can
use
> > as many 16K chunks as you want. It is possible to have as large as a
256K
> > frame located in conventional memory.
> EMS 3.xx works through a 64 Kb EMS frame page with 4x16 Kb windows in
> there, but under EMS 4.00 you can map in EMS outside of the frame,
> even below the A000h address (this is called memory backfilling).
> This technique derived from EEMS, that's true.
> Even the AST machine must at least have 128 Kb or 256 Kb of
> conventional memory, otherwise DOS cannot boot (DR-DOS 7.03 needs
> 128 Kb to boot). The remainder of the memory can be backfilled
Yes that is true, but the AST had no hardwired conventional memory like all
other computers have. They used plug-in modules (these were not simms, they
were little plug-in cards of someting 2"x3" if I remeber correctly.) They
had NO memory of the motherboard at all and ALL of the memory could be
mapped completely according to the user's taste. Thus once you got the
system booted you could map the memory anyway you wantd. For some unknown
reason, no one else ever bothered to catch on to this great idea (GREEEED
and EGOS????) They did this on thier 286 machines. I think we had a couple
of 386SX which also did this.
BTW talking about 386SX, I have a 386SX mother board that I used for a few
years. It can use up to 32MB installed on the MB, yet the 386SX cpu can only
address 16MB. Actually if the MB had 8 more simm slots it could address up
to 64MB. This is because the chipset used in this particular board had it's
own built-in memory manager that allows it to do this.
When Lotus, Intel, and MS got together to improve the LIM 3.2, they
basically used AST's EEMS, however, they never consulted AST about (Hmmmm
sounds like a typical Gates ploy of stealing someone elses ideas) using
their EEMS. When they got done they had LIM 4.0 but left out a couple of
crcial things that were in the AST EEMS.
> using EEMS or EMS 4. I think, Windows 3.xx is almost the only
> application to make use of that. As far as I know the MS-DOS
> EMM386 also supports this, while the DR-DOS EMM386 does not
> (at least it lacks these command line options). I'm not
I was under the impression that the hardware also had to have this feature
implemented to be able to use it. There were many expansion memory board
available for the 64K and 256K PC mother boards, but not all were capable of
backfill. I remeber seeing 1MB and 2MB expansion boards and some could
backfill and some could not.
Another example is my 286 mother board, it can hold up to 1MB of memory,
however, if I used 1MB of memory on it (which I did and could run WINDOZE
2.x and 3.x on it) 512K was conventional and 512 was extended. If I made the
second bank of memory 128K I could get 640K conventional. I could not
backfill to 640K conventional when I used 512K in the second bank of memory.
I had to use 512K conventional and 512K extended. I did have an HMA driver
that I found that would work with MSDOS 5.0 that would use this memory and I
could run WINDOZE on it which everyone said I was nuts, that you could not
run WINDOZE on 1MB. I could because 512K was extended memory! I could not do
much with it, just run small apps, but it did work.
Of course I am a hacker and if someone says it can't be done, I'll do
it!<BG>
> sure if EMS 4 still requires a FRAME page or if this is optional
> (for backward compatibility). Anyone?
It does require a page frame and needs t be in UMB, but you can add up to 32
more pages in conventional memory if you have enough registers to do it. In
fact you can have up to 64 such registers, but cannot swap out the lower
256K.
I am checking up on XMS memory now, in the book "DOS beyond 640K" It does
refer to XMS memory in it but was not listed in the index. It is extended
memory and from what I have read so far, it is NOT swap memory, it is in
fact extended memory. But I need to poke around the book some more about it.
I think some of the comments made about XMS is untrue. It should be much
faster than EMS because there is no window to swap memory through I believe
that Task Manager is using DPMS through the extended memory created by XMS.
What I can't figure out is why do you even need a memory manager at all for
extended memory. It already exist, all you have to do is use it. DOS,
however, is so stupid, it does not know about it because DOS is not a 32 bit
OS and has never been upgraded beyond the 1MB limitation, so you are forced
to use a stupid memory hogging memory manager for something that should be
natural.
Intel ward both Gates and IBM that they were making a new chip that would
use protected mode of addressing, but since Gates knew nothing about
operating systems, and IBM knew nothing about microcomputers, we all got
stuck with DOS. Had Kildall written the OS, we would not be having these
problems today. We still would probably not have these problems today if it
were not for the bugs in DOS and those stupid MS APIs. But so that everyone
elses DOS is compaible, they have to work around the DOS bugs and backward
engineer those stupid APIs that were put in because of Gates' GREEEEEED.
Also a lot of LIM4.0 hardware is not fully compatible with LIM 3.2. This has
also caused a lot of problems. LIM 4.0 is a superset of LIM 3.2 and includes
all of the 3.2 capabilities, but many hardware manufactures did not follow
the STANDARD. So your question about backward compatibility will still be a
question, because it depends on what the hardware can do.
Pat
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
- Raw text -