Zbigniew,
>> Now that JEMMEX is available, HIMEMX + JEMM386 and XMGR + JEMM386 are
>> "historical curios" only, and JEMMEX should be preferred.
>
> That was my guess: "maybe some of them can be even seen as 'obsolete'
> by now".
All still work O.K., however JEMMEX saves all possible 640K memory for
use by DOS programs.
I have saved XMGR for "real mode" users who run UMBBCI first, followed
by XMGR. In that case, XMGR is able to "read" UMBPCI's table of UMBs
and can load there directly, which also uses 0 low-memory like JEMMEX.
UMBPCI cannot "map" the B000h-B7FFh space ("black and white" graphics,
that no one uses any more) into upper-memory. But DOS games players,
and others who want real-mode speed (like me!), normally get over 128K
upper-memory, which is O.K. for our needs. So, UMBPCI + XMGR is the
only useful "old" configuration -- Most users should run JEMMEX alone.
> Actually, it was a bit surprising to me, that I still need a software
> cache, while using hardware, which - like for DOS requirements - is
> really very fast. Unfortunately, using no caching at all, I noticed
> pauses (3-4 seconds), that occur although not to often, but frequently
> enough to be irritating (the controller's LED is on at that time).
> Well, perhaps the NVIDIA SATA isn't the best fit for DOS.
Not NVIDIA's or other chip makers' problem. Memory speeds continue to
"Reach for the MOON!", while the actual bit-rate coming from a disk has
remained much more constant at about 33-MB/sec. Higher transfer rates
like 3-GB and 6-GB simply permit much-faster "burst rates" from a disk,
but sooner-or-later one must actually READ data from it, and it is that
reading that remains slow.
DOS also retains its single-sector directory handling, designed back in
the early 1980s, when memory was EXPENSIVE and buffers were kept small.
Even with BUFFERS=nn in CONFIG.SYS, DOS still writes directory sectors,
then could re-read that sector again, like when deleting multiple files
from one directory. With UIDE/UIDE2, most reads come from XMS memory,
and writes of the SAME sector usually only "update" the write caches in
modern hard-disks, so that deleting 1000 files from a disk "appears" to
take little-more time than deleting 10 files! Not-much I can do for a
big file-copy, as the data must be moved "sometime", but for repetitive
directory-sector operations, UIDE and disk write-caches do help, a LOT!
>> For most of us, I feel UIDE with its 1400 bytes of extra logic beyond
>> the actual "driver", 800 for UIDE2, is a more reasonable caching idea
>> and provides fully-adequate speed, especially as both can do UltraDMA
>> directly to/from the actual XMS cache buffers! That saves time that
>> a "Write Back" cache, with separate drivers, might not be able to do!
>
> I agree, thanks for providing such nice thing. :)
My Thanks, and my apologies to all that this 66-year-old "Dodo Bird" was
not able to "think up" such an idea before about 2008!!
>>>> Just tell them you know a "Sorcerer"!
>
> ... In conclusion: "wizard" writes extraordinary drivers - "sorcerer"
> creates e.g. very interesting... viruses. ;)
Since I am not from Russia nor from India, please do NOT "associate" me
with viruses! Anyway, many Thanks for your "extraordinary" word!
>> Forgot to mention in my last post that if you do run
>> UIDE2 in HMA space with /H, you must limit the cache [..]
>
> Thanks, I think, that it could be worthy to add this comment to
> UIDE's readme.txt.
I keep my README.TXT file small, as Johnson Lam must have it translated
into Chinese for many of his users in Hong Kong and mainland China. I
do have all comments about UIDE2 at the start of the UIDE.ASM source.
Best wishes,
Jack R. Ellis
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
