BTW, just one thing I want to clarify a bit when I toss an idea/technical guess into this thread... if I fail to throw a "kudos" for the work you've done so far or come across as a bit "critical" it's just me being me. (Which is usually "busy and not having a whole lot of time to compose my thoughts".) You deserve a lot of credit for taking this project this far... *much* further than usually seems to happen with these "wouldn't it be cool if someone made a device to do X for my old Mac, like other people have made to do X for their (insert other obsolete system here) machines?" threads. If I suggest that you do something differently from how you're doing it you can usually take it as an honest attempt to be helpful rather than simply being contrary or critical.
So, with that out of the way: I can certainly see the value in your suggestion of logging conversations with the HD-20 without necessarily understanding them so you can perform experiments like playing back what appears to be the initialization acknowledgement to see if it tricks the Mac into thinking an HD-20 is attached when one isn't. That said, I still think it might be of great value to downplay the HD-20 *temporarily* and concentrate on nailing down what it takes to make your microcontroller fully conversant with "IWM-speak". I'm a big believer in looking for opportunities to break big projects into smaller modules that can be tackled individually, and with the documentation you have on hand perfecting your IWM signal processing before continuing seems like the lowest-hanging fruit. And again, based on the documentation you have on hand probably the best way to do *that* would be to concentrate on what the IWM was designed to do, which is speak to a floppy drive.
There are certain fundamentals about the HD-20 that we just don't know... one of the biggest holes in our knowledge is we have no idea how seeking/sector addressing is performed with the device. Does the Mac know about the low-level geometry of the drive and use the control lines to send track stepping and head selection commands, or is the HD-20 treated as a linear block of sectors and addressing is entirely encoded inside GCR-encoded bytes sent via the IWM shift register? We could probably make some educated guesses about this by blindly watching conversation logs and watching how often the control lines change when doing a bulk data transfer, but we won't really learn anything about the actual syntax. (Particularly if it *does* use GCR-encoded control bytes extensively.) We *know* based on the documentation how the floppy drive should react when its control lines are toggled and also know it doesn't accept any high-level commands from the IWM's serial shift register so the task of separating wheat (data) from the chaff (synchronization bits and filesystem headers) will be *much* easier because there won't be any unknown needles (HD-20 control bytes) mixed in to confuse you.
This seems to me a somewhat logical order of operations:
1: Wire up your snoop cable to an external floppy drive. Log control line transitions and the IWM serial bits while performing some known tasks. (Mounting/unmounting disks, reading a sector, writing a sector, formatting, etc.)
2: Based on your logs and the IWM documentation, teach your microcontroller how to understand GCR to the point that you can write a known value to the disk and have the microcontroller able to grab the sector as its written and unpack it to its original form.
3: If you have enough memory/your microcontroller is capable enough, set it up so it can fully emulate an external drive. (This could actually be a two-step implementation. Step 1 would be "emulating the raw bits", in which your microcontroller fully decodes control signals but writes the GCR bytes in raw form to its flash device, which means that emulating an 800k floppy would probably take about 1MB of flash. Step 2 would be real-time encoding/decoding of the GCR signals and mapping them to an emulator-style disk image on a FAT formatted flash drive. This might require a fairly powerful microcontroller.) Note that if you get this working you'll have a marketable device already. Many people have wanted a flash replacement for the Mac floppy drive.
4. If you really want to make sure you got everything right, reverse it. Hook a Mac floppy drive up to your microcontroller and see if you can read disks produced by a Mac and write images out to real disks that a Mac can read. This proves that not only have you mastered *speaking* to an IWM, you can fully emulate/replace one as well.
5. *Then* you'll be fully equipped to tackle the project of cracking the protocol spoken by the HD-20. Put your now very highly educated IWM protocol analyzer/emulator back inline with the HD-20 and not only watch the signals, but watch the *bytes inside the signals*. You'll be in a much better position to understand what you see.
But again, take this totally with a grain of salt. If you think you're up to skipping steps 1-4, well, you might manage it. I do again think it's worth noting that the product of step #3 is already something people want, so even if you fail to ever crack the HD-20 you've already won if you get that far.
So, with that out of the way: I can certainly see the value in your suggestion of logging conversations with the HD-20 without necessarily understanding them so you can perform experiments like playing back what appears to be the initialization acknowledgement to see if it tricks the Mac into thinking an HD-20 is attached when one isn't. That said, I still think it might be of great value to downplay the HD-20 *temporarily* and concentrate on nailing down what it takes to make your microcontroller fully conversant with "IWM-speak". I'm a big believer in looking for opportunities to break big projects into smaller modules that can be tackled individually, and with the documentation you have on hand perfecting your IWM signal processing before continuing seems like the lowest-hanging fruit. And again, based on the documentation you have on hand probably the best way to do *that* would be to concentrate on what the IWM was designed to do, which is speak to a floppy drive.
There are certain fundamentals about the HD-20 that we just don't know... one of the biggest holes in our knowledge is we have no idea how seeking/sector addressing is performed with the device. Does the Mac know about the low-level geometry of the drive and use the control lines to send track stepping and head selection commands, or is the HD-20 treated as a linear block of sectors and addressing is entirely encoded inside GCR-encoded bytes sent via the IWM shift register? We could probably make some educated guesses about this by blindly watching conversation logs and watching how often the control lines change when doing a bulk data transfer, but we won't really learn anything about the actual syntax. (Particularly if it *does* use GCR-encoded control bytes extensively.) We *know* based on the documentation how the floppy drive should react when its control lines are toggled and also know it doesn't accept any high-level commands from the IWM's serial shift register so the task of separating wheat (data) from the chaff (synchronization bits and filesystem headers) will be *much* easier because there won't be any unknown needles (HD-20 control bytes) mixed in to confuse you.
This seems to me a somewhat logical order of operations:
1: Wire up your snoop cable to an external floppy drive. Log control line transitions and the IWM serial bits while performing some known tasks. (Mounting/unmounting disks, reading a sector, writing a sector, formatting, etc.)
2: Based on your logs and the IWM documentation, teach your microcontroller how to understand GCR to the point that you can write a known value to the disk and have the microcontroller able to grab the sector as its written and unpack it to its original form.
3: If you have enough memory/your microcontroller is capable enough, set it up so it can fully emulate an external drive. (This could actually be a two-step implementation. Step 1 would be "emulating the raw bits", in which your microcontroller fully decodes control signals but writes the GCR bytes in raw form to its flash device, which means that emulating an 800k floppy would probably take about 1MB of flash. Step 2 would be real-time encoding/decoding of the GCR signals and mapping them to an emulator-style disk image on a FAT formatted flash drive. This might require a fairly powerful microcontroller.) Note that if you get this working you'll have a marketable device already. Many people have wanted a flash replacement for the Mac floppy drive.
4. If you really want to make sure you got everything right, reverse it. Hook a Mac floppy drive up to your microcontroller and see if you can read disks produced by a Mac and write images out to real disks that a Mac can read. This proves that not only have you mastered *speaking* to an IWM, you can fully emulate/replace one as well.
5. *Then* you'll be fully equipped to tackle the project of cracking the protocol spoken by the HD-20. Put your now very highly educated IWM protocol analyzer/emulator back inline with the HD-20 and not only watch the signals, but watch the *bytes inside the signals*. You'll be in a much better position to understand what you see.
But again, take this totally with a grain of salt. If you think you're up to skipping steps 1-4, well, you might manage it. I do again think it's worth noting that the product of step #3 is already something people want, so even if you fail to ever crack the HD-20 you've already won if you get that far.
