Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!dcl-cs!bath63!pes From: pes@ux63.bath.ac.uk (Smee) Newsgroups: comp.sys.atari.st Subject: DCFORMAT not quite right... Message-ID: <1417@bath63.ux63.bath.ac.uk> Date: Sun, 12-Jul-87 08:04:26 EDT Article-I.D.: bath63.1417 Posted: Sun Jul 12 08:04:26 1987 Date-Received: Tue, 14-Jul-87 00:49:15 EDT Reply-To: pes@ux63.bath.ac.uk (Smee) Distribution: world Organization: AUCC c/o University of Bath Lines: 29 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.