An Interesting Finding...

A project log for OMNI 4 - a Kaypro 2x Logic Analyzer

A while back I acquired a rare logic-analyzer, whose lone system-diskette needed backing-up. Now this page is all things OMNI 4

esot.ericesot.eric 03/10/2017 at 11:360 Comments

Here's a draft I wrote but didn't publish because of the rant at the end. But, it is what it is, just beware. Maybe skip the last couple paragraphs.


Briefly (hahahaha): What it does is breaks the entire track down to its MFM-representation. For this explanation, you could think of it like looking at the raw bits in a serial transmission (including handshaking bits, etc.).

Then it searches through the MFM bit-stream for specific things on the disk... E.G. "GAP3/4" indicates the end of a track, and is represented by the *byte* pattern '0x4e' repeated numerous times (190, in the track I'm working with).

The groupings of 32 bits are the MFM-encodings of two consecutive *bytes* read from the track... these are the bytes, as read from the floppy-disk-controller, then re-encoded in MFM for printout/searching.

So, from the beginning of the image, what we're seeing is the first location of an MFM-encoded 0x4e stored across two data-bytes stored in the track-file... It detects 190 '0x4e's, until the end located at file bytes 0x2b6c-2b6d. It happens to be shifted by three MFM-bits (1.5 data-bits).

These shifts occur because each time a sector is written, it isn't *perfectly* synchronized with the previous sector.

The line marked "END", then, is the first location of an MFM-encoded byte, after the 0x4e's that does *not* match 0x4e, This is where "GAP3/4" ends.

And this is a perfect example of where bits might get shifted... After GAP4 comes GAP0, This is the *beginning* of a track. You can imagine that if an entire track was written all at once, the disk would eventually spin around and could overwrite the beginning of the track with bits from the end of the track. Thus the two separate gaps, one written at the end, and another written at the beginning, which tend to overlap.

So, after GAP3/4 there's *most-likely* going to be a new bit-shift... and that means the data read-in from the floppy-disk-controller, for the next byte (or several) is invalid... It was originally written as 0x4e, but that's been overwritten slightly by a slightly-shifted 0x4e.

Anyways, back to the image...

What's interesting, here, to me, is the highlighted-bit indicating the detection of the end of GAP3/4. The next byte, 0x09.

That's where, again, GAP3/4 overwrote GAP0, where the end of the track overwrote the beginning of it. 0x09 is the result of two overlapping 0x4e's, one shifted by a few bits, with respect to the other. This isn't really a byte at all, but it's being treated as the "byte" following GAP4, so to detect the end of GAP4, we use the same bit-shift as was used to detect GAP4 (three bits).

OK, so the apparent-value 0x09...

But, don't be confused by the printout thereafter "Ending at 0x02b6d == 0x09".

THAT 0x09 happens to be the MFM-value of byte 0x02b6d *in the file*. That's the byte that's *not* been shifted by three bits. So, if you're looking at the bit-representation:

/- File Byte N -\ / File Byte N+1 \
10010001 01001001 00101010 01001001
   10101 01001001 001
                  00101010 01001001

The first 0x09, the one highlighted in the image, '10101 01001001 001' is 0x09, as detected with the same shift as the 0x4e's preceding it.

The second 0x09, "Ending at", '00101010 01001001' is that from directly reading the file-byte 0x02b6d, without any shift, at all.

So, that's just some coincidence, right...? Happens to have been a weird enough coincidence as to confuse my debugging... because I was having trouble with the fact that it was reporting the file-byte rather than the shifted-byte at another location in the code...

Also, note, those two values don't match...

The first one starts with a 10, the second starts with 00...

That's a matter of MFM-encoding... '0's are stored as one of two encodings either '00' or '10' depending on the value before it. So, (between that and some other factors) it's really not possible, with my understanding, to know the *actual* MFM-encoding of the diskette... I'm just guessing and taking some "artistic liberties" with the search-parameters. So, yes, in fact, that apparent bug isn't a bug at all, but just a coincidence...

10101010 01001001
00101010 01001001

That's easy to see *now*, but wasn't so easy in debugging...

We also have from the search-string-matching:

10001 01001001 001
10101 01001001 001 

So three different MFM-encodings of 0x09 in that image:

10001010 01001001
10101010 01001001
00101010 01001001

Technically, one of these is wrong, per MFM, but it works for our purposes.

And... We really don't even *care* about the value that happens after the 0x4e's in GAP4, just that we need to make sure the function exits with everything aligned properly for *other* cases.

Those other cases, as it stands, are showing the same effect, except even more deceivingly... because after GAPs often come SYNCs which are represented by '0x00's... So aren't at all helpful to the cause of determining whether the function detects and/or exits properly-aligned.


So, as I recall of MFM-encoding, at the moment... looking back at the three cases: the second ('101...') is the result of 0x09 following a byte which ends with its lowest-bit low, it would've been preceded by MFM bits '00'. The third ('001...') would've been preceded by a byte whose lowest-bit was high, or MFM bits '01'. But the first ('100...') isn't per-spec... 00 shouldn't follow 10. How'd that get in there?

If this were the MFM-bits as-read *directly* from the diskette, it could've happened due to the bit-overlap of GAP4 and GAP0... But in this case I had to *recreate* the (presumed) MFM-encoding based on the bytes returned by the disk-controller...

So, is my encoder wrong...? Plausible. Maybe even likely...

Here I see that it's got a bit-shift of *3* (which is a *data-byte* bit-shift of 1.5). So, as-read, it may be possible to come up with that (improper) string, if some of those zero-bits (either '10' or '00') were read as *1* ('01') by the disk-controller...


So, now, do I need to rethink my encoder/search functions to take that possibility into account? Probably. Hmmm...

In which case, I've just been "lucking out," again, that the particular track I've been working with happens to have everything aligned by *odd* bit-counts?

----- rant -----

...strung-along by dumb-luck again. I've lost interest in this project's path countless times already, keep looking into other directions, yet keep getting these stupid "lucky" things that suggest I'm on the right path. Just like the CGA card in #Improbable AVR -> 8088 substitution for PC/X

Wherein "dumb-luck" kept leading down a certain path, and yet the solution was unrelated and one I'd already known all-along and just forgot amidst all those misleading distractions.

And... when/IF I've finished...? What will there be to show for it, to contribute to the world...? *Maybe* a backed-up diskette, and a bunch of ramblings which are wrong countless times. Nevermind *working my ass off* for weeks on end, yet not being able to earn the roof over my head, the food in my belly. Nevermind the recurring reminder that I *should* be working *for pay* if I can pull this shit off... yet, I'm *not* pulling this shit off. Who could possibly justify paying me even minimum-wage for the work I've been doing for so long. But it IS WORK. By someone *highly-trained*, who *should* *expect* to be receiving an appropriately-large consultant/contractor wage. And instead does it for free, and gets degraded on a regular basis for relying on social-services... because, frankly, the friggin' universe seems out to prevent me from doing what I do best (and pretty much *only*).