Receiving Disk Images

Hitting the "R" key from the main menu lets you enter the name of the disk image you want to copy from the host to a disk on your Apple:

You can also leave that prompt blank, and hitting the Return key will bring up a listing of files in the current working directory, allowing you to simply pick one by highlighting its name and hitting the Return key.

You can page back and forth with the "A" and "Z" keys respectively, and move the cursor up and down with left/up and right/down keys respectively:

You can copy images in any of the following formats:

  • .DSK (Often, but not always, DOS-order images)
  • .DO (DOS order images)
  • .PO (ProDOS order images)
  • .SDK (Shrink-it disk images)
  • .SHK, .BXY (Shrink-it file archives similar to today's .zip files)
  • .NIB (Nibble-ized images - though ADTPro only writes normal in-track data)
  • .2MG (2IMG images)

Note that if a file name is longer than 40 characters, it will not be correctly communicated to the host and it will fail to find the file. In that case, either rename it something shorter on the host or type in the entire long name at the prompt.

After hitting Return to specify the file name, ADTPro will present you with a screen to pick a "volume" (a slot/drive combination). The slot and drive numbers are the first two columns; if the volume happens to be formatted with ProDOS, its name will appear in the Volume Name column. You can use the arrow keys or the space bar to pick the volume to be sent to the host:

The "Blocks" column is the count of ProDOS blocks present on the disk. Each block contains 512 bytes of data. Typical disk sizes are:

Blocks Disk
127 64k RAM disk (128k Apples)
280 5-1/4" Floppy disk (140k)
1600 3-1/2" Floppy disk (800k)
65535 32MB Hard drive

Some messages may appear in the "Volume name" column to indicate various situations:

Message Meaning
<NO NAME> A DOS 3.3 disk is in the drive (which is ok)
<I/O ERROR> Can't read the disk in the drive, or the drive is empty

Once you pick the volume to copy the image to by hitting Return, an attempt is made to contact the host:

If the image size from the host does not match the size of the destination volume, you will be alerted to the mismatch. You generally don't want to copy a differently sized image to a disk drive, but if it happens that you really do - you have the option to go ahead and do it anyway:

From a purely ProDOS standpoint, the operation will generally work if the destination has more capacity than the source (i.e. the destination disk on the Apple is bigger than the image you're receiving). Some space will be wasted in the process. But if you are trying to put a 5.25" .DSK image of a game, say, onto a 3.5" floppy, don't expect that to work. It won't be bootable, and DOS won't understand how to operate the 3.5" disk.

Once contact is made with the host, the disk information starts receiving and writing. The line across the screen represents a 20k buffer that is alternately received from the host and written to the disk:

When the image has finished receiving from the host, you will see a "Complete" message:

Pressing any key brings you back to the main ADTPro menu.

If errors are encountered with receiving or writing blocks, you will see "X" characters instead of solid blocks:

If an image contains at least one "bad" block, an error message will appear both at the Apple and at the host end.

Compressed Files

When transferring Shrinkit-compressed files (i.e. .shk and .bxy), a virtual disk is synthesized with enough space to hold the contents, which is then served to the ADTPro client. Typically, this results in a 280 block (140k), or 1600 block (800k) disk image. But it could result in a larger virtual disk as well, depending on how big the compressed files end up being.

Sometimes, depending on several factors, it may happen that a compressed file will fail to uncompress correctly - for example, if the resulting disk image ends up being just slightly too small to contain the unpacked files. ADTPro will respond that it was unable to open the file in that case. If this ends up happening, you can use external tools like AppleCommander or CiderPress to understand more about the compressed image you are trying to transfer, and how it might be better converted to a disk size you expect.

Once a compressed file is successfully converted to a virtual disk image, it is served to the client, but there isn't really an indication of exactly what size image was created to hold the contents. But if you indicate the unit you want to write to on the client end, it will either simply work or ADTPro will complain that there is an image size mismatch, indicating a different size virtual disk image was created to hold the contents. If that happens, it will also be a good time to consult the external tools mentioned above to make a closer inspection of the file you're trying to transfer.