>> 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. > > if UIDE would check INT13/15 if change line is supported, and not > cache the floppy if it's not supported everything would be fine (and > /N5 not needed). I can't locate any documentation about 0:448.
Apologies, I misread my own source file (early!) this morning. UIDE and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive A: or B: suipport a media-change line. Note the BIOS data lists at: <http://www.bioscentral.com/misc/bda.htm> >> My update to UIDE in adding the /E switch was simply to add a mask >> which is 011h without /E, 000h with /E, to "mask" against the bits >> at address 0:448h. This works fine. > > I prefer software that works without switches. at least if it can > handle the situation itself. And I prefer "emulators" which emulate EVERYTHING, including a valid alternate way of determining change-line support! >> 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. > > wrong. VirtualBox tells you 'change line is not supported' > which part of this is difficult to understand? I run V6.22 MS-DOS and V4.0 Win/NT, that I got "for free" in 1994 and 1998 as a software developer. I have never run any "later" Windows, Linux, or other "C"-based systems. So, I have never used VirtualBox and have NO REASON to study its documentation or sources. I rely on what others tell me about it, and before today NOBODY ever told me it positively states 'change line is not supported'. What part of THAT do you not understand?? We all cannot be experts on everything, and after all this, I in fact want NOTHING TO DO with "VirtualBox", as it too-often proves itself a piece of TRASH!! >> And in any event, by indicating NO such support, as you also wrote >> above, they make it impossible for UIDE to cache diskettes anyway! > > exactly. hands off these floppies. Thus you "joke" about this being GOOD?? I think it is PATHETIC that they choose not to support diskette media-changes!! >>> maybe the real issue is that noone finds the time to do a tiny bit of >>> debugging the problem but finds a lot of time to write loooooong >>> emails > >> To which I shall add: Maybe you might have read the UIDE.ASM file >> before making any BASELESS and WRONG accusations about my drivers! > > neither BASELESS nor WRONG, and neither accusations. Just stating > that they behave suboptimal. I say again, apologies for my referencing 0:448h this morning, when I should have referenced 0:48Fh as UIDE/UIDE2's source for the diskette media-change flags. However, "suboptimal" has NEVER been a problem, at-least never before VirtualBox, and UIDE/UIDE2 have worked properly using this scheme for 6 years! I also say again: I will NOT add any (large) amount of logic in UIDE merely to handle one miserable "emulator" program which admittedly is NOT emulating EVERYTHING! On any "hardware" PC system, UIDE's logic for handling diskettes and their media-changes runs fine. As I want to keep UIDE/UIDE2 simple, I shall leave things as-is. If users want to run VirtualBox, they can simply use UIDE/UIDE2 /E which specifies 'hands off those floppies' (like Tom stated above), exactly as the writers of VirtualBox intended! No diskette data errors, and everybody should be happy! Jack R. Ellis ------------------------------------------------------------------------------ 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
