Hi!
> or you could just replace the IWM completely and do away with the floppy drives totally and emulate protocols for drive 0 and 1.
Yup, that's my plan. The Plus Too hardware should act like an IWM with a pair of floppy drives connected to it, so reading/writing from memory-mapped IWM registers should produce the same results as on a real Mac. But behind the scenes, instead of the IWM and floppy drives there will be some combination of an FPGA, microcontroller, and SD card.
Replicating the IWM's behavior shouldn't be too difficult, I hope. The hardware can keep track of which floppy track is currently selected, by watching for track step commands sent to the IWM. The bigger challenge will be replicating the byte-by-byte data stream that the IWM returns when reading a track on the floppy.
I believe the data is a circular buffer consisting of all the sectors in that track. A read might start anywhere in that buffer. The IWM will keep returning bytes from that buffer, looping back to its beginning if necessary, as long as the CPU continues to poll the IWM read register.
The buffer will contain about 10 sectors (exact number depends on which track due to the changing drive RPM). Sectors in the buffer are separated by a large but indeterminate number of FF bytes. A special 3-byte signature D5AA96 marks the start of a sector. The format of the sector contents is documented in the MESS source code file ap_dsk35.c, and also in the book Beneath Apple DOS. The sector data is encoded using GCR, where every six bits of "real data" is encoded into an eight bit byte on the disk. The hardware will need to do on-the-fly GCR encoding of a portion of a DiskCopy 4.2 image, then the Mac OS will decode it normally just like a real floppy disk read.
It hopefully won't be necessary to disassemble the floppy driver code or use a logic analyzer, since the necessary details are already documented. But as a last resort, the answers could certainly be found that way.
It sounds doable in principle, but I'm sure the devil is in the details! If anyone's attempted something like this before or is familiar with the low-level 400K/800K floppy format, I'd love to hear from you. I'm just kind of faking this as I go along, making educated guesses about implementation details based on the incomplete information that's available.
> or you could just replace the IWM completely and do away with the floppy drives totally and emulate protocols for drive 0 and 1.
Yup, that's my plan. The Plus Too hardware should act like an IWM with a pair of floppy drives connected to it, so reading/writing from memory-mapped IWM registers should produce the same results as on a real Mac. But behind the scenes, instead of the IWM and floppy drives there will be some combination of an FPGA, microcontroller, and SD card.
Replicating the IWM's behavior shouldn't be too difficult, I hope. The hardware can keep track of which floppy track is currently selected, by watching for track step commands sent to the IWM. The bigger challenge will be replicating the byte-by-byte data stream that the IWM returns when reading a track on the floppy.
I believe the data is a circular buffer consisting of all the sectors in that track. A read might start anywhere in that buffer. The IWM will keep returning bytes from that buffer, looping back to its beginning if necessary, as long as the CPU continues to poll the IWM read register.
The buffer will contain about 10 sectors (exact number depends on which track due to the changing drive RPM). Sectors in the buffer are separated by a large but indeterminate number of FF bytes. A special 3-byte signature D5AA96 marks the start of a sector. The format of the sector contents is documented in the MESS source code file ap_dsk35.c, and also in the book Beneath Apple DOS. The sector data is encoded using GCR, where every six bits of "real data" is encoded into an eight bit byte on the disk. The hardware will need to do on-the-fly GCR encoding of a portion of a DiskCopy 4.2 image, then the Mac OS will decode it normally just like a real floppy disk read.
It hopefully won't be necessary to disassemble the floppy driver code or use a logic analyzer, since the necessary details are already documented. But as a last resort, the answers could certainly be found that way.
It sounds doable in principle, but I'm sure the devil is in the details! If anyone's attempted something like this before or is familiar with the low-level 400K/800K floppy format, I'd love to hear from you. I'm just kind of faking this as I go along, making educated guesses about implementation details based on the incomplete information that's available.