Date: Sat, 12 Nov 2005 17:47:47 -0600 (CST) From: [EMAIL PROTECTED] Subject: Re: [LIB] 110CT Large Drives with EZ BIOS...
Thank you Philip Nienhuis for offering extended rational information relative to the operation of Scandisk and FAT's. I am ignorant to these areas. The only chip-level progamming and process I have experience with is with old Commodores Vic 20's and 64's. Modern FAT's, Hard Drive or other BIOS, is pretty much a mystery to me. Thanks to everyone who has offered information, theory and experience. :) John Martin ======================================= > Date: Sat, 12 Nov 2005 23:43:59 +0100 > From: Philip Nienhuis <[EMAIL PROTECTED]> > Subject: Re: [LIB] 110CT Large Drives with EZ BIOS... > > [EMAIL PROTECTED] wrote: > > Date: Sat, 12 Nov 2005 10:09:52 -0600 (CST) > > From: [EMAIL PROTECTED] > > Subject: Re: [LIB] 110CT Large Drives with EZ BIOS... > > > > Hello Raymond and thank you for your reply... > > > > I was amazed at how this topic was discussed so much over the years with no > > real end result that I could determine. It took many days to read the full > > archives. The BIOS HDD <8.4 seems like a simple thing. Sort of a Yes/No to > > me. A "No" of course is not what I wanted to hear. Also because much of the > > information did not apply to the 100/100 directly I hoped it might be outdated > > at least for these last two CT Models. > > > > I will gladly accept the "No" at this point. :) > > > > This all leads back to a previous question however... > > I have allowed this computer to hibernate a number of times now since safely > > duplicating the drive. The drive is full less 1/2 gig or so free. I opened > > up a number of browsers and spreadsheets etc to make certain the memory would > > have been completely full when written to disk. > > I realize that Scandisk is NOT a high level tool, but I simply can not believe > > it can't find a 64meg damaged spot on the hard drive, which hibernation should > > have caused. Is it inaccurate to believe Hibernation should have blown the > > formatting, data, everything on that area of the disk? > > Any idea? > > (As an aside: the "damaged spot" it is not just 64 MB but rather 64 MB > RAM + 2 MB video RAM + BIOS data) > > As regards scandisk: Damage assessment depends on where the crucial disk > organization data are stored (i.e., tables with pointers to clusters > containing file fragments). On FAT(-32), this is usually at the start of > the partition. As long as those pointer tables (File Allocator Tables) > are intact, scandisk simply won't notice that the actual cluster > contents are blown to pieces. > You know, scandisk won't inspect a cluster that is in use by e.g., some > .xls file to check if that cluster contains valid Excel data; it just > checks that the cluster chain itself (in the FAT) is still complete and > its beginning is attached to some file descriptor somewhere in the FAT. > IOW, the very contents of data clusters is not quite scandisk's affair - > it won't even look at the data area proper (unless you instruct it to do > a surface check). > > While FAT32 may be a bit more complex than FAT16 (or FAT12), this must > be largely the explanation you seek. Even if there are aditional FATs > elsewhere on the partition, as long as these have not been touched > scandisk won't ever notice problems. > > Other file systems (NTFS, HPFS (OS/2), ext2 / ext3 (Linux)) have their > crucial data areas scattered over the entire partition, so they are much > more vulnerable and data corruption would be noted much easier. > > BTW As Raymond wrote, there has been considerable debate on the merits > of various disk overlays. Even an otherwise very (IMO) knowledgeable & > prominent Lib user (dr. Xin Feng) once believed that some Maxtor overlay > (MaxBlast III) would finally fix the BIOS hibernation of Librettos > 100/110CT. Alas, he was corrected all too soon..... > > I think the BIOS hibernation routines might be patched (at least > theoretically), but it would take considerable disassembly efforts of > some very knowledgeable guy to come up with a BIOS "upgrade". I once > tried a similar thing on an ancient AT-like desktop, but although I > could recognize a lot from IBM BIOS sources in the AT tech ref manual, > after a week I had to give up - it was too complicated. Now the Lib110 > design date is about 10-12 years later than that desktop and is thus > much more complicated - so I think there's little chance that anyone > will ever be able to succeed. > > Philip > > >
Attached files are not permitted on this list, attachment has been removed.
