test results of my output file

What I wanted to know was if the output file that I collected via my setup was actually correct. I was confident that since I was getting 4489’s consistently, that I have to be at least part way there…….

The format of my output file should only contain the proper groupings of acceptable amiga MFM encodings, and those possibilities are:

10, 100, or 1000. So 2-bit, 3-bit, and 4-bit combinations.

Nothing else is acceptable and nothing else has been seen via the scope hooked up to the output.

I already had my file created, but it contained binary(read: vs text) 8-bit characters and I usually view this in HEX, but since I’m looking for binary(read: 0 vs 1) results that are all strung together, including across byte boundaries, then I have to look at a lower level. Here’s what I did:

I created a small program that reads in my original file byte for byte, and then output to a different file the binary equivalent, so a ‘0xAA’ input gives 10101010 output.

Then, I needed some way to be able to detect the groupings, but trying to do this programatically is a real pain in the butt. I couldn’t come up with a good way to do this. Perhaps some perl experts who really know how to manipulate some regex might come up with a way…..

What I did was to load the output which is now one large ASCII text file containing 1’s and 0’s (ASCII 48’s and 49’s) into Microsoft Word. Then I did a search and replace for the various cases, replacing them with NULL.

Search for “1000”, yielded 3,047 cases, or 12188 bits worth, or 1523.5 bytes worth.
Search for “100”, yielded 15,136 cases, or 45408 bits worth, or 5676 bytes worth.
Search for “10”, yielded 34,594 cases, or 69188 bits worth, or 8648.5 bytes worth.

Add these all up, and you get 52,777 groupings yielding 15848 valid BYTES of raw MFM encoding.

The total filesize was 15892 bytes, so that means that there are 44 mal-formed MFM bytes, or 352 bad bits. These would be cases where there were too many zeros trailing a one, or a one immediately following another one. These are invalid cases, that really shouldn’t exist.

I guess there are a couple possibilities

1. Maybe there are other cases(that I have yet to recognize) that come up much less often, namely 1+(4 zeros), 1+(5 zeros), 1+(6 zeros), and 1+(7 zeros), also 11111111. If I do the same search and replace and add these cases, my file ends up NULL. Perfectly. No bits off. I can’t believe my total solution is perfect — I can’t believe I’m not missing at least a bit here or there.

2. Maybe my hardware is slipping. I’ve long thought that even the new setup, although yielding SOME accurate results has got to be getting of out sync, if only for a group or two……