[Blindapple] copying Dos to non-talking disk
jaybird at bluegrasspals.com
Thu May 1 00:57:26 EDT 2014
The following information was obtained from Appendix B of the ProDOS
Technical Reference Manual at:
I'm assuming here that absolutely nothing from track 0 can be recovered
at all. Track 0 contains eight blocks, numbered 0 through 7.
Blocks 0 and 1 contain the ProDOS boot code, and are totally unimportant
in this situation.
Blocks 2 through 5 contain the volume directory, with the first entry in
block 2 containing vital information such as the volume's name, size,
etc. These blocks are, in effect, the entire road map of the filesystem.
If they're lost, there is no information about the names or locations of
files on the disk.
Block 6 contains the bitmap. This shows which blocks are used, and which
are free. If this were a valid disk at this point, this information
would be vital, to avoid ProDOS accidentally overwriting already
allocated blocks with new material.
Block 7 is the real kicker as far as your data's concerned, since block
7 is the first data block. At this point, I'm assuming a volume which
was formatted, and onto which the files were copied or created, one
after another. If this is the case, block 7 contains the first block of
the first file on the disk. Assuming, again, total loss of track 0, if
this first file was 512 bytes or less, the entirety of the file is lost.
If this file was longer than 512 bytes, the first 512 bytes of the file
are lost. Assuming track 1 isn't also damaged or destroyed, block 8
should still be the valid index block for this file, so all except the
first 512 bytes should be recoverable. Index blocks are not used for
If files have been moved around, deleted, modified, etc. there's no
telling what was actually contained in block 7. It may have been the
first block of the first file, it may be a data block or an index block
for some other file, or it may be free. ProDOS allocates the lowest
block numbers first, so if the first file was deleted, that would put
block 7 up for grabs again, and if you then added to an existing file
elsewhere on the disk, it could be using block 7, in which case, you'll
have lost some random chunk of 512 bytes somewhere.
If you're going to try to recover the data by imaging the disk and
reconstructing the files on another system, you probably want to image
the disk in ProDOS order if possible. Although the physical format of
ProDOS and DOS 3.3 disks is the same, the two operating systems organize
data differently. In other words, ProDOS doesn't use two consecutive DOS
3.3 sectors for one ProDOS block.
If files have been deleted from this disk, you'll probably end up
recovering them, or bits of them, in the process. Without the bitmap in
block 6, there's no way to know which blocks are actually used and which
contain garbage data.
Also keep in mind that, along with your text, you'll also recover what
looks like gibberish. These blocks are probably the index blocks for
files on the disk. If the filesystem on track 0 were intact, these index
blocks would tell ProDOS where to find the blocks for these files. The
way ProDOS block allocation works is that the directory entry for each
file specifies one block as the so-called "key block." In a file of 512
bytes or less, the key block is the one and only data block. On files
larger than this, and smaller than 256 data blocks, the key block is an
index block. The index block specifies up to 256 blocks of actual data
for the file. Since there's no header information in an index block,
there's no way to tell an index block from random binary data, assuming
total filesystem loss.
In any event, recovery will probably involve reconstructing the files
from bits and pieces, and determining what, if anything, is lost, and
whether it can be reobtained/recreated.
Hope this helps!
On 4/30/2014 10:50 PM, Tom Brennan wrote:
> Thanks, Jason. This is a prodos data disk with only its root directory. All
> files on it are text and there are about 25 of them. It is, indeed, a 5.25
> Tom Brennan KD5VIJ, CCC-A/SLP
> web page http://titan.sfasu.edu/~g_brennantg/sonicpage.html
> BlindApple mailing list
> BlindApple at bluegrasspals.com
More information about the BlindApple