Mail Archives: opendos/2000/12/01/07:39:24
----- Original Message -----
From: "Matthias Paul" <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
To: <opendos AT delorie DOT com>
Sent: Thursday, November 30, 2000 6:45 AM
Subject: Re: Optimizing CONFIG.SYS...
> On Wed, 29 Nov 2000 Patrick Moran wrote:
>
> > Actually it loads in two chucks. With QEMM I found it can load with
65000
> > bytes (probably less if I experimented more but was satified with that
> > amount.)
>
> It could be that the low level portion (including the buffering)
> and the higher level file system stuff are loaded in different
> segments. Maybe it was consuming more memory on my system because
> I have set the buffers to max?
>
They way I found this out was by forcing NWCDEX to load low and see how much
memory it actually used there. I don't recall how I figured out that it
loads in more than one chunk. I may have read about it or just assumed it
when playing around with loading it. I know that QEMM would allow 128K for
loading it. I also found that QEMM also allowed more memory than what is
needed to load the DRMOUSE driver. I played with that and found it will load
with 9 or 10K of memroy instead of something like 12K. Thus I could force it
to load into the B000 range. By using a lot of different techniques and
using both MFT and MEM, I dicoverd a lot about how things load with DRDOS.
You might try using different buffer sizes and forcing it to load low and
see what the results are. If you have QEMM, you might want to see how much
memory it needs to load it with different amounts of buffer. That may give
some clues. Why do you need those buffers? There are caching programs
available for CD. I only have a 4X CD and it is also a SCSI CD which may
also make a big difference. I never could see any practical use for those
high speed CDs anyway, because all I use mine for is to install programs and
listen to audio CDs. My next one will be a DVD RAM drive anyway and those
are not high speed CDs either. Those so-called high-speed CDs are nothing
more than about a 6X or 8X CD with a large RAM buffer. If those things
actually spun at 24X or 36X they would probably fly right out of the drive!
That brings up a question I have had and have done some research but have
not found the answer. The DVD RAM drive I want to get will also be able to
read and write PCDs. Can PCDs be use just like R/W CDs. They also have 650MB
capacity. i.e. do the use ISO 9660? Or can they be forced to? If so, then I
could DL ISO images. Sure I can do that anyway as there are programs that
can force a HD to look like a R/W CD, but I could actually save it
permanately on a PCD if that is possible.
> > I downloaded the program and will check it out sometime, but if it takes
900
> > bytes of conventional memory, I won't need it until I use QEMM or
something
> > else that does not let it all load into UMB and extended memory. I can
get
> > by with 112 bytes in an area I can't use anyway. (At least at this time
I
> > cannot.)
>
> Hm, my INSTCDEX has nothing to do with the 112 byte environment not
> being freed by NWCDEX, if you mean that. (I mentioned that my
> personally enhanced issue of NWCDEX as well as other drivers do free
> the environment, and if Lineo would at some time open up DR-DOS,
> I will make this available to everyone. I still haven't lost hope...)
> INSTCDEX allows to load NWCDEX in CONFIG.SYS (which normally does
> *not* work for various reasons) and thereby the chance that it can be
> completely loaded into UMB will be increased. INSTCDEX is not a
> resident tool, it is an utility that patches around in internal data
> structures, and allows to temporarily save state data on disk, while
> the Current Directory Structure (CDS) is relocated into UMBs after
> CONFIG.SYS processing has finished.
What environment are you talking about then? The 7K?
That program might be useful with QEMM. I do have over 64k of contigous
memory left in UMB for a page frame, but I cannot get everyting loaded high
when I use an EMS page frame. Too bad I can't establish the page frame last
after verything else is loaded.
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. I don't know why that is a limit, but
according to the book "DOS Above 640K" it is.
AST actually made a computer that had no conventional memory and used EEMS.
I don't know how they did it, I would like to see the theory and docs on how
they did this. It seems that you would need at least 64K conventional to
start with. My old 286MB was a 99.99% clone of an IBM AT. It's BIOS ROM was
located in two memory locations. At the top of 1MB and at the top of 16MB.
Why no one ever used this feature other than AST, beats the crap out of me.
It seemed like the most logical way to do things. You just forget about
conventional memory completely and run everything in extended memory. All
that would need to be done is to boot thew system, load the system area of
low RAM into the bottom of the extended memory area and operate everything
in the 1MB to 15MB range, then of course with the 386 it would be 1MB to 4GB
area. ROMs are generaly porgrammed to be relocatable. i.e. they could care
less if they are loaded at C0000-C7FFF or C8000-CFFFF or D0000-D7FFF or
FFFFC0000-FFFFC7FFFF. The first significant hex number is merely relative
and is assigned by a jumper or whatever as in C000 or D000 or C8000 or E800.
Any address beginning with more significant didgits is irrelative. So it
could be FC000, FFC000, FFFC000, FFFEC000 or what ever you want. The only
restriction would be a particular boarder of 8K, 16K, 32K 64K or whatever it
happens to require.
I don't know if current mother boards still follow this, but if they do, all
someone needs to do, is write a loader to do this and forget about
conventional memory altogether and EMS completely. But because many programs
do use EMS (only) you could put as large of a page frame as you want in
extended memory, probably with the 256K limit. Then you would have however
much memory in your system minus the 1MB of conventional memory. This would
probably require that DOS be rewritten so that it CAN operate in protected
mode. I would not think that it would be that difficult to do, as instead of
using segmented addressing you could use absolute addressing. As far as DOS
or any other application is concerned, the beginning of memory at 100000
would actually be 00000.
This is essential what APPLE did with it's DOS, you could load it at the top
of any 4K page boundry. There were loaders that would shove it up into the
Language card. I did this as I had Applesoft in ROM on th MB and Integer
BASIC in a ROM card in one of the APPLE MB slots. The loader would merely
change the Most Significant hex address accordingly for all absolute jumps.
This could also be applied to an APPLE ][e with 128K RAM, you could have
shoved it to the top of 128K. APPLE had a high and low memory marker and no
program gould be loaded above/below those markers.
A very similar thing was done with my OSI. There were 4 unused data lines of
it's bus, and these could be used in comjuction with the PIA port that was
also on the CPU card to manipulate 64K pages above the 64K CPU limit and
thuse allow you to use up to 1MB or RAM. OSI actually had systems that could
utilize up to 256K or 512K RAM doing this. They did this in thier multiuser,
multi-processor systems. We are talking about a measly 8 bit 3MHz CPU system
that could run circles around an IBM system with 16 bit processors. In fact
you had to have at least a 286 to even use multi-processing in the Intel
family of chips, yet OSI did it with 6502, Z-80 and that 1600 chip they used
to emulate a PDP-8! And you could install as many 6502 CPU cards as you
wanted into a single system and connect up to 256 such systems together. The
Backplane of each system could be expanded up to 256 slots per system! This
was way back in the late 70's!!!!
> I'm not sure, Patrick, if you can make good use of INSTCDEX in
> your configuration, because you said you already *can* load high
> all the stuff, and even if not, you said, you *can* load NWCDEX
> in CONFIG.SYS (the only reason I currently see, why this works for
If I use QEMM or any kind of page frame, I may need it. I do not currently
use EMS at all.
> you even without INSTCDEX, is that your system sees only one or two
> DOS partitions, because otherwise the pre-set of the LASTDRIVE value
> (the reported count of slots in the pre-CDS) would be used up
> already (and you can expand this only by loading block device
> drivers, or - under DR-DOS - by patching around in the kernel's
> internal data structures (INSTCDEX /LASTDRIVE does that)).
This may be true as I only have a single IDE drive and it only has two
partitions on it. Everything else in the system is SCSI and the IDE will be
history before long, when I upgrade this system to a much better MB and
memory and a 80 or 160MBs ultrawide SCSI.
> The LASTDRIVE setting only takes effect after CONFIG.SYS has
> finished, in the same moment when the pre-CDS (in low memory)
> is freed and the actual CDS is build (in UMB memory when DOS
> goes up).
I take it then that 7K area is used for that and if you can load that high,
you are in the groove.
> NWCDEX takes 928 bytes of conventional memory, when it uses EMS.
> So far I was not able to load this portion high. Anyone?
Did you try loading it first and using INSTALLHIGH? What about with your
SETENV?
> However, many people are still using EMS *and* let NWCDEX use
> DPMS *and* have problem to load the 7 Kb real-mode portion into
> UMBs. Those people are probably better off forcing NWCDEX to use
> EMS instead of DPMS.
I have always had that problem, until recently when I was playing around
with it and discovered if I loaded it very early in the AUTOEXEC, before any
additional environment was used and using the LOADHIGH with it, it would
load everything into DPMS and UMB. But, it will not do so if I use EMS,
because that stupid memory hogging page frame takes 64K of UMB away before
you can load your drivers and TSRs. If that damnn thing could be load last
but before anything requiring EMS was loaded, then everyone could probably
do it. That is just one more reason I hate EMS. Maybe we should take a step
backwards and use EEMS. i.e. Use AST's much more capable memory manager that
LIM 4.0 was based on but hacked because of stupid company egos!!! That is
the same reason I sometimes have problems connecting at 28800 with my modem.
It has the Rockwell chipset in it and was designed before the v.32bis was
implemented, BECAUSE NO OTHER COMPANY WANTED ROCKWELL TO HAVE A HEADSTART,
so they hacked it and Rockwell had to redesign their chipset, just because
they might be a little ahead of everyone else. I can sum it up into one
single word-> GREED!
> (BTW: NWCDEX has a bug, and will hang if you force it to
> use EMS when EMS is not present.)
That figures! Maybeeck for the precence of EMS before it loads<g>
> is ignored. So, if your ROM-BIOS has faulty date support,
> you would need to load a 3rd party Y2K-fix after loading
> QEMM. This should work. Such TSRs are freely available
> from many places, including ASUS (ASUS2000.COM) or
> Heise Verlag, Germany (c't magazine, www.heise.de).
Most diagonstics I have run ssys it is Y2K compliant. I have had a couple
that say it is not, but on decenber 31, 1999 at mednight it rolled over. I
think I also checked it for leap year and it is obvious that that worked
because we are now past that point. I haven't checked it for leap year 2004,
but don't intend to be using it then, unless it is for a DOS box.
> 2. QEMM's DOSUP has problems because of the changed layout
> of handles since DR-OpenDOS 7.02+. Previous issues
> had 5 handles in one chunk in low memory during CONFIG.SYS
> and 8 or more handles in two chunks (8+x) afterwards.
I was always currious, why DOS UP had problems with DR DOS, seems like it
should have been a simple fix for Qauterdeck to fix it in later versions of
QEMM, but QEMM 8 still has that problem. The FCBs are probably handled in
this manner for CP/M compatibilty, which of course Gates immediately
allienated when MS wrote it's first actual version of MS DOS (V2.0.) BECAUSE
CP/M COULD COMPETE WITH MS CRAP FOR DOS!!!!! GREED!
> Due to the introduction of the FILESHIGH/FCBSHIGH
> directives, this has changed a little, and it now
> has 5+3 handles in two chunks in low memory and
> optionally x handles in a third chunk either in
> low memory or upper memory, depending on FILESHIGH/
> FCBSHIGH. This is completely valid in terms of
> DOS standards, but QEMM's DOS-UP objects (probably
> just because it does not expect this layout under
> an OS or the DR-DOS family).
They stick with the stupid buggy MS CRAP APIs probably, because who knows
what Gates may have done if they did not stay completely within his circle
of complete dominance. If Gates had found out that QEMM would work perfectly
with DRDOS he would have changed a stupid API to make QEMM not work with MS
CRAP for SOFTWARE. Which by the way is illegal! But since it is Gates doing
it, the law is just for other people, Gates don't you know is above the law.
(let's get some very messy pies ready!!!)
> The other QEMM features still work, though.
> If you really want to make this work, back in
> 1997 I developed a simple patch for the IBMBIO.COM
> file which forces the old layout. This was posted
> several times in this forum (I think I called it
> IBMBIO85.SCR), but I could locate it in my archives
> if anybody still needs it.
I have one of those that you wrote. Not the .SCR, but the binary. I don't
recall the date on the file or where or when I got it. It is in my vast
collection of DRI related files. I'll have to dig it out and look at it. Did
that version fix the problem with DOS loading into HMA or was it based on
the 7.02 updated kernel files which had already fixed that problem?
Can you send me the code that you used and I can disassemble the 7.03
version and edit it in and reassemble it with the patch. I can use Sourcer
to diassemble and MASM 5.0 or 5.1, which ever version of MASM I bought as
that version of Sourcer is compatible with my MASM.
Pat
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
- Raw text -