Re: Apple ][ plus 13 sector! Problems...

[pausch@saaf.se (Paul Schlyter)]

In article <1gh55xq.ad72g01oor7z2N%dempson@actrix.gen.nz>,
David Empson <dempson@actrix.gen.nz> wrote:

> "Bill Garber" <willy46pa@comcast DOT net> wrote:
> 
>> Thank you David. I really must take some time
>> and read through all these books. After all,
>> I did buy them to learn from. What programs
>> can I use to convert a 13 sector disk image to
>> a real disk?
> 
> No idea.  I haven't done anything signficant with emulators.  I only use
> the real thing. :)
> 
>> From what you wrote above the 16 sector controller should be
>> able to still write one?
> 
> Yes.  The 16-sector controller (and the 13-sector one) can write
> anything, even disk bytes which can't be read back by the same
> controller: any 8-bit data pattern is possible, but if the written byte
> doesn't follow the rules, it won't read back reliably (or at all).  You
> can even write mistimed bytes, by waiting longer than 32 microseconds
> between writes.  (I'm not sure what would happen if you waited less than
> 32 microseconds - probably get a partial byte followed by the next
> byte.)

Most likely, yes.  What happens when writing to disk is this: once writing
is turned on, bits are written all the time.  They're taken from an 8-bit
shift register, and as the bits are used up, zero bits are poured in
from the other side of the shift register, unless the 6502 explicitly
writes a new value into the shift register.

So to write bytes in a controlled way to the disk, the shift register must
receive new contents from the 6502 every 32 clock cycles.  If the shift
resiter is updated too quickly, parts of the previous byte won't be
written to the disk but will be lost.  And if the shift resiter is updated
too slowly, extra zero bits will be written to the disk.

And that's the way the FF self-sync bytes/nibbles are written to the
disk: the 6502 fills the shift register with an $FF every 40 clock
cycles instead of every 32 clock cycles -- this will produce those
two extra '0' bits after the eight '1' bits.  Actually, any byte on
the disk can be made a "self-sync" byte in this way -- those two
extre '0' bits at the end of the byte will be invisible to the normal
disk read routines.  The book "Bag of tricks" had an accompanying
diskette which was "copy protected" in this way: some bytes in the
address field had those extra '0' bits at the end, and the utility on
that disk checked for the presence of those extra '0' bits (this is
done by, instead of the normal looping until the hi bit read is '1',
read the next byte a suitable fixed number of clock cycles after
reading the previous byte, and then check that the hi bit is '0').
Sure, the disk could boe copied with any normal DOS 3.3 disk copy
utility, or with Locksmith, Nibbles Away, etc, but the copy would not
work since that check would fail on the copy.

So you can write anything to the Apple II disk -- but you won't be able
to (reliably) read anything back from it.

> Copy protection techniques have been known to pull these sort of tricks,
> and use other tricks such as timing measurement to determine whether the
> disk has been written with the correct special rules.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/