Hi Jack, Dos386, as your driver already has built-in caching, UIDE does not need to "make" int 13 device numbers for non-BIOS devices... I still think that allowing PIO for harddisk in case UDMA fails would be nice, and maybe it could share most of the logic with CD/DVD PIO mode.
The block device thing is a separate issue - DOS does not care whether the hardware is int 13 or ASPI or RAM as long as there is a block device driver which can do very basic access such as "read sector 1e to 2ff:c00". The functionality is the same as for RAMDISK. Drivers for RAMDISK can be very small, so the suggested driver would also be small. However... The problem is that DOS block devices are single FAT filesystems, not partitioned disks. It would be easy to write a driver which parses the partition table of a given int 13 (or ASPI, if we want more bloat ;-)) disk and gives DOS block device access for each FAT partition on it. DOS itself then does the FAT file- system handling and assigns drive letters etc :-). Note that I do not know existing "give block device access to all FAT partitions of int 13 disk XX" style DOS drivers. There is one for ASPI, which is Adaptec ASPIDISK, but afair, it only checks for FAT16 and of course it is not open source. It is very small and it is useful for some DOS USB drivers which make storage devices available as ASPI devices :-). I assume int13 style would be even smaller than ASPI style here. Eric ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
