Hi Bret, thanks for sharing your thoughts on this.
> If the FreeDOS kernel (including the BUFFERS) and most of the utilities (like > caches) > assume 512-byte sectors without even bothering to check, it's going to create > problems. This is a problem, but in part distinct from the LBACACHE one: It has been a long-standing feature request to support FAT disks with different sector sizes, but given that FreeDOS does not, LBACACHE would normally not have to worry about it. My problem is that ELTORITO creates the possibility to have a non-FAT, but BIOS-supported drive (which in fact represents the contents of a CD/DVD) and I see a risk that LBACACHE would try to cache it. > It's quite possible that it has caused problems and nobody has recognized > it or thought it was something else, especially since you normally don't > write to CD's but only read from them. As sketched in my previous mail on the topic, the risk (ELTORITO does not let you write to CD anyway) is that cache hits will return wrong data: When you read a sector from the CD, my cache will only copy the first 512 bytes. Now read the sector AGAIN and the cache will return the cached 512 bytes and claim that you have received all data, which is not the case, you are still missing the trailing 1536 bytes of it. So if the problem really triggers with ELTORITO and LBACACHE then it should be quite easy to notice, even while just reading a few random files from your CD more than once. > The description of INT 13.50 in RBIL is, at best, incomplete, and > doesn't contain enough information to even try and test it. Indeed. > http://www.o3one.org/hwdocs/bios_doc/bios_specs_edd30.pdf > "This function defines a service that the system BIOS will call for > sending data to and from a serial packet oriented device. The BIOS > will provide this service before the OS is loaded. That does not sound very specific either? Do you think it would allow to create hardware-independent USB/FireWire drivers with BIOS support, of course with limitations? The part where you say that other drivers can provide int 13.50 FOR the BIOS, to keep it working when they take over the USB/... controllers, seems interesting. However: > spec seems to have been written before it understood exactly how USB works :-p > In my USB disk driver, I'm adding a new INT 13.51 function to provide > a "complete" way to send special packet commands to a USB disk... Is that an official API or your own design? Regards, Eric _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
