Jack, > 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>
This document states that bit 0 and 4 indicate change line support for drive A: and B: respectively, but RBIL states that the bits are about 80 track support. A safe option would be not to "read 40:xx coffee grounds" but instead use the well-documented int 13 interface... > And I prefer "emulators" which emulate EVERYTHING, including > a valid alternate way of determining change-line support! If VirtualBox believes RBIL, they have to set the bits, as the virtual floppy supports 80 tracks. If they believe the website mentioned above, they would have to not set the bits, as the virtual floppy has no change lines... >>> 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. Yes, and VirtualBox is correct in doing so. > 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... There is no need to read VirtualBox docs or sources, just follow the well documented BIOS int 13 interface, easy... > I in fact want NOTHING TO DO with "VirtualBox", as it > too-often proves itself a piece of TRASH!! It is not the fault of VirtualBox that you relied on some questionable source of information about 40:xx fields. Of course RBIL is only 99.9% correct either but I am sure a lot of sources agree that int 13 is the official disk API. > I think it is PATHETIC that they > choose not to support diskette media-changes! Dosemu also took a while to support it, you could ask some dosemu expert why they did not immediately do it but I assume that there are sufficient reasons... > 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 Using flag bits for which conflicting documentation exists and then blaming others for not implementing the bits in the way that you would prefer is not a question of optimal versus suboptimal drivers. There would be no need to discuss a well-documented int 13. Sorry if this means that your driver will grow above the current size limit, but I think it will not: You can remove the "manual workaround" command line flag to reduce driver size as soon as you change UIDE to use reliable int 13 as opposed to unreliable 40:xx. 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
