Hi! To put it in un-technical terms, I am talking about a block device driver which tells the kernel "hey here is a nice FAT partition, 512 bytes per sector" but when a DOS kernel asks the driver to read or write sectors in that partition, the driver will actually access a 4096 byte per sector disk. If the kernel wants to read the 20th sector, this driver will fetch 512 bytes from a place inside the 3rd 4096 byte sector instead etc. It will probably talk to some ASPI, SCSI or USB driver which makes the 4 kB / sector disk accessible as-is.
The "shimmy" thing on such a transforming block device driver is that it uses a small buffer to translate small access to access to part of a big sector and that it also transforms a few values in the boot sector and BPB to reflect sector size changes. As a bonus feature, it could parse a GPT partition table even when the kernel can only parse MBR partitions :-) A very nice starting point for Bertho / Czerno for writing a block device driver would be RDISK from the drivers of Jack (same download as UIDE / XMGR, includes source and binaries) which is only 700 lines long :-) RDISK is a FAT16 RAMDISK up to 2 GB in size, using XMS 2 or 3 depending on disk size :-) RDISK has flags 0802, a SIMPLE block device with open/close and 32 bit sector numbers. The 2 GB size limit comes from a maximum "classic" cluster size of 32 kB and the FAT16 limit of max 64k clusters. FAT12 / sizes below 32 MB differ a bit. Geometry & partition offset are ? x 255 x 63 and 0, ignored. Implemented command codes are 4 read, 8 write, 1 mediacheck, 2 build-bpb, 9 write-verify, 0d open and 0e close. Function 1 just always says "disk not changed", 2 points the caller to the BPB of the ramdisk (made when you load the disk) and open and close basically do nothing but say "thanks, done". Finally, function 0 is of course supported to init the disk. The Assembly sourcecode is a bit hard to read, very compact. Note that for FAT32, you have to support more complex BPBs. For changeable disks, you also have to support function 0f. Functions 13/19 (hex) ioctl/check have cat 08/48 for disks. Functions 17/18 get/set logical device are for messing with drive letter assignments a la "one floppy can be A: or B:"? See also int 2f.0802 and int 21.440d in RBIL about IOCTLs: You can set/get drive params and serno, write/format/verify tracks, use the "access flag", lock, eject. In DOS 7.x you can even locate swap, list open files, or drivers. Many of those functions are interesting for floppy and formatting, but less interesting for most "everyday" work with drives. Regards, Eric >> Questions of licence aside, is that so? I was under the impression >> that a general transformation driver would simply load a different >> block device driver (here: DI1000DD) to interface with, downwards. > > You and Eric are discussing it in "general" technical terms, i.e., > not talking about what the "downward" side is (ASPI, INT 13h, a > "shim" between a non-compliant kernel and a device driver, etc.). > Bertho is talking about a specific (USB)ASPI implementation. PS: It MAY also talk to int13, if that supports 4 kB/sector. A "classic" kernel will have problems with such disks, only a modern kernel could use int 13.48 to detect a large sector disk as such and then either use or skip it, depending on a limit of "acceptable" sector size (maybe set via config.sys) and depending on whether it supports other than 512 at all. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
