I don't have a way to test, but in general agree with your assessment of the
situation. 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. 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.
Optical media (CD/DVD/BD) has always had 2048-byte sectors, and modern hard
drives have 4096-byte sectors. > PS: Any experiences with int 13 function 50 for
> USB or FireWire "packet command" BIOS support? I'm not familiar with
> FireWire, but am pretty familiar with USB. The description of INT 13.50 in
> RBIL is, at best, incomplete, and doesn't contain enough information to even
> try and test it. INT 13.50 is part of Phoenix's Enhanced Disk Drive Spec
> v3.0, available here:
> http://www.o3one.org/hwdocs/bios_doc/bios_specs_edd30.pdf With respect to INT
> 13.50, the spec says this (in addition to what's in RBIL): "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. When an operating system takes control of the serial
> device controller it takes the hook for this service to provide a seamless
> transfer of control from the BIOS to the operating system. This service
> allows several BIOS level services to continue functioning, even after the OS
> has taken control of the 1394 controller, as follows:
The INT 13 mass storage interface
Power Management
Suspend to disk
The BIOS is a single threaded, master device. This means that the BIOS will
not process asynchronous requests from other devices. The BIOS will send
commands to devices and wait for responses. This means that the operating
system can take control of the serial interface with no hand-off information
from the system BIOS. The operating system will reconfigure the interface and
hook the service described above. The system BIOS provides INT 13h Fn 50h for
both the 1394 and USB buses." In other words, once the Operating System (DOS)
has taken control of the device, if it wants the INT 13h functions to continue
the OS must do it itself since the BIOS only provides this service long enough
for the OS to boot. In addition, I don't even think an OS would normally need
to send a special packet request to a disk since it should be able to obtain
all the information it needs from the disk using other INT 13h functions. In
addition, the spec seems to have been written before it understood exactly how
USB works, and it really won't work as it is with USB devices. I won't go into
a lot of detail here since it's complicated, but in order to send data back and
forth to USB devices takes three transactions, and INT 13.50 doesn't address
where or how to transfer the data. Again, it's complicated, but just suffice
it to say that it won't work the way I think you're hoping. 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 if that is needed for some reason. INT
13.51 is based on (and similar to) ASPI, though isn't exactly like ASPI since
it's specifically directed at INT 13h disk functions (ASPI/SCSI can handle lots
of different types of devices other than disks). I don't know if that's helpful
to anybody or not.
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
