keithI created a disk with a textfile called AMIGA on it which contained thousands of “AMIGAAMIGAAMIGA” throughout the entire file. The idea here is that no matter which part I happen to read/decode, I can tell if something successful is happening.
data: ezfA<strong>AMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGA
AMIGAAMIGAAMIGA
AMIGAAMIGAAMIGAAMIGA</strong>AIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCA
EIMCAEIMCAEIMCA
EIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCA
EIMCA
EIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCA
EIMCA
EIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCKEIMCAEIMCA
EIMCA
EIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCA
EIMCA
EIMCADLW
(128487) Format: 255 Sector: 2 Track: 9 Sectors to end: 6
data: fh`]MIGA<strong>AMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGAAMIGA
AMIGAAMIGAAMIGA</strong>A
IMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCA
EIMCAE
IMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCA
EIMCAE
IMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCAEIMCA
EIMCAE
IMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCE
AIMCEA
IMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEAIMCEDLW]
Even the repeated AEIMCA or whatever that repeated string is encouraging! Just the repetition of the same characters tells us we are on the right, ahem, track.
I did make a minor modification to the SX source code, and this definitely helped. What I was doing was doublechecking to make sure we didn’t miss an edge. I’m not sure why, yet, but this doublecheck was processing an edge where it shouldn’t have been….. more on this later.
So, I’ve successfully found the SYNC pattern, decoded the sector header, and now read at least SOME data successfully from the sector.
Things are looking up!
Big progress, congratulations!
If we consider EIMCA sequence a distorted AMIGA original, then seems like every third bit (0000.0×00) is sometimes lost.
Can you use longer pattern, say, ‘ABCDEFGH…XYZabcdefgh…xyz’?
Or binary pattern 00 01 02 … fe ff would be nice, too, although won’t be as readable as ASCII one is.
Thanks.
Do you mean that the third bit of every byte is missing? Or that every third bit is missing? like 12x45x78x?
And how’d you figure that out? 🙂
oh, and did you notice it was two adjacent sectors? Sectors 1 and 2 of Track 9. And the “sectors to the end” field is accurate. Overall there has to be a fair bit of correct data in order to get this far.
I have transcribed ‘AMIGA’ and ‘EIMCA’ in binary. It looked like this:
A M I G A
0100.0001 0100.1101 0100.1001 0100.0111 0100.0001
0100.0101 0100.1001 0100.1101 0100.0011 0100.0001
E I M C A
Of course, this can be plain coincidence, but if you compare the two binary strings you’ll see the difference in the third bit in almost every byte.
That’s why I think of choosing another test pattern – to clearly see if other bits get spoiled, if any.
I think you’re almost there 🙂
Thanks for that.
Yeah, I plan on using a different test file with the full range of ASCII chars. The problem right now is that I’m really only seeing a limited number of sectors, when I should be seeing many more given the overall size of the sample. I’m seeing something (10) sectors (most with invalid data) per 100kb-200kb of raw MFM data. This should be MUCH higher — and you can tell by looking at the valid sector numbers that DO decode that I’m dropping all sorts of sectors. Also I’d have to add a little code anyways to pretty-up a hex output vs just dumping the raw ASCII to the screen the way I am now.
This is mostly related to not seeing the SYNC’s. If I don’t see the sync, then I don’t try to decode the sector header, because I don’t really know where the sector decoding process should really start.
So I really have to focus on why I’m not seeing the SYNC’s, and try to improve that, and then worry about the DATA later.
Now don’t get me wrong, I’m pretty excited about seeing the valid data!
And maybe by using a better test file, I might be able to determine WHY the SYNC’s are not being read properly. Is this the path you were going down?
Oh and the 3rd bit thing — No idea why that’s happening as it is. My code doesn’t treat any particular bit differently than any other one. Now what IS different, is that every 8th bit, the main routine puts the byte on the PC’s port, clears the storage, and starts again.
Which reminds me, perhaps an interrupt occurs when main is right before the clearing of the number of stored bits. That would cause the last bit written by the ISR to be dropped…. Hrrmmmmm….
You made a good point by thinking of DATA as a workbench for resolving the SYNC issue. In fact, there are plenty of DATA in the track, much more than number of SYNCs. Turns fishing into fun you know 🙂
On the third bit – it could be fifth bit, or eight, doesn’t matter. What does matter is the fact that some bit gets lost (or misinterpreted) quite periodically, and this can be tracked and shot down.
Is there an SX simulator for PC? So that you could trace your code step by step, perhaps using some stimuli file.
Heh. I was never any good at fishing, so I might be in some trouble.
Right, I figured there was much more data. However, it’s a little more complicated though, because the odd and even bits are spread out in the MFM encoding. Since they are spread out on opposite sides of the sector, knowing where the actual READING problem was isn’t so easy. I guess if you know what the data should be, you could tell which bits were off, and therefore which section of bits were in ERROR. But this is hairy! It’s tricky when there are multiple steps involved, because you don’t know which is at fault!
I think there might be an SX simulator, but how the heck do you provide the input data? Draw the waveforms?? I *really* wish I could capture the data coming out of the drive for a long period, like a few seconds, and review it at will. Right now I’m stuck with one screens-worth of (10) 2us divisions on my scope…. I’ll check out the simulator idea.
Stupid me. I keep constantly miss that weird odd/even bits thing.
As for input data – it is pretty simple. I recall reading someone’s explanation on how to build stimuli (sp?) data for AVR simulator. The person did that in MS Excel using some automation.
Or better yet, you may write a program that would build a test file on your PC pretending it be actual data output from floppy, and feed it into simulator [if there is one].
Pathetic!
I’ve just got my A1200, am trying to fit it with some HDD to have a more friendly environment for my floppy project.
Have you seen this page?
https://www.sxlist.com/techref/ubicom/simulators.htm
Some simulators’ descriptions look very appealing.
I finally got a newer working version of SxSim running. I’m going to play with that and see what I can come up with.