NIB format is not bidirectional?

[hackerb9]

To begin: Thank you for ADTPro. This is an incredible program and I have found it extremely useful for over 15 years. I see you now have a web store, so I will make a purchase as a small token of my appreciation.

I am using the latest release (ADTPro 2.1.0). When attempting to send a certain floppy disk using ADTPro's standard method, I get a warning that the disk was transferred with errors. Sure enough, 98% of the DSK file is just zeros. It appears that ADTPro now supports sending files in NIB format. I tried that and it seemed to work (no errors and the file on the host actually has data instead of the zeros).

The problem arose when I tried to make sure that the NIB copy was valid by sending it back to the Apple ][. The documentation states that ADTPro can receive images that are in the NIB format, with a caveat:

.NIB (Nibble-ized images - though ADTPro only writes normal in-track data)

Unfortunately, beyond that caveat, the NIB receiving routine seems buggy in two ways. First, when receiving the .NIB image, ADTPro gives an unexpected warning:

IMAGE/DRIVE SIZE MISMATCH!
COPY IMAGE DATA ANYWAY? (Y/N):

It is not clear to me that ADTPro is detecting that it is receiving a NIB file. In fact, the warning makes it sound like it simply thinks it is a DSK file that is too large.

Second, if I hit 'Y', the process hangs forever on block number 74.

RECEIVING BLOCk 00074 OF 00280
---------------------------------------------------
██████████████████████████████████████████V
---------------------------------------------------

The "V" makes me think it is attempting to Verify that the data was written correctly on the disk. I can see from the LED on the drive that it is active, although it is not making loud noises. Also, the LED on my serial port is lit up, as if data is being sent. Perhaps ADTPro is repeatedly failing the verification and re-requesting the block? I am unable to cancel on the Apple ][ using the Esc key. I have to break the connection from the host side to get the ADTPro client unstuck.

I'm guessing there's something about this specific .NIB file that makes it ill-formatted. I will attach the .NIB disk image in the hope that it helps to track down the bug. This file was created by ADTPro 2.1.0 (on both the host and client): buggy.nib.gz. By the way, ADTPro always generates the same .nib file for this specific disk.

[david-schmidt]

In order to deal with Nibble disks (which I wholeheartedly advise against for several reasons), you'll want to be sure to enable nibble operations in the client: https://adtpro.com/configserial.html#Nibbles

You'll never be able to write a faithful nibble image using a Disk II controller that has any meaningful information outside the in-track data. That's the fact behind the caveat.

[hackerb9]

Thank you for the caution. I had heard that NIB is lossy and only used it because sending that particular disk the normal way had resulted in an error message and a DSK file that was 98% zeros. By enabling nibble operations, ADTPro was able to send the data from an otherwise unreadable disk using just an ordinary Apple ][. So, yay, for ADTPro!

The problems I faced were when trying receive the NIB file. It seemed like ADTPro had two bugs:

1. A minor issue is that when receiving a NIB file, ADTPro claims that the image is the wrong size.
2. The ADTPro client locks up when receiving this particular NIB file.

[david-schmidt]

That's really a bug in the docs - ADTPro client can't reconstitute a .nib image at all. There was an attempt made long ago: https://github.com/ADTPro/adtpro/commit/c4f775a749f7c45549852a66e80a454079823b0d. But 1) it doesn't actually work, and 2) it's been rendered unreachable today - which is why it's falling through to try to interpret a .nib file as some sort of ProDOS-order image, and of course it's a different size than what it's expecting for a normal Disk II image (i.e. it's bigger than that).

[hackerb9]

Ah, that would explain the message about the mismatched size and subsequent crash.

Fixing the docs is a good idea. May I suggest also changing the client config option for "ENABLE NIBBLES" to indicate that it is a one-way trip? For example, have the options be either "NO" or "YES (SEND ONLY)".