Re: Hardware musings

["Michael J. Mahon" <mjmahon@aol.com>]

Ed Eastman wrote:
> Michael J. Mahon wrote:
>
> > It is not possible to know that a disk is "normal" except by doing
> > "sufficient" testing, which is beyond an algorithmic procedure.
>
>
> The normal flag is for regular disks like data disks or kracked stuff or 
> whatever.

Right--I wasn't thinking of the "a priori" normal case.

> > It is always possible that a program tests for a condition which is
> > a "don't care" in a normal disk, but which is fully specified in the
> > "original" disk--in fact, this is a fairly sophisticated scheme of
> > copy-protection.  ;-)
>
>
> Yes but we copy the entire bit stream regardless.
>
> > Such a track could appear to have virtually any length--in fact, if
> > the nibbles were written in isolation with the rest of the track
> > written as 0's, then the track would appear to be *almost* completely
> > random--it would be easy to miss the short "magic" pattern in the
> > sea of random nibbles.
>
>
> Not if one evaluated the boot procedure.  Besides, the EDD card would 
> see the pattern as well as Copy II+ hires disk scan...

And this "evaluation" is a human or human-driven process, since it is
indeterminate when the program will actually do the verification.
(Sometimes it's well after boot time.)

> > What exactly is the purpose of all the checksums?
>
>
> Someone suggested that the current files were subject to corruption 
> during transmission or the occasional twiddled bit.  I agree and think 
> you should consider checksumming each track so you know where the issue is.

No, since a file transfer is either good or not (much more likely to be
good), it is quite sufficient to simply checksum the whole thing.

The only rational recovery in case of a bad transfer is to re-transfer
the file, which will almost certainly fix it unless it's bad at the
source.

> > > I also noted that unless quarter tracking on a spiral, no disk will 
> > > have tracks closer than .75 tracks away.  or a total of 48 tracks 
> > > stored assuming you used quarter tracking between 35 and 40.
> >
> >
> > And again, the problem is knowing when data is relevant and when it
> > isn't.
>
>
> But you can tell a spiral disk from the sound...  It is SOOO obvious.

And that is human observation, or one made *after* the image is created
by observing program behavior.

> > Maybe I sholdn't worry too much about file size in this day and age, but
> > a 6x or so expansion over a normal image does seem a bit severe,
>
>
> No worries unless it is a spiral disk. Those images promise to be up to 
> 512k in size!  (39x4 +1) x 6.25k

That's exactly what I'm thinking--and there's no foolproof way to
avoid saving that unless the image creator already (correctly)
understands the protection.

Given the problems with unusable images, I'd rather take that choice
element out of the equation.  Storage is cheap and getting cheaper.

> But assuming the disk has ever been deprotected or even monitored while 
> booting, the protection routine will be known and where it is at.  Most 
> protection schemes rely on data inserted between normal sectors that 
> does not get read by normal copy programs.  The bit steam format catches 
> all of that.

Again, I think we'd all be better served by a format that didn't require
*any* knowledge of protection schemes (lest it be absent or incorrect).

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."