> Calling the BIOS on such a "new BIOS" mainboard WILL cause crashes
Does this mean that FreeDOS will not boot at all on these systems or do you
not mean BIOS interrupts?
73 Matt Rienzo W9ERA
B.S.E.E | B.S. Music
On Jan 13, 2016 1:25 AM, "Eric Auer" <e.a...@jpberlin.de> wrote:
>
> 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
>
------------------------------------------------------------------------------
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
