Re: Disk Muncher

[lyeoh@pop.jaring.nospam.my (Lincoln Yeoh)]

On 19 Feb 1999 08:53:55 GMT, mjmahon@aol.com (MJMahon) wrote:

>My guess is that everyone has already made up their mind
>about Disk Muncher, but...
>
>Digital data is frequently copied many times in the course of
>its use, and the design of _any_ copy utility should aim to
>perform copying _absolutely flawlessly_, within the limits
>of the technology.  This is why any copy program should,
>by default, read back copied data and verify that it is
>identical to the original if there is any possibility of an
>error (as there is on disk).

I suspect checking of trailers and checksums was disabled in order to
backup/copy copy protected software, not to speed things up. 

Not checking things does not speed things up, because you still have to
wait for the disk nibbles to spin around.

If you cannot make a single copy because the checksums/trailers/headers are
intentionally nonstandard, then you usually switch to a copy program which
can deal with that. Even if it makes one bad copy out of 100, it's better
than making zero copies out of 100.

Because of the Apple II disk system design there is no easy way to make
sure the nibble data is identical from within a standard Apple II system.
Some systems didn't even use the usual 10 bit FF syncs, you could do have
11 bit ones maybe even 12 bit. e.g. instead of using the following to
synchronise 
1111111100 1111111100 1111111100 1111111100 1111111100 
you used
11111111000 11111111000 11111111000 11111111000 

If you know what you were looking for it's fine but trying to find and
recreate these patterns for perfect copies was nontrivial given that the
6502 was running only at about 1MHz. 

Cheerio,

Link.
****************************
Reply to:     @Spam to
lyeoh at      @people@uu.net
pop.jaring.my @ 
*******************************