>> the 'issue' is that VirtualBox clearly states 'floppy without
>> change-line support'
>> int13/15 returns '01h floppy without change-line support int13/16
>> returns '06h change line active or not supported
>> but UIDE ignores this, and relies on change line support anyway.
> You are WRONG, Tom!!
> UIDE has NEVER ignored if a diskette has change-line support!   It 
> does in fact check the BIOS data table at 0:448h for bit 0 (change 
> line for diskette A:) or bit 4 (change line for diskette B:).   If 
> those bits are off, diskette A: or diskette B: will not be cached.

That is an interesting bug in VirtualBox then (wrong 40:xx data)
but I support Tom here because int 13 is the "front entrance" to
knowing if change lines are supported. Whether and how this uses
the "back office" 40:xx data and whether this data reflects the
"official" statement returned by int 13 is not always reliable,
so asking int 13 is probably better. Also, it would be very easy
for UIDE to ask int 13 instead of or in addition to 40:48 bits.

I remember that DOSEMU also had no change line support back
in version 1.1.3, but reported that correctly via int 13.15
and when you queried int 13.16, it always said "changed"...

> But, if what you wrote above is correct, VirtualBox expects people to
> use ONLY the "Int 13h" requests, when determining if a diskette has
> change-line support. And in any event, by indicating NO such support
> ... they make it impossible for UIDE to cache diskettes ...

Indeed. But it is better to not cache than to damage data.

Back in the DOSEMU 1.1 days, I had an undocumented option
for LBACACHE to cache diskettes even without change line,
but the user had to manually tell the cache each time when
the diskette changed. I have not implemented something a
la "flush on boot sector read" then, because all physical
floppy drives that I had did support the change line and
I only wanted to play with floppy caching myself, did not
suggest to normal users to cache no-change-line drives...

> cache diskettes anyway! I will NOT cache a drive which cannot tell
> me when its media has changed, and I REFUSE to add all of the logic
> in UIDE that Eric notes the DOS kernel contains, to find out if a
> media-change has occurred using other methods!

Given the new information from Tom, I agree that it is
not worth the effort to add heuristic cache flushing,
as it turned out that it IS possible to detect that no
change line exists in VirtualBox. So VirtualBox users
will not enjoy UIDE caching, but please do use int 13
(instead of or even better in addition to 40:48) for
the detection of systems without change lines... That
will protect VirtualBox users from data loss dangers!

> So, I shall amend my earlier post to say that VirtualBox now needs 
> TWO changes:  (A) It needs to provide media-change status for each 
> diskette, and (B) It needs to provide a PROPER BIOS DATA TABLE, as 
> the table bits that are "seen" when VirtualBox runs are INCORRECT!

With change (a) it will support floppy caches better,
but I consider (b) to be low priority, as the normal
way to ask the BIOS about change lines is int 13.

> To which I shall add:  Maybe you might have read the UIDE.ASM file 
> before making any BASELESS and WRONG accusations about my drivers!

The sources are circa 4000 lines long and do not even
mention "change line". Now that you explain how UIDE
works, I was able to find this snippet:

>         mov     al,FMCMask      ;Use diskette media-change bits
>         and     al,es:[MCHDWFL] ;  for our number of diskettes.
> I_FScn: test    al,001h         ;Can next unit signal media-changes?
>         jz s    I_FMor          ;No?  CANNOT use this old "clunker"!

where MCHDWFL equ 0048Fh. You claimed that you would
check 40:48, not 40:8f, but I could not find anything
in UIDE which checks 40:48 and RBIL does not give any
meaning for 40:48 either. Looking at RBIL for 40:8f,
I see that you can check whether drives support 80
tracks and/or multiple baud rates, but not on XT and
nothing is said about change lines being flagged by
this byte according to RBIL. In other words, it MAY
be the case that most BIOS implementations that you
have seen somehow tell something about change lines
in some 40:xx byte, but it is NOT documented in RBIL
and therefore you should not blame VirtualBox for not
implementing this undocumented flag needed by UIDE.


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Freedos-user mailing list

Reply via email to