Jack writes:


Eric,

Re: your FD-User post about "new BIOS" UltraDMA errors, the post has
"just a few" ERRORS, which you need to correct:

First, the title of your post, "BIOS with broken UDMA needs DOS disk
driver loaded before JEMMEX", should be changed.   Instead of saying
"UDMA" that you and I understand, use the full word "UltraDMA" which
many more people would more-immediately understand.   Also, one does
not need to load a DOS disk driver, which might be seen as "any" DOS
driver.    One must ABSOLUTELY load a DOS *ULTRADMA* disk driver, as
this "new BIOS" problem applies only to UltraDMA done in "v86" mode!

> Some mainboards have a BIOS with faulty UDMA in V86 mode support!

Better to say "Some *new* mainboards have a BIOS with faulty support
for UltraDMA in V86 mode".   Better English; and again, you should
replace "UDMA" with the full word "UltraDMA".

> ... The presence of EMS memory hardware is simulated by moving
> DOS into a V86 task.

Absolutely NOT TRUE!   "V86" mode was created by Intel to provide a
way of (a) running 16-bit programs on 32-bit systems, (B) providing
protection for the system from such programs.   EMS hardware is NOT
"simulated" but is REQUIRED to access extended memory, which is the
"E" in EMS!

> When the BIOS fails to support UDMA (memory block copy and block
> copy between memory and I/O devices) properly in V86, attempts to
> transfer disk data can fail or end up at the wrong places in RAM.

NOT what Martin Rehak saw!   He got "Cold" DOS disk ERRORS, when his
system tried to do UltraDMA output using his new mainboard.   He did
NOT indicate what happened to his data, during such I-O transfers --
Martin got only disk I-O errors from his V6.22 SYSTEM!

> DOS disk drivers could potentially test if your BIOS is buggy, but
> it will not always be possible to do that without causing a crash.
> In the BEST case, the driver could conclude that no UDMA will work.

Given Martin's new mainboard, it will NEVER be possible to do such a
test, I guarantee you!   Also, if we limit "DOS disk drivers" to the
ones I wrote, assuming "no UltraDMA will work" says the drivers MUST
"call the BIOS" to do such I-O.   My drivers were meant for UltraDMA
and have no "PIO mode" code for disks (XDVD2 must have it for CD/DVD
"audio" and other drive commands).   Calling the BIOS on such a "new
BIOS" mainboard WILL cause crashes, as the BIOS itself is a PROBLEM!

> In the WORST case (!), the BIOS itself defaults to UDMA disk access
> and crashes as soon as you enter V86 mode.   In that case, you will
> be FORCED to load a driver like XHDD or UIDE before loading JEMMEX
> to protect your BIOS from its own stupidity ...

Not the worst-case, but the EXPECTED case, as modern BIOS programs
ALL use UltraDMA to improve speed!   Also, unless you desire nasty
words from my "good friends" Rugxulo and Hall, I would not mention
XHDD, since it shall remain closed-source and thus unavailable for
use within FreeDOS, also unavailable for archiving on SourceForge.

> To avoid crashes, it is important to LOAD DISK DRIVERS BEFORE EMM
> (if your BIOS is affected by such bugs). For example, load XHDD in
> your boot process before you load JEMMEX. If you disk driver is
> using XMS (for example as cache) you can of course not use JEMMEX
> as your XMS driver, but have to load a separate XMS driver before
> the cache, as JEMMEX has to be loaded after the disk driver...

Likely a very "confusing" paragraph, for the average user!   Again
I would suggest NOT mentioning XHDD, as it shall never be any part
of FreeDOS.   Do try to write "simplified" English so more of your
users will understand what is going on.   I target "4th graders",
which some view as insulting.   But, I know doing so is NECESSARY!

> Some drivers can use HMA space provided by XMS drivers (as HIMEM)
if no UMB space (provided by EMM386 and similar) is available ...

Never heard of any other DOS drivers loading in HMA, except my own.

> Jack recommends to load HIMEMX then UIDE then JEMMEX: That way, the
> UIDE driver can use the HMA and HIMEMX + UIDE will use circa 3.5 kB
> of low DOS memory together. If you only load UIDE and then JEMMEX,
> UIDE would need 4.5 kB of low DOS memory and would miss early XMS.

All true, with V6.22 or V7.xx MS-DOS.   NOT TRUE when using FreeDOS,
since FreeDOS does not make any HMA available to CONFIG.SYS drivers!
When using FreeDOS, there is NO SUCH THING as "early XMS"!

> An even more advanced suggestion by Jack is to load XMGR /B instead
> of HIMEMX, then UIDE, then JEMMEX, then XMGR again, but without /B,
> which allows XMGR to regain 2 kB of memory as soon as JEMMEX is on.

JEMMEX will NOT load if another "XMS manager" driver is loaded!   If
XMGR is present, only JEMM386 or another "non-XMS" EMM driver can be
used.   XMGR + JEMM386 solves the problem of FreeDOS permitting only
one upper-memory "provider, in this case JEMM386.   UMBPCI + JEMM386
may not be used together, on FreeDOS.   That is why I suggested this
CONFIG.SYS "scheme", from my driver README file.   But NOTE that it,
too, may not be of much use -- the full UIDE then must load in "low"
DOS memory, since FreeDOS does NOT offer HMA before AUTOEXEC is run!

> Note that FreeDOS by default does not give drivers access to HMA
> space at all inside config.sys, so you would have to delay those
> driver loads to autoexec - other DOS variants are more flexible.

What you suggest would be the WORST case of all!!   JEMM386/JEMMEX
cannot load on a "new BIOS" mainboard unless an UltraDMA driver is
already loaded.   If you delay loading UIDE until AUTOEXEC, and so
have no "EMM" driver during CONFIG.SYS, FreeDOS and most other DOS
systems will REJECT your "DOS=HIGH,UMB" command!   The user system
then gets a low-memory-ONLY kernel, having no upper-memory nor HMA
available!   An "EMM" driver MUST load during CONFIG.SYS; and now,
due to our "cheap" Taiwanese friends, an UltraDMA driver MUST load
before the "EMM" driver -- unless you want to try a diskette/etc.!

> PS: When you boot Windows or Linux, the protected mode disk drivers
> of the operating system are usually activated BEFORE any V86 tasks
> get the chance to try to access the disk. This is why the BIOS bug
> can go unnoticed - only DOS will suffer, other systems don't care.

Try telling THAT to Martin Rehak, who spent a LARGE number of hours
in a vain attempt to get his miserable Win/98 system to "boot"!   I
cannot speak for Linux, as I have never used it.   What you say may
be true for "larger" Windows systems; but it is NOT true for Win/9X
variants, in which Microsoft "Broke EVERY rule in the book"!   Take
a look at the sources for Microsoft HIMEM or EMM386, as I have; and
you will SEE how they created the perfect "Frenkenstein's MONSTER",
then had virtually NO CHOICE but to "abandon" all of that GARBAGE!!

Jack R. Ellis



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to