Hi Gerald! > I'm a brazilian user of freedos and I use lbacache and > cdrcache in my config.sys. > Is it possible merge lbacache and cdrcache in only one driver > like smartdrive?
Well... it is not completely impossible, BUT... - harddisks / floppies use 0.5k sector size, while CD-ROM uses 2k sector size. - harddisk / floppy caching happens by intercepting BIOS calls while CD-ROM caching happens by creating a virtual CD-ROM driver which forwards requests to the real driver if the data is not found in the cache - both caches use XMS memory and some kind of table to store cached data and for bookkeeping of which data is in cache - both caches use basically the same code for some basic functions, but lots of the code is still different - CDRcache must act as a device driver and has to be loaded before SHSUCDX - LBAcache can be loaded and unloaded from both config sys and the command prompt. While CDRcache uses "echo ... > cdrcach$" to receive user commands, you run the LBAcache com binary to control LBAcache. So there are some parallels but on the other hand there are many differences. You can assume that apart from being able to use the same XMS area, a combined cache would not use considerably less DOS memory than loading both caches separately does. In addition, if your UMBs are slow (happens if you use UMBPCI, http://www.uwe-sieber.de/ to create hardware UMBs, for example because you have compatibility problems if you would use EMM386), access speed can drop quite a bit if you load the cache into an UMB. On my system I therefore load the LBAcache into low DOS memory but keep CDRcache in an UMB (because CD-ROM is slow anyway, and I want to keep more low DOS memory free). UMBPCI.TXT tells me that a 4 MB sized SMARTDRV would take 16k low DOS memory and 20k UMBs (if you use 8k element size and 16k read-ahead buffer, defaults) or at least 2k low DOS memory and 16k UMBs if you use 2k read-ahead and 1k element size. Note that LBAcache does NOT have builtin read-ahead. You load the read-ahead SEPARATELY as TICKLE (by default it only enables FLOPPY read ahead, but you can activate HARDDISK read ahead with hidden options. Mail me if you want to play with that feature. Read-ahead using TICKLE only helps if you are caching the drive with LBAcache as well. Load LBAcache before TICKLE). This allows you to load TICKLE into low DOS memory while loading LBAcache into UMBs - can be useful if ISA-DMA (floppy...) is not supported in your UMBs. With SMARTDRV, you would have to load the double-buffering feature for that. LBAcache itself never needs double-buffering. Only for TICKLE you may be forced to load it into low DOS memory if UMBs do not support ISA-DMA. As told, you still may want to keep LBAcache out of slow UMBs to make it faster. For the SMARTDRV case, read-ahead must be at least 2x the element size and if you use CD-ROM caching module (which adds several kilobytes to the size of SMARTDRV in RAM) the element size must be at least 2k. LBAcache uses 4k element size: Bigger elements mean smaller table, smaller size in RAM and faster access BUT they also mean more chance of caching a smaller number of useful sectors in certain situations. Maximum value is 8k, minimum useful value is 1k. So the possible range is the same as with SMARTDRV, but the default is 1 step smaller (4k, not 8k). If you want to experiment with some other element sizes, please mail me. You cannot change the element size on the command line, so I would have to send you binaries with other element size configurations compiled in. If you would like to test the effects of read-ahead for harddisks, let me know how the current settings perform for you (after mailing me to ask how to enable them...) and we can try to figure out faster settings. Maybe I will eventually make the read-ahead more public then... To get back to your question: Sorry, but merging LBAcache and CDRcache into one binary is not planned for now. For comparison: LBAcache takes (at 4k element size) 5300 - 64200 bytes of DOS RAM (low or UMB, depending on whether you use DEVICE or DEVICEHIGH / run it directly or run it with LOADHIGH) and 0.25 - 29 MB of XMS. For each megabyte of XMS more cache size it uses two kilobytes more of DOS memory. This means 13k for 4 MB cache size, less than SMARTDRV would use. But of course it does not include CD-ROM caching. CDRcache takes 5500 - 18000 bytes of DOS RAM (low or UMB, depending on whether you use DEVICE or DEVICEHIGH) and 0.25 - 24.75 MB of XMS. For each megabyte of XMS more cache size it uses half a kilobyte more of DOS memory, which means 7.5k for 4 MB cache size. In total you get (with 9-10k of TICKLE for floppy readahead) 29k of DOS memory and 8 MB of XMS compared to 27k of DOS memory and 4 MB XMS (maybe more, do not know if the 27k include CD-ROM caching) when using SMARTDRV with 8k readahead / 4k element size configuration. And of course you get 4 MB more cache with LBAcache + CDRcache :-). But maybe this is exactly what you want to avoid by asking for a MERGED cache. In that case: Bad luck, this is not planned for soon. Next planned features are: - configurable element size if this is proven to be useful - configurable harddisk readahead if this is proven to be useful - delayed-write caching (not that I would be very interested in USING it: It adds insecurities because if your PC crashes before all delayed writes have been "forwarded" to the real disk...), because of the technical challenge. I already have some interesting plans for that, but would need some bench- mark results with certain NWCACHE configuration for tuning first. AND I would need enough "time in which I am bored enough to start with the challenge" :-) - better FLOPPY SIZE detection (probably the FIRST thing which I will do), including proper 1680k floppy processing. Current versions MIGHT miss floppy size changes (if you use e.g. 720k floppy in 1440k drives) which can cause data corruption on the floppy (or the wrong data to be read from the floppy) in CERTAIN situations. Note that floppy caching is off by default anyway. Happy caching! Eric. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
