Re: Apple II version of Activision's H.E.R.O.

[Andy McFadden <fadden@fadden.com>]

Mike OMalley <m.SPAMNOomalleyNOSPAM@cqu.edu.auspammenot> wrote:
> Some of the people are using as ][GS, which I can't comment on - I've never
> used a real ][GS.
> 
> All of my transfers have been done on an old Apple ][c.

Shouldn't matter; the IIgs slows down to 1MHz the instant you turn the
drive motor on.

>>I expect that SST doesn't verify that the rotational speed of the target
>>disk will allow it to actually hold 6656 nibbles, and therefore overwrites
>>part of the track on a fast drive.
>>
>>If that's the case, then setting a drive a little slow ought to make it
>>work...
> 
> Maybe my ][c's drive(s) are a little slow.

Most drives will hold $18xx nibbles, where xx is just about anything.
They rarely go above $1900.  6656 is $1a00, which was chosen because it's
bigger than any reasonably expected track.  However, that doesn't really
matter: there's no way to get an index marker out of a Disk ][ drive,
so you have to read the track for a while to get the self-sync bytes to
latch, then over-read, then analyze the track to figure out where the
old and new data overlap.

The fun part is the self-sync bytes.  If you structure Disk ][ I/O code
correctly, you have just enough time to store the data you read plus
an indication of whether it's a normal byte or a self-sync byte.  You
can't tell the difference between 9-bit and 10-bit self-syncs unless
you're reading a large field of them, but in most cases that doesn't
matter.

The .NIB format doesn't record self-sync bytes, which makes it useless
for copy protection schemes that measure byte timing.  (The FDI format
is the only one that's useful here, but it's not likely to be widely
supported by emulators.)  However, emulators don't need self-sync bytes,
because their nibble data is always byte-aligned.  "Normal" I/O routines
don't check for their presence, so in most cases this works fine.

This aspect makes converting .NIB back to a real disk tricky, because you
have to "create" the self-sync bytes by guessing where they should be.
On a lightly-protected disk this is easy, because you can look at the pile
of FFs before the D5 AA 96 and D5 AA AD patterns and just assume they're
all self-sync.  If you can't find the address markers, though, it's hard
to know where the sync bytes are.  This gets worse because the easiest
way to find the address markers is to grab the bytes that come right
after a large self-sync field.  It's tough to get one without the other.
If the disk has a truly custom format, possibly using byte values other
than 0xff for sync bytes, there's no way to restore the bytes correctly.

Now, none of this would have been news to the author of SST, so it's not
surprising that you've been able to get it to work.  (Well, it's a *little*
surprising, since you're the first person I've seen on this newsgroup with
a success story.)  But it's also not surprising that it doesn't work in
all cases.

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
CD-Recordable FAQ - http://www.cdrfaq.org/
CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/