UPDATE: No, really this time! See the bottom... And more pondering on how to write the new disk...

-----------------------

I think I got 'em all, now...

There were a few questionables... some tracks that had multiple identical sectors... would make sense e.g. if those sectors were unwritten (after format). But, then... there're a few that're filled with 0xff, a few filled with 0x00, and a few filled with 0xea (or something similar).

These are a bit difficult to be *certain* are properly-IDed. But I think I verified it pretty well.

e.g.

Negative sector-IDs indicate data was found *long after* the alleged sector-ID... so most-likely is data associated with a *different* sector-ID which wasn't readable with that search-method.

Sectors with allegedly 1024 bytes are most-likely wrongly-read Sector IDs (which is verifiable with the mismatched ID-CRC). So, then, the corresponding data-CRCs are prefixed with the location where a CRC-match was *actually* found. Thus, 0x27d39 indicates a data-CRC of 0x7d39, and an "N" value of 2. (N is a sector-ID mark indicating sector-size... (128<<N).. so 2 indicates 512 bytes.

Alright... The last column indicates individual sector-extractions which were done previously (now weeks, if not months, ago)... These only exist if the floppy-disk-controller reported no-error (in either ID-CRC nor Data-CRC). If their CRCs match that reported by *this* extraction-attempt, then they're marked "OK". If they were found, previously, but not with this attempt, then their CRCs are in that column.

... So... in this example... we've read a CRC-matched Sector ID indicating sector-zero, with a verified data-CRC of 0xda6e... That one's a bit questionable, as other sectors also have that data-CRC. BUT that data-CRC matches that of a sector which is filled with nothing but 0x00. So, it could be an empty-sector.

The only remaining questionable-bit is the fact that the ID-CRC is prefixed with 1.

That happens when a sector-ID is matched with that on-disk... BUT... the address-mark, which is usually 0xa1 0xa1 0xa1, was read as 0xe1 0xe1 0xe1. This *could* be a quarter-bit-shift issue... But, again, I haven't *fully* wrapped my head around that. But what that 1-prefix indicates is that the ID-CRC was calculated *assuming* 0xa1's, but the program read 0xe1's. Well, if the 0xe1's were in-error, then how are we to know the ID itself wasn't in-error, as well...?

So, some amount of uncertainty, but I did my best within my understanding to verify that it's *unlikely* I'm mistaken... I had to do similar with numerous missing-sectors, and most were much easier to discern (e.g. they had *different* matching CRCs than every other verified sector, so therefore *must* belong to the only missing sector... right?)

So... Now... I think it's time to actually *write* the new disk. I have no idea how to do that, yet.

---------

Some things I'm still ignoring... sector-interleave... I'll probably write all the sectors in order, for now. It looks to me like they're *not* written that way on the original disk. They write them out-of-order so that they can be read-back as quickly-as-possible, while taking into account the facts of processing-time for each sector, and the amount of time it takes for the disk to spin around to the next sector. Clever, for the sake of speed-improvement, but not required (right?).

...I think that's it.

I might experiment with fudging some of the characteristics... E.G. there's a "gap-length" of only 16 bytes after the index-mark. And yet, there's 190 at the *end* of the track. And, if the thing I read before is true (that IBM-PC-compatible disk-controllers fail on sectors too close to the index-mark, which seems quite probable considering the *majority* of my missing sectors were sector-0...)... Then, why not throw, say, 90 of the 190 bytes from the end at the *beginning* instead? Of course, those 190 are based on the spindle-RPM at the time of write... So... who knows if that's a good idea. OTOH, I'm using the same *drive* in both the PC and the KayPro, so its RPM shouldn't vary dramatically in the two cases, and doing this would make the new disk more-likely readable on a PC in another drive. It's a thought, but maybe not really a concern.

And... if all that's true, then it's likely, if not probable, that I could've read this disk with "normal" means by merely adjusting the spindle-RPM potentiometer, as suggested in IMGDISK's documentation. Weee Months!

Nah, there were some non-0-sectors that were missing, as well... many, in fact.

---------

Update

Whoops, somehow I missed 3 more!

Got 'em now.

YEAH!

(ignore "error: '4/5'," bits below 0x08 are status bits, not error bits)

----------

Also, pondering how to actually write these floppies... Looks a bit difficult.

Apparently IBM-PC compatible disk-controllers have basically *one* option that'll allow for straying from the default format in the way I need to...

The default format is 9 sectors/track, whereas this disk managed to cram 10 sectors per track. *That* can be handled with the disk-controller, but what can't is changing of [most of] the gap-sizes... E.G. in one case the IBM-format gap-size is 50 bytes, whereas on this disk it's only 16. That means with that one gap, alone, we lose 34 bytes worth of data-space from our tenth sector, unless it can be made-up somewhere else. There are other gaps, too, which can't be changed.

What *can* be changed is the gap-size between sectors. IBM-format recommends 0x20 bytes between sectors, but this disk has 23 (decimal)... That's a pretty big difference. In fact, it's *almost* enough for another sector. ALMOST. But what that also means is that the disk-controller has to be accurate enough to write new sectors with such short gaps inbetween without overwriting the next. Seems reasonable for newer systems... then again, so does being able to read the first sector after the index... And that's been deemed a problem.

So, again, back to imgdisk (http://www.dunfield.com)... Wherein, it says, again, that the trick *may* be to slow the rotational speed of the disk from 300RPM to 290. The end-result, in this case, being that the data will be recorded *slightly* more densely,.. maybe *just enough* for that extra sector and bigger gaps...

But, then... when inserted in a drive running at 300RPM? Might want those gaps as big as possible!

I think I'll try first without... Use small-ish between-sector gaps. We'll see what happens. There *might* be enough space at the last gap, after the sectors, before the index that it won't overlap with the beginning of the track, despite the larger gaps elsewhere.

The other consideration is the fact that formatting the disk only formats the layout of the sectors, gaps, etc. But doesn't actually write information. Writing of information happens via individual sector-writes... ten per track... which, of course, means many chances for overlapped sectors (what with such small gaps). All that to say, it's not possible, within-specs, to write the entire track all at once in one long sequence.

Though, I suppose "The Trick" used to *read* the entire disk could be used to *write* the entire disk... hmmm. Big Problem: No way to *write* the address-marks with missing-clock-bits. Wonder how important those are... (that's kinda the point, to use the missing-clock-bits to indicate where address-marks are located...)

Another problem: That trick used, essentially, a sector-read with a sector-size longer than the track, itself. Sector-sizes can only be 2^N multiples of 128 bytes... so there's no way to specify a size that's exactly the length of the data (address marks, gaps, CRCs, sync bytes, etc.), nor the exact length of a track (which depends on the rotational speed, anyhow). So, would have to choose a size larger than the track... and... Maybe use some logic with the index-pulse to mask the write-process as soon as the disk spins one full revolution. Whew. Doable, but the missing clock-bit thing might be a bigger problem.

People pull this off much easier.