• Please review our updated Terms and Rules here

ImageDisk + 5160 = no go?

VileR

Veteran Member
Joined
Jul 21, 2011
Messages
656
Location
Israel
I've been looking into imaging some floppies on my 5160 (5.25" DSDD half-height drive, IBM FDC). Tools like Diskcopy Fast, Teledisk, etc. are all working fine so far; but as you all know, certain disks may require a "second opinion", so I've been testing ImageDisk as well. And ImageDisk is giving me funny results - with every disk I feed it.

In any track that IMD reads, it always maps the first *logical* sector to the last *physical* sector on the track. Apart from that, the sectors are ordered as usual. When using IMDV to browse an image created from a normal 360K disk, every track's sector map looks like this:
2 3 4 5 6 7 8 9 1

...instead of the expected order:
1 2 3 4 5 6 7 8 9

In other words..
Logical sector 1 = physical sector 9
Logical sector 2 = physical sector 1
Logical sector 3 = physical sector 2
...and so on.

Here's a GIF that could better clarify what I mean: note the sector map and the Physical vs. Logical numbering. This is from a plain vanilla DOS boot disk.

Those other tools give me perfectly normal sector maps for the same disks, so I'm guessing the drive and the controller are probably fine. It's almost as if IMD lags a little after the index mark is read, and starts reading the sectors a little too late. So it misses the first sector, treats the 2nd sector as the first, and by the time it registers a full revolution of the disk, the first sector is actually the last one it has read.

Mind you, this is with Sector Interleave set to "As Read". If I change that to "Best Guess", I get a normal track 0, but every track after that gets the 'skew' as before. Sure, I can use IMDU to re-interleave the sectors, and that does seem to work; but with any disk format that's even a little bit off the beaten path, I don't want to trust that.

Any ideas here? IMD's documentation keeps trying to talk me out of using it with a PC/XT controller... but I'm not trying to read HD or 8" disks, and I do take care to lock the data rate at 250kbit/s, so I'm not sure what the show-stopper is. I don't have a machine with an AT disk controller, so this is what I have to deal with. Is IMD just not usable with a PC/XT-type FDC? Has anyone else encountered this problem?
 
Interesting. I don't recall running in to that problem before with ImageDisk on a 4.77mhz system. Although I usually do use one of my other faster systems. It is possible I may not have noticed. From what I have seen, ImageDisk does "work" on a PC/XT system, but some operations can be painfully slow. When archiving disks, a critical factor is to keep the disk spinning as little as possible - you might only get so many revolutions before the disk falls apart.

Getting a slight skew like that won't really hurt anything, but it is not ideal and (presumably) not technically correct.

Does this happen when reading a freshly formatted disk?

What kinds of disks are you archiving? Data disks? Copy protected disks? If you are dealing with factory original commercial titles or copy protected disks, you should consider a Kryoflux or SuperCard pro. For non copy-protected disks in standard 360k format, other DOS copy tools will be much faster. Typically I only use ImageDisk for 160k, 180k, and 320k formats or non-DOS formats because many other DOS or Windows copy tools can't handle those formats.

You might check the motor RPM speed of the drive and see if it is too far off.

I have seen damaged disks cause odd interleaves, or worse yet duplicate sectors. (Mainly with Teledisk, though).

You are not telling ImageDisk to re-analyze every track are you? I'm a little surprised that "best guess" would get get track zero right and then switch things around - Might be wrong, but I think it should not do that unless it has re-analyzed the next track.
 
Yes, this happens with newly-formatted disks too. The motor speed looks good - in IMD's test it settles to 299-300 RPM. I tried both with and without the 'full analysis' option, but the weird skew is there regardless. Specifying a 1:1 interleave does seem to eliminates the issue, but in case of slightly weird disk formats that's probably something I don't want to do.

For now I'm only testing the waters with this drive. I probably *will* want to archive some commercial titles, and I'm actually beginning to consider the SCP if this becomes a priority. But a more immediate goal is a pile of old home-written floppies which have been sitting around (in various locations and storage conditions...) for up to 3 decades. For most of these, it'd probably be enough to just yank the files out, so I'm not too worried if it's only ImageDisk that isn't playing nice. I just wonder if this doesn't indicate a bigger sneakier problem somewhere.

What else could cause such a symptom? Could the XTIDE Universal BIOS be interfering somehow?
 
I'd have to look at the source, but it could be that your machine is a bit too slow and it misses the first sector after the index.

Just curious, what are you using for a floppy controller? The original IBM 5150 controller used an Intel 8272 (no suffix) which has a long "blind spot" after the index for VCO sync.
 
Interesting, I had not noticed that the earlier revision used an Intel chip.

This is an early IBM FDC (also note the black back plate indicating an early 5150)
http://minuszerodegrees.net/5150/early/5150_compare_diskette_adapter.htm

And this is a later one that uses an NEC chip:
http://minuszerodegrees.net/5150_5160/cards/5150_5160_cards.htm#floppy_adapter

I wonder if this is why DOS 1.x used only 8 sectored disks?

Apparently 9 sectors must "work", but perhaps it is less optimal?

Can this chip handle 10 512-byte sectors like most later low density FDCs?
 
Original was 8272/uPD765 vs. later 8272A/uPD765AC.

No, it won't handle 10-sector floppies unless you mask the index signal--and then you can only read them, not write them.

The problem was that the VCO sync time where the FDC was "blind" on the older chips was 1 msec. Way too long to pick up an IDAM, particularly on floppies that didn't have the IAM. I think the "A" versions cut that in half.

But the originals would work with 9 sector formats. The 8 sector was the recommended format in the original NEC data sheet, so I suspect that IBM went with that.
 
Hmm - looking at the layout, my FDC is the newer revision (the 5160 itself is one of the later ones, with the half height drive). The chip is an Intel 8272A.

If the 'A' revision still has a long enough "blind spot", it'd mean that lag after the index pulse is due to the controller itself (not IMD, as I assumed in my first post)- it's just that IMD doesn't try to compensate for it when Interleave is set to "as read", whereas other tools like DCF/Teledisk/etc. might be doing that... which is why they don't show the same issue. Does that sound plausible?
 
Last edited:
Dunno. TD worked out interleave by using the "Read Track" command (which ignores IDAMs and starts right at the index) and then reading sectors individually, matching up contents. I suspect that Dave does a bunch of Read IDs, but I'd have to look at his code.
 
Back
Top