keith
I bought at Saleae Logic which is an inexpensive logic analyzer. See link here.
It isn’t nearly as fast (only samples at 24mhz max), and it doesn’t have as advanced triggering capabilities, but it does do millions->billions of samples.
So, of course, I put it to the test! I recorded 5 million samples at 24mhz which works out to be 210ms, just slightly over a floppy track time of 203ms. I sampled an entire track, which is FANTASTIC if you know anything about logic analyzers. They just don’t usually store much.
Then I wrote a small C program which converts the exported binary data to RAW AMIGA MFM. I searched for binary patterns of the sync code 0x94489, and exactly 11 of them came up. Which means that my little code is working, the logic analyzer is correctly reading the data. I still have to try to decode this track and see if it decodes properly, but this is pretty neat. It’s like third party verification of what I’m doing.
I have these odd exception cases where sometimes a track refuses to read although the amiga reads it perfectly. I’m going to get the bottom of those cases.
I hate to say this, but everything just worked tonight. No problems. Brought back up the java client, programmed the SX, and off I went. Pretty neat.
I’ll have more to say on this logic analyzer, but the software is really nice, clean, simple. It does its job.
I can’t tell you for how long I’ve wanted to sample a whole track w/ some test equipment. You can buy $$$ logic analyzers and not get this type of buffer space…. It achieves it by doing real-time samples straight to the PC’s ram……
So I’ve had to play with my C program a little to get it working, but I think I’m pretty good. This C program, as mentioned, decodes the binary sample into raw MFM using a similar method to how my SX actually stores the MFM as it is received. It looks at the time (in this case, the number of samples) between pulses and then stores 10, 100, or 1000 in a long ascii string. Then I have a routine that converts that super long binary ascii string into separate binary bytes.
I have not yet run the track through the MFM decoder, because I’ve got to write a quick and dirty load-track-off-disk routine for it, but I’ll be doing this shortly.
I can do interesting analysis pretty easily with this. Here’s some of my (debug) output:
0x94489 detected at position 8023.
0x94489 detected at position 16727.
0x94489 detected at position 25431.
0x94489 detected at position 34135.
0x94489 detected at position 42839.
0x94489 detected at position 58263.
0x94489 detected at position 66967.
0x94489 detected at position 75671.
0x94489 detected at position 84375.
0x94489 detected at position 93079.
0x94489 detected at position 101783.
So there are the (11) SYNCWORDs I would expect.
total number of transitions is 44761
So almost 45000 pulses per track. Total bits recorded ~105,000. So almost 50% 1’s density.
fours=30405, sixs=11231, eights=3123
So 30,405 different “10” patterns
11,231 different “100” patterns
3123 different “1000” patterns
For this particular track.
I think it might be interesting to look at a large number of tracks, disks, etc to see if we couldn’t come up with an average, standard deviation,etc.