Hi Johnson, thanks for posting the error message! Analysis: LBAcache *newbin* in binsel2.asm seems to suggest allocating cache slots beyond the end of the cache sometimes (you used a 2 MB cache, I guess), you got attempts to copy data TO cache 16, 48, 80 and 176 sectors after the actual end of the cache (10, 30, 50 and b0 hex), each for a whole element of 16 sectors. Luckily you only got DOS->XMS errors and no DOS<-XMS errors, so LBAcache never tries to read "cached" data from the void.
I think I can fix this bug - which got introduced in the "more speed" update earlier this month (6/2004) - by letting newbin always do a fresh calculation of the "search start position of 16(element)-way associative cache allocation". The bug seems to be that newbin uses cached results from findbin, but findbin would NOT update this variable if the relevant bin was found using the 256+1 entry memoization table. The STRANGE thing is that "if findbin DID find a bin, then newbin just fills that bin MORE - it should NOT allocate a completely fresh bin then". I have to look closer at binsel2.asm, maybe the bug is something else. Anyway, thanks for providing the error log. Oh, wait... > DOS<-XMS.1057 In one of the many accesses, LBAcache failed to return data when Cubic Player tried to read from disk. The error was not reported to Cubic Player, only on screen. This only happened in the "disk read" which directly read back data which was supposed to be written to disk and cache just a moment before (still in the 1 "most recent" element of the memoization...). LBAcache has failed to copy the data to cache, so reading back the data must have failed, too. I think this is because in *findbin* the other 256 elements of the memoization table are overflow protected - not sure if the search algorithm for the rest of the cache can get affected by the new bug, BUT 256 elements are 2 MB and you only tested with a 2 MB cache - so only (much) BIGGER caches could get overflows in findbin outside the memoization trace, and only for access patterns where the memoization strategy is not fully successful. Thanks again for the log... Eric. ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
