Continues...

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

----------
missing: 29:
  
  Pc2h1s0_Lc2h0s10
  Pc5h1s0_Lc5h0s10
  Pc9h1s0_Lc9h0s10
  Pc12h1s0_Lc12h0s10
  Pc13h1s4_Lc13h0s14
  Pc14h1s0_Lc14h0s10
  Pc15h1s0_Lc15h0s10
  Pc16h1s0_Lc16h0s10
  Pc17h1s0_Lc17h0s10
  Pc18h1s0_Lc18h0s10
  Pc19h1s0_Lc19h0s10
  Pc21h1s0_Lc21h0s10
  Pc22h1s0_Lc22h0s10
  Pc22h1s9_Lc22h0s19
  Pc23h1s0_Lc23h0s10
  Pc25h1s0_Lc25h0s10
  Pc26h1s0_Lc26h0s10
  Pc27h1s0_Lc27h0s10
  Pc28h1s0_Lc28h0s10
  Pc29h1s0_Lc29h0s10
  Pc30h1s0_Lc30h0s10
  Pc31h1s3_Lc31h0s13
  Pc34h1s0_Lc34h0s10
  Pc35h1s0_Lc35h0s10
  Pc36h1s0_Lc36h0s10
  Pc37h1s2_Lc37h0s12
  Pc37h1s4_Lc37h0s14
  Pc37h1s6_Lc37h0s16
  Pc38h1s0_Lc38h0s10
----------
only existing with errors: 5:
  
  Pc8h1s0_Lc8h0s10
  Pc11h1s0_Lc11h0s10
  Pc13h1s0_Lc13h0s10
  Pc14h1s1_Lc14h0s11
  Pc14h1s6_Lc14h0s16

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'.

K-den.

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.

K-den.

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.

(WHAT?!)

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.

NOW...

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:

  Pc2h1s0_Lc2h0s10

(P=Physical, L=Logical).

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

  Pc22h1s0_Lc22h0s10

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:

c2h0s10

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.