Hi, there is an occasional problem with LBAcache disk detection, maybe you can help finding out more. It happens on SCSI systems, possibly related to UMB usage, loading LBAcache to UMB, or having an UMB collide with memory ranges used for SCSI or network BIOS or memory mapped IO. Symptoms: Drive detection takes long and no drives are detected. LBAcache will just display that it is scanning for drives, and then display [done] without showing that it has found drives before. LBAcache STAT will confirm that no drives are cached.
This is supposed to be in setup.asm, findnextgeom: ... alldrives: label somewhere. Used int 13 functions are int 13.4100.55aa.dl (returns AX BX CX DX) for LBA detection and int 13.08.dl (returns AX BL CX DX ES DI) for geometry detection. The 40[75] disk count is not checked, and some BIOSes seem to return wrong "number of drives" values for int 13.41, but LBAcache only checks the returned BX magic and CX flags, not the AH/DH/DL information. RBIL recommends using 40[75] or int 13.15 if int 13.41 or int 13.08 are unreliable - I am trying to avoid that. (int 13.15ff.cx=ffff.dl returns AH (or AX!) as 3 and NC flag if harddisk, and size CXDX...) The used int 13.08.dl call returns AX BL CX DX ES DI, but ES DI are ignored, only carry and DL and geometry in CL (CX) DH are used. BL is floppy type, not interesting for harddisk, DL is drive count (LBAcache assumes that ONE drive is missing if int 13.08.dl returns a DL of 0 for THAT drive). When the bug / problem happens, LBAcache drive detection takes quite long, finds no drive, and it can happen that the scanned drives, even CD-ROM ones, spin up. It seems that it always solves the problem to load LBAcache low (not into an UMB). This is strange because LBAcache has no internal buffers - the SCSI BIOS does never see pointers to LBAcache code segment except for the disk read/write (where a data structure describing which sectors should be accessed is created on local LBAcache stack: The sector contents themselves, however, are not stored in LBAcache memory. Instead, they are copied between the caller's buffer and XMS directly...). Would be nice to know what is going on here, so if you know how to use a debugger and have a SCSI system, please help. PS: If you load LBAcache to UMB and nothing AT ALL happens, then you had an UMB area which was 7..10k in size, and the UPX decompression stub found that it would be impossible to work (-> it did "int 20", exit to DOS, at once). To avoid such problems, de-UPX the binary first. After initialization, the smallest possible LBAcache (128 kb :-)) will only take 5.5k of RAM, because things like the command line parser are dropped from memory for the TSR instance of the cache. A normal 2 MB cache takes slightly above 7k. Eric. ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
