Re: DSK to NIB Instruction

[Linards Ticmanis <ticmanis@gmx.de>]

Ed Eastman wrote:

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

Hello Ed,

Actually judging by the source code, most emulators seem to "nibblize" 
the .dsk image internally and then feed it to the emulated controller.

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

I don't have any literature available on low-level disk operation. Do I 
get this right:

1.) the .nib format stores bytes in the same format that the Apple's CPU 
sees when accessing the drive controller card (disregarding the .nib 
overlap).

2.) this is not the format that is actually stored on the disk.

3.) the purpose of sync bytes is: to tell where in the bitstream a byte 
starts, so you don't get half of one byte and half of the next. So when 
reading a disk on the Apple, you throw away what you read while waiting 
for a sync byte, which will be aligned correctly, then the bytes after 
that will also be aligned correctly, so you can use them.

4.) sync bytes are stored with some extra bits in front of the normal 
bit pattern. These extra bits are not directly visible to the Apple's 
CPU, only to the controller card itself.

5.) when reading from a disk, there's a way to ask the controller 
whether you've got a sync byte or not.

6.) when writing to a disk, there's a way to tell the controller to 
write either a sync byte or a normal byte.

7.) You can't tell from the byte value alone whether you've got a sync 
byte or a normal byte. You have to ask the controller in a specific way.

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

My point was actually not emulation, but making use of the large library 
of already existing .nib images on a real Apple.

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

That's my point.

> 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

I was actually thinking of coding something on the PC side that turns 
the .nib image into two SST-format .dsk images (if only I knew what the 
SST format actually is). These could then be transferred to a real 
machine with ADT and reconstructed there with SST. This would mean there 
is no need for any new software on the Apple side, saving me the hassle 
of coding something in 6502 Assembler, which I'm not terribly good at.

I'm only talking of *known to work on an emulator* .nib images. These 
obviously don't need exact track-to-track timing or nonstandard sync 
stuff. Couldn't you just pick some number of bytes evenly distributed 
throughout the track and make them into sync bytes, since obviously the 
software doesn't care either way, or else it wouldn't work on an 
emulator. Or am I missing something here?

Greetings,
--
Linards Ticmanis