[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [Freedos-user] writing a loadable block driver for 4k-sector drive (Questions) Bertho Grandpied Tue Feb 21 14:01:39 2012

Hi, FreeDOS-devel !

Upon C. Masloch's harsh request\\\\\\\\\\kind invitation, I'm joining 
Freedos-devel now and shall continue this question here that started in 
Freedos-user. Apologies to anybody this change of venue may inconvenience.


On Mon, 20 Feb 2012 11:15:00 PST BretJ <[EMAIL PROTECTED]> wrote in 
Freedos-user :

> Bertho Grandpied wrote:
>> Therefore my first interrogation is, what set of device header attributes
>> - and associated functions, including IOCTL codes - must be present /at a
>> minimum/ for letting DOS access the disk properly ?

Bret wrote :
> FWIW, this is what is implemented in my USBDRIVE:
> 01h - Media Check
> 02h - Build BIOS Parameter Block
> 04h - Read
> 08h - Write
> 09h - Write with Verification
> 0Dh - Device Open
> 0Eh - Device Close
> 0Fh - Removable Media
> 11h - Generic IOCTL DOS 3
> 13h - Generic IOCTL DOS 4+
> 17h - Get Logical Device
> 18h - Set Logical Device
> 19h - IOCTL Check DOS 5+
> USBDRIVE is installed as a TSR instead of in CONFIG.SYS, so
> doesn't need or
> support Function 00h (Initialize).  I don't know if all
> of these are
> actually needed or not, but they are supported. 
(list of IOctls scrubbed for brevity, cf. Bret's original msg)

Well, OK Bret, but this doesn't tell what the minimum set would be (as you 
conceded). Are the IOCTLs and functions 17,18,19h required ? Since support for 
these features has to be marked by corresponding bits #7 & 6 of the driver 
attribute, it is conceivable that a driver might not provide it. Unless of 
course DOS refuses to use (old?) drivers which do not advertise these 
functions. Someone knows ?

> Bertho Grandpied wrote:
>> - Using a loadable driver for the block device implies DOS won't use /its/
>> internal buffers, so I don't have to care about DOS own buffers sizing,
>> right ?
> Wrong. 

Of course you're right, I wasn't thinking out well.

> The reason you're even doing this in the first
> place is because DOS
> _will_ use its internal buffers.  This wouldn't be
> necessary otherwise. 
> IOW, you should still check the max sector size in the DOS
> List of Lists
> before you install yourself to make sure it's 512 bytes, and
> should refuse
> to install yourself if it's already 4096. 

Uh, here I'm confused, not following any more, please elaborate your point. 
Assuming we've loaded  USBASPI.SYS [which provides ector access to the external 
disk using "SCSI" commands], my hypothetical driver wishes to support one or 
more FAT partitions on that external disk. Whether or not DOS has already 
increased its buffer size up to 4K before my driver loads from CONFIG, the 
driver had better be loaded or else DOS won't know to access the partition(s). 
IOW the role of the driver is not /just/ to inform DOS that it might have to 
adjust its internal buffer size, as you seem to be writing above; rather the 
main role of the loaded driveris to "augment" DOS by allowing it to well, 
read/write files and clusters and sectors to the disk, a feat DOS by itself 
would be incapable of (neither USB nor SCSI/ASPI existed when DOS was designed, 
so I guess we might pardon it).

 What am I missing of your above point ?

> The only way
> around this I know
> of is to install as an IFS (Installable File System /
> Network) driver,
> similar to how MSCDEX (and its clones) work.

> Bertho Grandpied wrote:
>> - Besides, should I consider using the "non IBM format" bit in driver
>> attribute ? From whatever docs I saw is unclear what "non IBM" changes
>> exactly in how DOS uses the driver, 
> None of the devices I've ever seen use the IBM format -- it
> changes the BPB. 
> Probably a dangerous road to go down.

Do you mean to say "non-IBM" ? UIAM again, the "IBM" (should be called "MS") 
formats are the usual FAT disks. IOW "non-IBM" is when attribute bit 13 = 1. 
See a difference in driver function 2 in Ralf Brown's list : FAT sectors aren't 
transmitted, does it mean a "non IBM" disk may be non-FAT ?
Again, I'm curious if anybody has experience with this unusual case.

WHATEVER... Interestingly Novac's DI1000DD.SYS driver has attribute = 68C2 (or 
68C0 for disks under 32 Megs). Yes, it's "non IBM" whatever that means!



Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
Freedos-user mailing list