Jack, >> 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. Eric ------------------------------------------------------------------------------ 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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
