Hi Tom,
>> Jack has commented on the topic: > it would be cool to have his comment forwarded to this list, not only > a summarized version of it (as far as you understand and think is > important). Sure, here is the original comment, after checking back with Jack. Note that I had put that "64 bit buffer pointer" thing in context of being potentially interesting for the kernel for DMA boundary safe buffers in XMS space AFTER that, so Jack's comment was based on incomplete context at the moment when he had written about it: > int 13 functions 42/43 can support 64-bit flat address > pointers for the I/O buffer in V3.0 EDD. Do you know > how frequently this is actually supported? My guess is that 64-bit buffer addresses are NOT handled by DOS. My drivers reject such I-O calls and pass them back to the BIOS. I use only the first 32-bit address word, which is a regular segment/offset pointer for DOS. > The int 13 function 41 detection result itself seems > only to tell me whether function 42/43 are supported > at all and whether the EDD version is 3.0 or not? Correct. > Or will EDD 3.0 BIOS always support that flat address > pointer variant? No idea. Nobody has ever complained to me about using a 64-bit pointer, and I assume DOS does not use them. How the BIOS handles them, IF it handles them, I do not know. > Lacking a way to check whether the pointers are supported, > I would GUESS that EVERY bios with EDD 3.0 supports them? Again, no idea. Even if the BIOS supports 64-bit address pointers, I think no DOS system uses them, and they always specify only the 32-bit segment/offset pointers, or else I would have heard differently from SOMEBODY by now! > If I remember correctly, UHDD could use EDD 3.0 to know > which disk is connected to which PCI controller. Does > it require that for UDMA or is it equally acceptable if > UHDD just scans the PCI bus without using EDD data? MUST use EDD data, as the PCI BIOS doesn't specify what BIOS drive number is used for every DOS disk. PCI does not know that; only EDD does. Also, the EDD specs have a BIG "hole" in them: They specify the IDE addresses but DON'T specify the UltraDMA address for each controller! XHDD/UHDD must match the PCI and EDD IDE addresses during driver Init to get the UltraDMA address for a controller. That says BOTH a PCI and EDD scan are needed during driver Init! A BAD omission by the EDD BIOS people, back in 1998! > How widespread is support for EDD 3.0? Virtually all PC BIOS programs have supported V3.0 EDD, since 1998 when it was released. My drivers demand 100% adherence to V2.0C+ PCI and V3.0+ EDD specs, if UltraDMA is to be used. XHDD/UHDD handle disks and controllers that do NOT follow the specs with "Call the BIOS" logic, which normally means slower PIO-mode or "substandard" BIOS UltraDMA. Jack R. Ellis > I spend more or less all day to make this 'read to XMS' trick work, > but only managed to trash the maschine. > > I'm probably just doing something stupid wrong, but can't find it. Maybe there simply is a bug in the BIOS of your virtual machine? RBIL only says that you have to make the normal buffer pointer ffff:ffff and change the packet size from 10h to 18h if you want to use a 64 bit linear address (packet offset 10h) instead. I assume you have locked your XMS handle to a fixed linear address and noted that address as the linear buffer location the usual way. Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
