[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dark Crystal and Time Zone

Linards Ticmanis wrote:

On 01/19/2011 04:16 PM, magnusfalkirk wrote:



Has ANYONE EVER successfully used SST to change a .NIB file back into
a REAL Apple II disk? I read the threads you linked to Dave and in the
end both of them said that it couldn't be done. As an experiment I
might just try using SST to copy a disk, say the Owner/General Manager
disk for MicroLeague Baseball, to 2 disks and then try rewriting it
back to a real disk to see if it can be done at all.



Usually it doesn't work. NIB is an ancient format, older than DSK as far
as I know, and, in hindsight, not terribly well thought-out.


It was designed for the protections of its era, which were typically
substitution of address and data marks, and occasionally a simple
nibble count or nibble signature.

As deprotection technology advanced, copy-protection technology
advanced, too, in a typical "arms race".  As usual, the methods
to defeat protection schemes were developed more rapidly and
by more people, so deprotection generally caught up quickly to
any new protection advance.

But advance they did, and the software-controlled nature of the
Apple disk drive enabled a real "zoo" of tricky and sometimes
clever protection schemes that went far beyond capturing the
nibbles on a track.


NIBs have longer tracks than any real Apple drive, to make sure
everything fits even if the disk uses slightly shorter-than-normal bits
or the drive is spinning too slowly. Because of this the beginnings and
the ends of tracks will have varying amounts of overlap when a NIB is
used to store a real disk. Unfortunately, NIB does not store the
original track lengths anywhere, and does not mark where overlap begins
and ends. Since areas of unused data won't be a perfect match between
the overlapping sections (although used sections will be), finding the
beginning and end of overlap takes some head scratching.


Actually, it's not too bad.  Since there is guaranteed to be an
overlap region, and the approximate length is known, it's not too
difficult to search for the overlap and determine the actual track
length.  This can be done manually or by code.


Also on a real disk you have to start and stop writing at some point of
the track and the bytes directly around that spot won't come out right
on reading, because the disk doesn't spin so evenly as to guarantee
hitting the exact same spot after what is supposed to be one whole
revolution. So you have to make sure that spot is in a gap (unused part
of the track), preferably in the largest gap; and there's nothing in the
NIB format that tells you where in the track there are gaps and where
there is actual game data.


This is a real problem, but it is a problem that affects most disk
duplication schemes as well, so if you can find the gap that tolerates
"slack" and use that for the overlap point, you've got it.

For entire tracks (not partial tracks) this is done by writing a longer
data stream than fits on a track, prefixing it with data that will be
irrelevant, so if more or less of it survives the overlap, that's fine.

There is nothing in *any* disk format that indicates which features
of a track are relevant to a program and which are not--that's the
"stopping problem", and it is fundamentally incomputable.  It requires
traversing all possible program paths and verifying which regions of
the disk are examined and which are not.

Thus, heuristics are required to make progress and there are no
guarantees that the determinations have been made correctly--whether
it's a program or a person that's making them.  ;-)

In practice, people are pretty successful at figuring out what is and
is not significant, by reverse-engineering the programs disk access
code, for example, and by doing experiments.  Every once in a while,
even an experienced deprotector is fooled into thinking they are done
when some protection remains to disrupt the program in some case(s).


Thirdly the Apple needs to make a difference between self-sync bytes and
normal bytes during the writing of a disk, otherwise you'll either get
framing errors on reading (when you're not using self-sync bytes where
you need them) or the data won't fit (when you're using too many
self-sync bytes, which take up a bit more space on the disk surface).


Normal nibbles are 8 bit times, while self-sync bytes (which are not
strictly necessary) are more than 8 bits long, typically 9 or 10 bits.
So they take up 12.5% or 25% more space than 8-bit nibbles.


However the self-sync bytes and normal bytes come out the same during a
normal disk read (you need special reading routines to tell the
difference and even then the detection isn't completely reliable).
Emulators (all that I know of) feed the emulated floppy controller one
byte at a time, not one bit at a time as a real drive does, thus framing
errors cannot occur in an emulator; and consequentially, NIB, as an
emulator format, does not store the difference between normal and
self-sync bytes at all.


Most methods of timing nibbles use the number of cycles between when
the last nibble was "presented" by the disk controller and the time
the current nibble is presented.  Thus no intermediate "shift states"
are needed to determine the length of a nibble.

The timing constraints are so tight when this is done with 1MHz 6502
code that a reliable determination (with no assumptions) of 8-, 9-, or
10-bit nibbles may require reading a track at least twice.  (Self-sync
bytes longer than 10 bits are "illegal", in the sense that they have
more than two consecutive zero bits.)


So the only way to get a NIB back onto a real floppy without actually
cracking the game is to take a look at your NIB with e.g. a hex editor
and find out what's going on - where tracks and sectors start, where
overlap begins and ends, which bytes are probably self-sync etc. Then
you can rearrange data so the largest gap is at the beginning, and mark
likely self-sync bytes as such. Then you can use a relatively simple
assembly language routine (which can be found in either Beyond Apple DOS
or Beyond Apple ProDOS, I don't remember which) to write the disk one
whole track at a time. I once put together a small program in C (cc65
compiler) as a front-end for that assembly code, which I could send to
interested people. However it won't do the NIB analysis described above,
only the writing once the NIB has been pre-edited. In fine, let's hope
KryoFlux gets disk write support soon, that should be the beginning of
the end of this kind of trouble, at least for those people who own one
(i.e. *ME* Bwahahahahahahaaaaaaaaaa.....)


While this details the issues involved in re-creating a disk from a
.nib *when a .nib captures all the necessary data*, it does not deal
with all the later protection schemes which relied on partial tracks
on fractional track boundaries, synchronized tracks (or does SST do
synchronized reads?), "soft" bits (unrecorded bit strings that read
unreliably), or other weirder techniques not comprehended by the .nib
format.

In short, even considering all the complications of reading protected
Apple disks, writing them is *much* more complex.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

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