keithWhile this new ISR is indeed easier to understand and much more simple, I can’t help but remember what else my ISR used to do for me.
The four things I really lose are:
1> Any type of double 1’s protection
2> Idle mode (don’t store long runs of high ‘0’s.) which is related to
3> No more than three consecutive zeros (longest data group is 1-0-0-0) and
4> A falling edge to start each group of bits.
The idle mode is easy enough to deal with, I’ve just set it up to wait 500ms after turning the motor on, and then wait for the first high->low falling edge. Then I start storing bits. Otherwise, without that, I’d capture a bunch of 0’s. I now have a falling edge to start the capture, but not on each group.
As far as the double-1’s and no more than (3) 0’s, I’d like to think that everything is working fine, so as long as the data is good on the disk, it should come out of the drive and into the SX properly. I think those things sort of hid problems I had, so I’m glad to just get the raw data.
The other benefit is that getting raw data might actually come in handy, later, if I ever deal with the issue of copy protection, etc, where the data pattern isn’t strictly MFM.
I’m happy I’ve simplified things, and it’s going to stay this way for the time being.
If you happen to have a spare input pin, you could use it to wait for /RDY (active low) signal from floppy instead of 500ms delay. Don’t know if this will make any sense though 🙂
You know, I tried hooking it up, and it didn’t work as expected. I wasn’t super concerned about it, but thought it was weird.
For whatever reason, I just realized that all the outputs(not just readdata) from the drive need to be pulled-up. 🙂
I was updating my large binder of AFP papers, datasheets, notes, etc when I stumbled upon a couple explanations I had printed out of “open collectors”. The explanation that struck me yesterday was something like, “without a pull-up resistor, open collector outputs will have an indeterminate voltage.” And then I was like, “DUH.”
I had trouble seeing other signals as well, and this must have been the case.
My experience with the drives is that they really don’t start spitting out data until they are up to speed. I was noticing perhaps (1) garbage byte at the most coming out of the drive before it’s ready. Because of how the software works, extra bad characters are not problematic.
While I’m starting to run short on pins, I very well may hook this up anyways.
The more I think about it, the more I want to integrate the data separator function into the SX. I’d love to spit out properly bit & byte sync’d data, and even MFM decoded data, and send just the actual data back to the software. I’m not sure how realistic this is, but I think it would be nice. It would also greatly simplify the PC-side software, and this lends itself to portability on other platforms.
I am thinking about data separator functionality, too, as a part of write support of my project. Accepting data sent to the drive for writing would synchronize somehow for infamous $4489 pattern so that the rest of the MFM flow would not require any additional shift work.
Mustn’t be too hard I suppose, like ‘store last 32 bits until they form 0100 0100 1000 1001 pattern, then go’.