Jack, kernel experts, > 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!
When DOS detects an unreliable floppy change line hardware, it should use the floppy label / serial / similar to detect changes in software. Maybe FreeDOS does this, maybe not? Is a change in label / ID always a trigger for a change event, or only in context of having detected hardware reliability troubles before? > Offering the user an option to switch diskette caching off is much > better. As you are aware, SMARTDRV allows a user to select... I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable in REACTION to detecting a floppy change? For example it might issue an int 13h "drive reset" command which in turn can be caught by the UIDE2 driver and treated as a "flush cache for THAT drive" event? Depending on other factors, even flushing the caches for all drives or all floppies would still be better than a situation where the cache still contains data from old disks which are no longer inserted in the drives: Rather be SAFE, have some performance loss (due to extra flushes, less cache efficiency is reached and the flush itself also takes time) than SORRY (data loss due to mismatch in cache / real data). If the kernel issues eg. int 13.0 after detecting a floppy change - which it should be able to do even if the change line is unreliable - and UIDE2 reacts to that with a flush, DOS can take care of the reliability while UIDE2 still only has to care about int 13 calls :-) Also this makes it safer to use UIDE2, as is does not need manual /N safety options. >> -- UIDE2 has only 16 spare bytes before it goes back over a 7K >> .SYS file! But, I shall find a way! Thanks :-) By the way, any chance to work around the VirtualBox huge-delay problem? Apart from configuring VirtualBox to use a different virtual chipset, I mean. It seems that UIDE2 code, in particular I_ScnC, I_PCIC and I_PCID uses BIOS calls (not fast? raw I/O) to scan ALL possible bus/device/function numbers, thus ignoring the "last used bus number" returned by int 1a.b101.0? If you prefer the BIOS way, would int 1a.b103 be an option? It scans by PCI class so you do not have to loop over bus/device. Just some ideas, of course, but might also help to make UIDE2 more robust with other flawed "hardware" or BIOS versions :-) Note that for example PCISLEEP only uses raw I/O in getpci and skips looping over functions if function 0 of a bus and device number pair return "PCI ID -1". So you scan only 1 out of 8 in such cases. Each bus has 32 device numbers to scan. Also, often you have far less than 256 bus numbers in use, saves much time. By the way, PCISLEEP only supports the "newer" mechanism 1, the "ancient" mechanism 2 for I/O is not supported but rarely used. See also: http://wiki.osdev.org/PCI and also note that SYSLINUX 3.05 calls mechanism #2 a "hideous old hack" yet supports it: http://www.syslinux.org/old/history.php As you see in PCISLEEP source code, mechanism #1 is easy and compact to implement :-) Regards, Eric PS: The UIDE issue is described in Ulrich's wiki page which also is a good GENERAL "how to install FreeDOS 1.1 on empty harddisk" document :-) I would also suggest to make /NOHI the KEYB default! The KEYB thing might be due to rawer-than-EMS-style UMB attempts? > http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8 > http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_9 PPS: Heat-wise (VirtualBox Chapter 7) I suggest to add FDAPM to one of the default driver sets in FreeDOS 1.1 config / autoexec. > http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_7#Possible_Solutions:_2._Use_DOS_Power_Management ------------------------------------------------------------------------------ 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
