Bertho, >> Given the "high level of responsibility" [Ha-Ha!] taken by the >> VirtualBox creators, it looks as if I will have to add another >> UIDE switch, that disables diskette caching regardless of what >> its other switches tell it to do. > > Jack, if I may chime in... I think you're now contemplating the right > step. I can understand your frustration with VB in this instance, BUT > imho your previous approach has been to ignore a few facts, that have > nothing to do with that or another emulator or virtualiser : > > On REAL (old) PC hardware, the existence of floppy disk changelines is > not guaranteed; even if the line is present AND properly connected it > MIGHT be flaky or not work at all; or the BIOS might not update the bits > you expect. MS-DOS (and, I presume, good DOS clones as well) will use > alternate means and kluges to check for media change in the absence of a > (credible) change line. Your DOS drivers could have been relying on DOS > for checking media change, not on the BIOS or direct HW interrogation > in the 1st place!
My design goal for UIDE/UIDE2 was to write a driver that uses as FEW "DOS system calls" as possible. At present, UIDE/UIDE2 are more a "BIOS" than a "DOS" driver, and they need to handle only a BIOS "Int 13h" call after their initialization. I did so (A) to have a SMALL driver, not a "Bloody MONSTER!" like SMARTDRV or Norton NCACHE2, (B) to avoid "DOS calls" that may NOT be implemented the same across all DOS systems, and (C) to follow the old U.S. engineering "joke" known as the "K.I.S.S. Principle" whose letters stand for "Keep it SIMPLE, Stupid!". UIDE/UIDE2 are thus "generic" for use on any DOS system, using very little of DOS during their initialization only. I want to KEEP my drivers that way!! I also DID try to find a diskette driver that I could include within UIDE, but by 2006 NONE were "available", since the BIOS had long-ago taken over diskette handling, and NOBODY offered a separate diskette driver any more! I saw no reasonable choice EXCEPT to use the BIOS "change lines" and "media change" status codes, to handle diskettes. This has been the case in UIDE/UIDE2 since 2006, and NOBODY has ever complained to me about diskette media-change trouble until now. So, I DISPUTE your comments about the change lines being unreliable! They have "been around" from 1985, and if they ever DO fail, that is a "maintenance" problem for the user, NOT an indication that I ought to reconsider using them in UIDE/UIDE2!! > Offering the user an option to switch diskette caching off is much > better. As you are aware, SMARTDRV allows a user to select, disk per > disk, not just for floppies, to cache or not to cache - and if cacheing, > whether to allow delayed writes or just write-through. SMARTDRV has many problems. It takes a LOT of memory and is very heavily linked to MS-DOS, so it may NOT run on other DOS systems!! Also, it has never been updated to use UltraDMA, thus it cannot do I-O directly to/from cache memory (XMS). UIDE/UIDE2 can do both. Delayed writes are nice, but you "PAY for them!" given the size of SMARTDRV and NCACHE2. I felt it to be MUCH more reasonable if my drivers did a FAST Write-Through implementation, with UltraDMA and direct cache I-O, in only their "912 byte" upper-memory size! >> -- UIDE2 has only 16 spare bytes before it goes back over a 7K >> .SYS file! But, I shall find a way! > > No doubt you will. In fact only 12 bytes, and I required only 11 of them for /N5, so UIDE2 still has 1 spare! It is still a 7K-byte .SYS file and it can be "packed" using UPX down to 6K for use on "boot" diskettes! 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
