Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!latcs1!stephens From: stephens@latcs1.oz.au (Philip J Stephens) Newsgroups: comp.sys.apple2 Subject: Re: Fast reading of floppies... Message-ID: <7400@latcs1.oz.au> Date: 11 Mar 90 14:39:52 GMT References: <14075@fs2.NISC.SRI.COM> <14076@fs2.NISC.SRI.COM> <90069.141109BRL102@psuvm.psu.edu> Organization: Comp Sci, La Trobe Uni, Australia Lines: 24 In article <90069.141109BRL102@psuvm.psu.edu>, BRL102@psuvm.psu.edu (Ben Liblit) writes: > > There is a last, rather creative tactic that I believe (I could be wrong) was > used in the old Locksmith Fast Disk Backup. [details deleted] This is just the tip of the iceberg in regards to how Locksmith copies disks so fast. It actually pretends that the sector has been stored in a different (but similar) format to the 6&2 encoding actually used. I can't remember exactly how it interprets it as it's been ages since I peeked at the raw code. However, it does compress it back into 256 bytes (which is why it can copy so many tracks at one time), but the data is scrambled. It turns out that this scrambled data can be re-converted back into the 350 odd disk-bytes _quicker_ than the 6&2 encoding scheme; in fact, it can be done on the fly. Hence Locksmith can write at maximum speed. Why then, don't we use this alternative scheme rather than the 6&2 encoding scheme? Again, I'm not 100% certain due to time eroding my memory bank, but I think you'd have to scramble the sector in RAM before writing it, and hence you lose the speed advantage. That's probably crap, though :-) < Philip J. Stephens >< "Many views yield the truth." > < Hons. student, Computer Science >< "Therefore, be not alone." > < La Trobe University, Melbourne >< - Prime Song of the viggies > <\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>