pes@ux63.bath.ac.uk (Smee) (07/12/87)
Carrying on with my experiments with swapping 3.5 inch disks between the ST and an IBM clone, I tried using DCFORMAT's 'put on a MS/DOS header block' feature. (The disk had been formatted 'normally' (DS, 80 trk, 9 sect) using DCFORMAT. Our PC (using DOS 3.2) was not at all happy with it. Was a bit funny, though. The files (put on on the ST) 'listed' correctly. DOS had no problems with the directory (root). Files less than one cluster long read correctly. However, files > one cluster were painfully garbaged. So, something goes wrong when the IBM has to look at the FAT. (For short files, it doesn't have to check the FAT to determine end of file, because of course the length is contained in the directory entry.) The only immediately obvious difference between the ST and PC standard formats (outside the header) is that the ST allocates 5 sectors per FAT and the IBM allocates 3. However it is hard to believe that MS/DOS could be stupid enough to be trapped by this. In looking at the available MS/DOS documentation, though, I note that there is a bit of information contained somewhere on the disk (not clear whether header block or in FAT -- poor doc) which tells MS-DOS whether the medium uses 12-bit FAT entries, or 16-bit FAT entries. I suspect (but can't tell due to lack of definitive documentation about MS/DOS disk format) that DCFORMAT is putting the disk into a state where one of the machines (probably the ST) thinks that FAT entries are supposed to be 12 bits, while the other thinks they are supposed to be 16 bits. That would very nicely explain the observed behaviour. Moral? If you're going to swap disks between a PC and an ST, format them on the IBM. DCFORMAT doesn't seem to handle this case correctly yet.
dragon@oliveb.UUCP (Give me a quarter or I'll touch you) (07/13/87)
in article <1417@bath63.ux63.bath.ac.uk>, pes@ux63.bath.ac.uk (Smee) says: > Carrying on with my experiments with swapping 3.5 inch disks between the ST and > an IBM clone, I tried using DCFORMAT's 'put on a MS/DOS header block' feature. > (The disk had been formatted 'normally' (DS, 80 trk, 9 sect) using DCFORMAT. > Our PC (using DOS 3.2) was not at all happy with it. Was a bit funny, though. > The files (put on on the ST) 'listed' correctly. DOS had no problems with > the directory (root). Files less than one cluster long read correctly. > However, files > one cluster were painfully garbaged. So, something goes > wrong when the IBM has to look at the FAT. (For short files, it doesn't have > to check the FAT to determine end of file, because of course the length is > contained in the directory entry.) When I modified the boot sector of an ST disk, as instructed a while back (using Norton's 4.0 on a PS/2 Model 50 running PC-DOC 3.30), the PC could dir the disk fine, but any files we tried to copy off would be truncated. Could this be related in any way? I was hoping to not have to copy 30 disks to IBM format to get them on a BBS run on an IBM... it would take weeks! -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ |_____