Hi, I have been thinking about an extra tool for LBAcache: hook "int" 25/26 (or the FAT32 equivalent int 21.7xxx function, or all), for ONE drive. That drive must not use int 13 BIOS disk access. For all calls, call int 13 LBA functions, using the linear sector number from the call and a fixed imaginary disk number like 0x87 (and allocate that number in some way, testing int 13.4100.55aa / 13.08 / 13.48). Hook int 13 with an handler which answers to int 13.4100 / 13.08 / 13.48 (disk info...) queries and which calls the ORIGINAL "int" 25/26 functions for that ONE drive in question when asked to do LBA read/write with the imaginary disk number 0x87.
So far so good and simple... If you would use it for an int 13 based disk, you would get reentrant calls to int 13 in some way. So it is only for other drives. Ramdisk caching is not useful (but there are smart caches which can use the free space on the ramdisk as cache space: COMBI does that, by implementing both ramdisk and cache in one program!). Network drives will often be redirector based, not int 25/26, I assume? So only special non-int 13 FAT drives are interesting here. Do ZIP drives or USB drives fall in that category? Is caching them useful? If so, we have a problem: FreeDOS does not use int 25/26, it only PROVIDES it. Internally, it accesses the disk driver devices directly, so you cannot hook int 25/26 as described. Is that correct? Should that be fixed (are there disk types which should be cacheable as described)? Do you know other DOS software which has to hook int 25/26? It seems that SMARTDRV hooks both at int 25/26 and at int 13 level, so it can still cache DOS access? If not, it would only be able to cache direct int 25/26 access, as used by disk tools like defrag or chkdsk... Of course there are always workarounds. You could load the hook tool like a ramdisk, to create a NEW drive letter which is a cached version of some other drive letter. But then you might get inconsistency - concurrent file- system modifications can happen. Please comment :-). PS: In case it was not clear from the above - after loading the hook tool you can load LBAcache, and it will detect and cache the (virtual) LBA harddisk 0x87 and thereby indirectly cache the drive letter which got hooked. DOS -> int 25/26 -> device driver is the normal case DOS -> int 25/26 new -> int 13 disk 87 -> int 25/26 old -> device driver is the hooked case. That case allows LBAcache to hook the DOS drive like a lowlevel LBA BIOS drive, by hooking int 13 as usual (int 13 call -> cache handles access in XMS and/or forwards to original int 13 handler). Eric PPS: Please let me know on which list this thread should continue. Notice that up to "8 - number_of_actual_int13_harddisks" drive letters can be cached. I think INTERSRV/INTERLNK are raw sector based (int 25/26, not network redirector), too, so they are cacheable candidates... but then, if you have INTER*, you will also have SMARTDRV!? ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
