Re: DSK to NIB Instruction

["josephoswaldgg@hotmail.com" <josephoswald@gmail.com>]

Linards Ticmanis wrote:
> Actually judging by the source code, most emulators seem to "nibblize"
> the .dsk image internally and then feed it to the emulated controller.
>
> 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).

This obviously depends on the emulator. Let's step back for a moment,
however.

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

What is stored on the disk is a magnetic field varying over the disk
surface.
The hardware (analog sense circuitry and digital controller state
machine) processes that, and software queries the digital controller in
a basically unsynchronized way.

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

It's not quite so simple. Sync bytes appear because the disk controller
only "locks" to the bitstream because it "knows" the
most-signficant-bit of a disk byte must be a 1. There are a lot of ones
on the disk. Sync bytes are designed so that if the CPU is in a read
loop (i.e., readloop LDA readlatch, BPL readloop), that once the read
passes a sufficiently long sync section, that the bytes that come out
of the loop will match the data that the write routine intended to put
down. If you have a diabolical write routine, you can force a naive
read loop to get back different bytes.

In usual disk formats, the sync bytes are placed before the address and
data header fields so that those fields can be found reliably by the
RWTS routine. What is missing from your description is that those sync
bytes ONLY work for the immediately following bits, and ONLY if the
read routine keeps reading the bytes continuously to maintain "lock".

Most read routines do NOT look for the $FF sync byte and "throw it
away", they look for the $D5 byte (in conventional format), which
reliably shows up because the $D5 bit pattern was carefully chosen so
that it should not match any other out-of-sync region, AND the sync
bytes just before that byte ensure that it won't be missed.

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

Extra zeros AFTER the $FF is usually how I think of them, but the
reality is the disk is just a bunch of ...11100111111110011111111001...
without any "hard" byte boundary, except as defined by the controller
state machine.

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

NO!!! At least not in any straightforward way.

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

Yes. you wait long enough for the controller to write out some extra
zeros.

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

It's a very involved process. My understanding is you read the track
multiple times with different choices of read timing, and post-process.
But I haven't gotten around to reverse-engineering a nibble-counting
program yet.

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

Those images are presumably NIB format for a reason, which is that they
were non-standard disks. "Using them" effectively requires a program
which implements the (possibly unique) standard, and that the NIB
format preserves enough of the format for that program to behave as you
wish.

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

OK, but no one said such conversion would be straightforward. See
below.

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

SST on the emulator would theoretically do so, but you would have to
DISABLE the funkier read logic, which presumably tries to detect the
zeros in a way that the emulator doesn't support.

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

It would not hurt to make *every* byte a sync byte, but you would
almost certainly run out of room on the track. Instead, one must pick
and choose. Choosing just $FF bytes is one possibility. But a disk
could use $FE bytes for sync, or have lots of $FF bytes around for some
reason. And so on.

It probably can't be done automatically for all cases.