Sounds like a "seek" problem to me. If it uses the old Western Digital floppy controller, you could issue seek instructions pretty easily to test that. I suppose other controllers might be similar. I'd have to hit the WD databook for details, but it was something like writing a track number into one register, then writing the "seek" command into another, then sitting back and enjoying the whir-click sound of a seek. Then a "restore" command would get it back to track 0. I've done it on TRS-80's; not sure if it would be quite so easy under CP/M.  Cautionary note though: the OS probably remembers what track it last positioned the drive to, and may be confused if you leave it at a different track. I *think* any attempted read/write would then fail with a "no such sector found" error, after which the OS would probably just automatically re-seek & re-try, resulting in no problem. But I wouldn't bet my last bootable floppy on it. I've seen a seek mechanism stuck - refused to move until I powered the thing down, opened it up, & physically slid the head back and forth along the rails a few times. After which it worked. YMMV, of course. One other possibility, I've seen (somewhere) a disk format in which track 0 was always written in single density for compatibility with older drives, while the rest of the disk could be SD or DD. So an older system could give the appropriate error message when failing to read a DD disk (more specific than just "unreadable"). Was that CP/M? If so, then the problem could be a failure in handling DD data. And it seems to me CP/M used "$$$" as some kind of temporary file extension, renaming files to their proper extension at the end of the operation...? Which would indicate again that the track-0 commands succeeded, but the other-track commands failed, leaving the disk op incomplete. Cheers, Bill.