Why no data in middle of all my Tandy (FAT12) 360K disks?
#1
I have a drive that the SCP app reports as reading 42 tracks (or more iirc), and does seem to step that far. Some random information I found on a random forum said this drive is a 96tpi model so that's the DriveType I've been using. Nearly all the images it creates in both Index and Splice mode load fine in HxCFloppyEmulator and I can use the "Disk Browser" to see the files and have exported some. (I have not verified whether absolutely all content is there but it sure seems to be.)

That said, whenever I open "Track Analyzer" in HxC the disk shows up with 20 rings of data around the outside followed by some 20 rings of noise in the middle. During another experiment I set my DriveType to 48tpi, and two magical things happened:

1. A "bad disk" ended up being readable by HxC, still a few "sore" (red) spots in its MFM decode but browseable!
2. Despite still setting it to scan 42 tracks, the "hole" of noise went away and HxC is showing sectors all the way to the middle!

So now I'm really confused. What does the DriveType (tpi) setting do? I thought the floppy hardware interface just took in pulses and stepped the head motor one step per pulse. So if SCP is pulsing 42 times as it reads the disk what does it matter how many "inches" that would be? I should also note I do have "Half-tracks" selected but half the time it ends up greying itself out and I don't know when/if that has any effect either.

What are the implications of imaging ~forty disks with the DriveType set to 96tpi if it appears that 48tpi gives better results? Are my existing dumps actually corrupted on half the data, just not a half with the FAT directory entries?
Reply
#2
I posted some sample files: http://extinguishedscholar.com/temp/deskmate_96tpi.scp vs. http://extinguishedscholar.com/temp/unknown_48tpi.scp

(The Deskmate one shows a directory listing even when SCP is set to 96tpi but does exhibit the noise in the middle tracks. The Unknown one had bad data spots at 96tpi but seems useable when imaged with SCP set to 48tpi.)
Reply
#3
What disk type are you selecting? The 96tpi vs. 48 tpi has to do with the head stepping and the disk type you select.
Reply
#4
I just looked at your images. That "unknown" dump has massive amounts of smeared flux, which usually means that the head is dirty. Keep in mind that you should be cleaning the heads just about every single time you dump a disk!

The 96tpi image is missing tracks 20-40... like the disk drive door was opened or something. What model disk drive are you using?
Reply
#5
The drive is a Teac FD-54B-02-U. I am not opening the door at exactly track 20; this happens on every disk when the DriveType is set to 96tpi. What exactly does the TPI setting change about the imaging process? A guide I found on floppy disk controllers seems to confirm my suspicion the a step pulse moves one track:

> Step - This signal moves the head one track toward the disc's center or away from it. Movement occurs on the pulse's trailing edge.

Likewise this guide http://www.bitsavers.org/pdf/mitsubishi/..._Sep83.pdf implies a one pulse to one track setting:

> It is allowable to read (and sometimes write) a 48 TPI disk in a 96 TPI disk drive. But the software must command the controller to move two "96 TPI" trakcks for one 48 TPI track

So if I have "IBM 360K" selected as the disk type, and 96tpi selected as the drive type, and am imagining to a file, and "half-tracks" is checked but [probably although not reliably] greyed out — how far will the drive have advanced when the SCP app thinks it is on track 21?

My guess is that what's happening is that because a Single/Double 5.25" disk would have 40 tracks at 48tpi (source: https://en.wikipedia.org/w/index.php?tit...omposition) that SCP thinks it needs to double-step if I have the DriveType set to 96tpi. So by the time it gets to what it thinks is track 21 it has actually stepped 42 times and is at the end of the disk. I don't hear terrible grinding sounds after this but maybe since it's only bumping two at a time I don't recognize the noises enough.

There isn't a 5.25" 1.2MB disk type that I see (iirc from other forum hints one would use the 3.5" 1.44MB as an alias to that) but if there were I suppose it would have 80 tracks defined. So perhaps by setting my drive to 96tpi and then imaging as if it were a 1.44MB [i.e. 80 track, i.e. the "high density" version of either 5.25"/3.25" branding…] then I would get a high resolution version of my original mistake. Specifically, I would still get the noisy inner ring (of 40 tracks this time) but the outer ring would have the full 40 tracks of data too. There's no point in actually doing this — instead I will be more careful with my stepper motor now that I know — but just trying to puzzle out how everything interacts.

---

In short, am I right to conclude the following?

1. Setting the drive type to 96tpi will cause a 48tpi drive to hit the end of its mechanism halfway through all the 48tpi disk formats (because the app will double-step between each track)
2. This is almost certainly a 48tpi drive, despite what some random forum post (http://www.vcfed.org/forum/showthread.ph...post170720) claimed about the Teac FD-54B model
Reply
#6
1) agreed
2) I am not sure. I will have to look into it, but it sure sounds like it to me and you are missing every other track (so track 20 is actually track 40) and then crashing the head into upper end stop after that.
Reply
#7
Cool, thanks! I think the mystery is solved then. After running a few more disks through with 48tpi configured I think it's pretty clear that's the right setting for this drive with the jumpers that get it working. [I still have some research on that on my list too but for SCP purposes my notes in the other thread here are ± the latest.]

Besides just the visually obvious "missing middle" issue that goes away at 48tpi, the directory listings also tend to get much "fuller". For example one disk I imaged had about 8 items in it on 96tpi, including an "empty" folder called GAMES; imaging it on 48tpi yields more items at the root level, plus another half dozen files within the GAMES folder.

Sorry for all these blunt questions [albeit not sorry enough to promise this was my last one — especially since I've only just dipped my toes in on the 3.5" side ;-]. I'm kind of stumbling my way through a lot of new knowledge of how these floppies actually worked. I'm sure I plugged a few in back in the day but hardly messed with jumpers much less what each different machine's FDC was doing.
Reply




Users browsing this thread: 1 Guest(s)