Re: [Freedos-user] checking virtualbox source codes for floppy and pci speed issues

[Jack <gyk...@ea...>]

Eric,

> Yes, 40:8f might be wrong in VirtualBox and yes the
> person who set it to the wrong value may even be in
> your "BIOS Central" style group of 40:8f users.

Did you ever think that such person may have been RIGHT
and all who say "use ONLY Int 13h calls" in determining
diskette media-change capability may be WRONG??

THAT was my point, in my last FD-User post!!   Somebody
besides me, in this event SOMEBODY AT VIRTUALBOX, had a
REASON for setting byte 0:048Fh like they did!   So, my
conclusion that all of your "conventions" on using ONLY
Int 13h may NOT be "cast in concrete" as you may think!

> But for example the IBM PS/2 and PC Technical Reference
> (official 1991 IBM docs) clearly describes 40:8f as
> RESERVED byte in the BIOS Data Area chapter, so you
> are still walking on thin ice with UIDE.  Of course
> the same reference book also describes ints 13.15 &
> 13.16 when it comes to proper floppy change checks.

In light of the above, I don't think I am on thin-ice
at all, and I'm still NOT convinced there is only ONE
"proper" way of testing diskette change-line support.

> Again, using int 13 instead of 40:xx would have
> avoided all UIDE troubles - even on VirtualBox.

Maybe, maybe not.   Other "emulators" and drivers may
be programmed to read the values from 0:048Fh and NOT
issue Int 13h calls, same as me.

> Another interesting thing is that the VirtualBox
> PCI BIOS seems to scan all possible 256 PCI bus
> numbers while it also states that it only has one
> such bus at the moment. MAX_BUSDEVFN could thus
> be lowered to 100h instead of 10000h which could
> mean 256 times faster UIDE load times. If this
> is true, PCISLEEP style PCI bus scans would be
> even faster (up to 8 times) compared to even the
> possible 256-fold improvement through VirtualBox
> BIOS tweaking, compared to 3 minutes in UIDE-VB.
>
> Of course it would be interesting to contact some
> VirtualBox experts about whether MAX_BUSDEVFN is
> indeed too high (PS: pcibios.inc and pcibio32.asm
> should probably derive the CL returned by int 1a
> function b101 from MAX_BUSDEVFN for consistency)
> and about whether orgs.asm line 1137 & 1147 CODE
> should be changed, to reflect the missing change-
> line support, or whether only the COMMENT should
> be changed if this bit is about 80 track support
> rather than change line support!

All "speculative" without such info from VirtualBox.
On any "hardware" PC, a UIDE/UIDE2 scan for PCI data
using class/subclass/function data (NOT busses) runs
almost instantaneously, so I see no reason to change
THAT logic in UIDE/UIDE2, either!

You also MIGHT hear from VirtualBox that their setup
of 0:048Fh is in fact CORRECT and some OTHER element
of their program is LOSING the byte!   I.E. they DID
intend diskettes to provide change-line support, and
someone else among their programmers "blew it"!   It
sure seems like their "RIGHT hand does not know what
their LEFT hand is doing", as we say, if your source
code fragment is correct!

Jack R. Ellis