Hi, I found that FORMAT and SYS need support for function
int 21.440d.0860 (for FAT32: int 21.440d.4860) to find out
the BPB contents. This function is not supported by ASPIDISK
when you use USBASPI4, and it is not supported by some RAMDISK
drivers. Other drives can be affected as well, maybe ZIP?

One work-around would be to make SYS and FORMAT fall-back to
reading the BPB from the boot sector if the GENIOCTL call for
21.440d.... fails, but I would prefer a generic solution in
the kernel. Extra problem: ASPIDISK reports device attributes
68c2, so it CLAIMS to support genioctl, but still FORMAT is
not happy about the support. Ideas / Comments?

PS: TDSK has device attributes 0800 (can be more than 32 MB)
... uhm, no, "open/close/removable_media" calls ... And XMSDSK
has attributes 6002: ioctl, non-ibm, can be more than 32 MB.
The non-ibm (see table 01648 in RBIL) means that device call 2,
build BPB, will not return the first FAT sector in a buffer.
This simplifies XMSDSK code... For the abovementioned BPB query,
device call 13 (hex) would have to be supported.

Argument PRO kernel support: Block devices are always FAT
devices, so simulating call 13 for drivers which lack this
feature does not hurt (but do not forget to suppress critical
error handling and reject implausible boot sectors).
Argument CONTRA kernel support: There are not too many disk
tools which can get unhappy about lacking int 21.440d.0860 ...
(my excuses if I missed some SYS update which adds USB support).

Eric

PS: See RBIL table 02595 for device driver command codes.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Freedos-kernel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Reply via email to