Hi Bret,
>> any idea how reliable/wide distributed this is? > It seems to be fairly widely distributed. I just tested in a few > places. It's present in an old HP laptop (I think it's about 7 years > old now). It's also present in VMWare Player and QEMU, but not in > DOSBox-X. > I also have it implemented in my USBDRIVE program. >> is this always available if LBA extensions are available? > I have no idea, but think it probably should be. The spec has been > around a long time. Jack has commented on the topic: His UHDD driver requires both EDD 3.0 and PCI 2.0c support to be present before UDMA transfers are possible, because EDD 3.0 only provides most, but not all, low-level I/O parameters for that. And "virtually all" PC BIOS since 1998 do support both as far as he can tell :-) His drivers fall back to use BIOS I/O when UDMA is unavailable, but still provide caching nevertheless. They redirect attempts to use 64-bit buffer pointers to using the BIOS, but so far, nobody has complained about UHDD not caching buffers at 64-bit linear addresses. The drivers themselves do not use them for BIOS calls either, they only transfer data directly between disk and XMS when a transfer is an UDMA transfer handled by the driver itself. When the driver calls the BIOS for I/O, it uses buffers below 1 MB. In short, we can assume that EDD 3.0 is widespread and that 64 bit address support might be widespread as well, but rarely used. If FreeDOS would ever decide to use 64-bit buffer pointers and XMS to optimize disk access, it would be relevant to know that such access is not yet cached, nor UDMA accelerated, by UHDD. Regards, Eric PS Jerome: Clever method to pass a setting from autoexec to know whether the installer has been started from FreeDOS and FreeCOM! _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
