Re: DSK to NIB Instruction

[Ed Eastman <noone@nowhere.net>]

Linards Ticmanis wrote:
> How do the emulators do it when using .nib images? Given the fact that
> there are a lot of .nib images out there that actually do work on an
> emulator, it seems the emulators somehow are able to deal with the sync
> issue?

The sync issue is irrelevant to emulators.  You only need the sync bytes 
when reading a 'soft sectored' diskette on a real diskette drive.

Emulators that support DSK or other formats emulate the disk to a 
read/write at sector/block level.

The emulators in supporting a Nib image emulate the hardware down to the 
read/write a byte level.

To get true emulation of the hardware to support highly protected 
diskettes, it would need to progress not only down to the bit level, but 
to the track to track seek timing level as well.

While not impossible, it is probably easier to deprotect, normalize and 
or crack the original programs to allow them to work in the emulator.

> Is there more to it than checking overlap bytes?

Yes...  None of the disk image formats retain sync bytes or track to 
track alignment information.  But if the nib works in an emulator, then 
it should be convertible back to a real disk and work also.

The NIB image is as follows (more or less):
Each 1A00 byte chunk is a tracks worth of bytes with some overlap.  Take 
the Nibble image back to a real Apple II and use the EDD analyze and 
write routine to put the bytes back on the disk one track at a time. 
(Sounds easy, huh?)  If only I could find my EDD source code.

Or build a program on the PC side to chunk the Nib and send to a ADTNib 
program to write out the raw track using a routine from Byte Zap or 
Locksmith Fast copy maybe.  I dunno, can't be that hard to write a 
track, If you want a starting point, the init routine does it and is 
fully documented in Beneath Apple DOS.  :p

Thankx,
Ed