Hi, I wondered whether I should remove eecho.com / syseecho.sys from the LBAcache package. Does eecho work well enough in current kernel and FreeCOM e.g. for a color setting eecho $[0;1;33;44m everything below this is yellow on blue (including the problems of case sensitivity and being able to do the eecho pretty short after loading nansi)?
And of course: I could leave eecho / syseecho in the package anyway, for those who use non-FreeDOS kernels and shells. Yet another kicking candidate is bootrand.sys: it hooks int 10 to set the border color to blue on mode change and to force yellow on blue color for int 10.9 (which MS kernel uses along with int 10.2 - FreeDOS kernel uses int 10.E instead). Bootrand also hooks int 21 to send some "I am already installed" type replies to functions 4bff (Cascade), DD, DE, E0 and E1. Very boring kind of virus protection for very few types of viruses. A FreeDOS VSAFE would not only check install checks but also suspicious calls in general (e.g. writing boot sectors or writing into files which are executables). An outlook to a possible LBAcache update: I might add associativity. LBAcache is quite well optimized for finding data on a cache HIT (it remembers the most recently requested "cache element" and a list of 256 most recently used elements (one for each hash value, so not exactly the 256 most recently used elements). But in the case of a cache MISS or if an unlucky (not recently used) element is accessed, a loop in binsel2 is executed at most [number of elements in cache] times: cmp eax,[si] / jz foo / add si,8 / loop [fail] foo: cmp dl,[si+4] / jz found / jmp (to beginning of this loop, as with "loop") Default element size is 4k (NWCACHE: 3k? 6k? SMARTDRV: 8k). Element size can be 1 / 2 / 4 / 8 k (as with SMARTDRV, but SMARTDRV element size has various side effects / bugs) and is a compile time option. I think about making that 8k in the future. Any experiences about how element size changes cache hit ratio in real life with e.g. SMARTDRV??? Another idea would be making the size a command line option. Whatever... a 16 MB cache would be 4096 elements of LBAcache so if you do something which is all cache misses, having the cache loaded gives you a penalty of > 16000 CPU instructions for each accessed sector. I think that can be quite a lot for systems with slow CPU and/or where the cache content table resides in slow, not well cached, DOS or UMB RAM. Opinions? By using associativity (as suggested by several people for quite a while) I would SPLIT the cache by hash: For example I could say "all sectors with an uneven hash key have to be listed in table entries with uneven index" Or I could even say "all sectors with a certain hash value (an 8 bit value) have to be in a certain area of the table which is reserved for only this hash value". The more I split the cache, the shorter is the chunk which I have to search for the right sector but the more I limit the ability of the cache to store many sectors with the same hash value at the same time. So: How much splitting would YOU recommend? Minimum cache size is 1/4 MB, which is only 64 table entries (elements), which would even be too little to give every hash value a single own table entry. For 8 k element size, it would be even only 32 elements. On the other hand, the table can be up to about 7000 entries (driver cannot be > 64k in DOS/UMB RAM, and with element size 4 k you do not reach that much for the max cache size of 99/4 (24.75) MB anyway). Splitting that into only even/oneven hashes would mean a cache miss penalty of up to something like 30000 instructions per sector for searching. The truth must be somewhere in between... Eric PS: I could probably make associativity depend on cache size, e.g. if it is a multiple of 1 MB then there are a multiple of 128 elements even in worst case... ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
