Re: Dark Crystal and Time Zone

[Linards Ticmanis <ticmanis@gmx.de>]

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.

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.

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.

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).
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.

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.....)

(Maybe I could make some money writing novels, or sermons. NOT. ;-)

-- 
Linards Ticmanis