The Never-Ending Tangent!

A project log for Improbable AVR -> 8088 substitution for PC/XT

Probability this can work: 98%, working well: 50% A LOT of work, and utterly ridiculous.

Eric HertzEric Hertz 02/28/2017 at 11:461 Comment


It seems amongst all the sector-extraction-attempts, I've managed to recover all but 34

missing: 29:
only existing with errors: 5:

There appears to be a pattern...

There're a *lot* of sector=10's missing..

If I understood correctly, this diskette *appears* to be formatted such that it has 39 physical cylinders, 2 physical heads, and 10 sectors /track/side... Furthermore, unlike most diskettes, it appears to have a sector '0'.


Further-still, it appears that the "logical" sectors completely disregard the physical...

Logical Sector 10 on Logical Head 0 is actually Physical Sector 0 on Physical Head 1.


I've obviously managed to extract data from various cylinders with these assumptions.

But I also see, from the list of errors/missings, that this assumption may not always be the case.

Plausibly: It's actually plausible, (in fact, mentioned 'round the interwebs) that some tracks/cylinders *may be* formatted *differently* than others. (what?!)

yeahp. And, the data here seems to suggest that may be the case.

I haven't looked into *all* these cases, but I looked at a handful, and the errors related to the missing sectors looks to be related to "sector not found".


So, I'm a bit wonky on my understanding of this... but it seems cylinder 0 is the outer-most cylinder/track. So, there *could* be some justification that the outermost cylinder might be able to accept more sectors than the innermost, where the circumference is smaller. BUT. that seems somewhat irrelevent because The Data Rate is constant. The Rotational-Speed is constant... So... The only difference, then, between the outter and inner tracks, if written a different number of sectors, would be the amount of space (the "gap") *between* sectors. Which... really shouldn't matter, because, if it's capable of discerning data-bits at the same data-rate at the same rotational-speed, then adding a larger/smaller gap between sectors shouldn't change anything.

Further still, if you look at the list of missing sectors, it seems the majority are related to physical head 1. Again, from what I've read, it *is* possible to format the tracks differently, not only across different cylinders, but *also* across different heads.


It's *plausible* one physical side of the disk may be formatted with ten sectors/track, while the other side might be formatted with nine. Further-still, it's *plausible* the first side might start with sector '0' while the other side might start with sector '1' (while, again, *also* having 10sectors/track on side 0, but 9sectors/track on side 1).

But, then, since the *logical* sectors completely disregard the heads, that'd mean sectors 0-9 are on head 0, while *11*-19 are on head 1.... But Apparently Only On *some* cylinders!!!

Since... again, that "missing" list assumes that the format is constant across all cylinders/heads... assuming that sectors 0-9 are on head 0 and sectors 10-19 are on head 1... and... that missing-list shows that there are some sector-tens that are *not* missing, which again implies that *some* tracks/cylinders on head 1 might in fact be ten sectors/track, rather than 9.

This is friggin' insane.

But we've barely scratched the surface! (hopefully, since once the surface is scratched, it's entirely plausible the data may never be recovered).


OK, there's another thing...

Allegedly... older systems like these often have lookup-tables to reroute sector-numbers. Why? Because, apparently, it takes some time to process the data... So, briefly, one might read the first sector on a track, and then it takes some time to process that data. Then, by the time that processing is complete, the disk has spun 'round to the 5th sector on the disk. But say you want to read the second sector... Now your option is to *wait* until the disk spins around another full cycle and sector 2 is available. So, what they did to speed things up was "interleave" the sectors...

Say it's presumed that it takes the same amount of time to process one sector as it takes to rotate the disk 1 full sector, then to make reading faster it'd make sense for the track to be formatted such that the sector-numbers are physically ordered 1, 5, 2, 6, 3, 7, 4, 8, or something similar. (That's quite a hack!) And if it takes n-sectors' amount of processing-time to process a single sector, that order would obviously be changed beyond my mental-aptitude at the moment.


As far as I can tell... a diskette whose "interleave" differs should *not* affect its ability to be read, though it may *dramatically* affect its ability to be read *quickly*.

So, frankly, I'm going to ignore this for now...

The fact is, each sector contains a header, which contains information regarding which *logical* sector/head/track it corresponds to. And, again, it would seem the *logical* tracks correspond to the *physical* tracks, we can ignore that for a minute. That leaves us with the heads and sectors which may not *consistently* correspond between the logical and the physical.

Regardless, whichever *physical* location one chooses, the header-information is what really matters. The disk-controller apparently reads each sector-header (containing "logical" information) and only returns data when that sector-header matches the requested *logical* location.

So, actually, it's entirely plausible these missing sectors are located on entirely different physical locations.

For instance: One of the "missing" sectors is what I presumed to be:


(P=Physical, L=Logical).

But another "missing" sector is what I presumed to be:


It's *entirely plausible* the data corresponding to Logical: Cylinder 2, Head 0, Sector 10, *might* be located at the physical location: Cylinder 22, Head 1, Sector 0.

The kicker is, because the disk-controller is so smart... it's being physically moved to cylinder 2 and reading back from head 1 all the sectors and not finding the one marked c2h0s10 because Logical c2h0s1 might in fact be located on Physical Cylinder 22.

This sort of remapping could've been accomplished in many locations. Most-likely the KayPro's BIOS has a lookup table that handles simple remapping such as sectors 10-19 are on head 1, plausibly also the interleaving mentioned before. Then the OS (CP/M) could handle some other remapping based on some header-information in the floppy-disk's higher-level-formatting (similar to FAT-12) which might have another lookup-table (maybe the sectors 10-19->head1 are handled here, instead of the BIOS?). OK, then... There's a third level... The software itself.

The software itself *may*'ve been written to bypass the BIOS/OS lookup-tables... The only reason I can think of to do-so is to implement some level of copy-protection.

Futher, because the disk-controller is so smart... there's, apparently, no way to ask it to list all the logical-addresses on a cylinder/track. The only way to do-so is to essentially request a "read closest sector-ID"... which returns the sector-header-ID closest to the head at the time it's requested. So, I suppose, I could run 10000 "readid" commands to determine *every* sector ID on each track... Assuming, of course, that those requests happen to occur at a rate that doesn't align, at all, with the rotational-speed of the disk...

I mean, seriously, this is ridiculous.

Why there's no "read all sector ID's" command, I have no idea.

So, I've presumed that it's *plausible* that the reason I can't read Logical address:


is because it may not be on cylinder 2 at all...

A more-reasonable method *may* be to search every track for the one with that ID.

OTOH, it's also *plausible* that the logical address c2h0s10 is never accessed, and equally-plausible that in order to make use of that sector-space they might've numbered it *completely* differently... e.g. c200h12s88, and somewhere in code requested the *physical* location on c2h1.


More plausible, still, is of course that the diskette itself has degraded over time.

But, again, look at that listing... there seems to be a very distinct pattern to it... logical head-0, sector-10, on most cylinders (but not all) is unlocatable. It would be surprising if that *pattern* was due to physical degradation.


Here's the kicker that's throwing me off right now...

Early-Early-on I tried 'dd' to extract the entirety of the disk... The result was *countless* I/O errors. However, 'hexdump' shows that there's data located at 0x24000-0x24fff. So, I extracted all that "valid" data as sector-sized files... then 'diff'ed those files with all the extractions I've made, so far...

The result?

0x24000-0x24fff corresponds to files extracted from physical cylinder 16, head 0, sectors 1-8.

Now... I'm not *great* at math anymore, but say we start with 0x24000 / 512(bytes/sector) / 2(heads/track) / 9(sectors/cyl)... we get 16, which I think should be our cylinder number.

Except, I've extracted cylinder 0, head 0, sector 0, as well as cylinder 0, head 0, sector 9.

That indicates *10* sectors/track. So, then, why would byte 0x24000 correspond with cyl 16?

Mind Boggled.


Thinking about it a little more, using 'dd' must require the system (somewhere) to have an idea of the formatting of the disk... it would need to know whether to expect sectors to start with '1' or '0', and it would need to know something about the logical-sector-IDs. Because, again, the disk controller, itself, bases its locating of sector-information on a *match* between the *requested* sector-ID and the one it's found. Since *most* diskettes (at least IBM-formatted?) start with sector 1, and have 9 sectors per track, the location of the data might make sense. 'dd' may've been assuming 9spt starting at 1, the real disk may be 10spt starting at 0, so 'dd' would only be *requesting* data from only 9 sectors per track, and combining the data sequentially based on that information. Thus, it might make sense that the data located at 0x24000-0x25fff would really have been located at 0x28000, if 'dd' had attempted to read sector '0', as well, and we'd still have data corresponding to physical cylinder 16. And it would've found matching sector-IDs on the expected cylinders... Yeahp. I think I got that.

There is a linux utility to handle this... setfdprm... from fdutils, which I guess I should look into more. Also there's cpmutils which contains floppy-settings for CP/M disks, and more. There are also CP/M disk-imaging utilities for DOS, which is what I attempted first...

Early-on, though, I got read-errors... which is why I went to fdrawcmd early-on.


Eric Hertz wrote 01/22/2020 at 07:07 point


OK, I can *barely* follow all that, now. But, it occurs to me, some *vague* recollection of something read/discovered long after this [?]... that some drives and controller-chip combos [in PCs] don't work well with 10-sector disks because the PC-style controller expects a bigger 'gap' between the "index" pulse [the hole on the side of the spindle-hole on a 5.25in floppy] and the first sector. Because: PCs use 9 Sectors/Track, and to squeeze in a 10th sector, non-PCs use a smaller gap.

So.... that'd probably explain all the sector-10s that were unreadable, being that it's the first sector on the second head.

Nice goin' Eric... how many months thereafter did I continue without this knowledge?

That said, my later endeavors [aka 'the trick'] *would* solve this problem in software, which otherwise would normally be handled by trying different controller chips, if yer lucky enough to have several lying around... or, *maybe* by somehow adjusting the index pulse.

  Are you sure? yes | no