Hi! Yesterday I did some measurements using a 5.25" HD PC drive, some disks (1541, SFD-1001, Amiga), 765debug (an excellent FDD controller debug program) and a digital storage oscilloscope. I measured the signal coming from the 'RDATA of the drive, and used 'INDEX as trigger. I've also looked up some docs about the subject. I suppose, the highest data density produced by native C= floppy drive (not counting the CMD FDDs that are MFM anyway AFAIK) is of the SFD1001s. The shortest period, found on the SFD1001 disk was somewhere about 3.75 us, and the next one was 5.25 us (please correct me if someone has more accurate data). Note that the PC drive runs @ 360rpm instead of 300. At track 68, the same periods are 4.55 and 6.55 us long, respectively). The pulse width is constant - I mean, the drive produces a stream of equally long 0.5us pulses with variable "distance" from each other. The 1541 is "slower", eg the shortest full period (pulse to pulse) is about 5.5us. The Amiga disk is of the same bitspeed as the regular PC MFM controller is @ 250kbps (e.g. one full bit is 4us long). Similarly to the 720K PC MFM format. Now let's add this together. The highest bitrate, supported by PC MFM controllers is 1Mbit per sec (2.88M disks). Most modern controllers actually support this mode (AFAIK, at least I could format tracks using this bitrate even on my old Pentium-100 PC). At this rate one decoded data bit is tranferred at each 1 us. We have 3.75 us time between each pulses, in the worst case. The next value is 5.25us, the difference in the length is 1.5us - less than 2 us, but more than 1 us. So - sampling the stream, and forwarding it 'on the fly' to the PC in MFM encoding is _possible_ - we just have to use the highest bitrate supported by the MFM controller. I'd use a microcontroller for the task. The timing is very tight, but on the other hand, not much people would feel like installing a huge TTL board for that task. An FPGA would be a very good choice, I'm just not familiar with them at all. Some consequences. If we could read a raw bitstream, by sampling it at each 1 us, the software on the PC would still need to do some tricks to reconstruct the original bitstream. Reason: although the sampling must be sufficient, it is still quite rough. But the streams could be reconstructed, with some knowledge on the actual (real) bitrate. Another consequence is that writing back a track could be possible too, it would just imply slightly more complicated tasks for the microcontroller. For example, a similar reconstruction should be done by the interface itself, before actually writing the real stream to disk. Another problem is to read both sides of the 1541 disk - when you insert the disk with the second side, the PC drive provides no index signal, thus the FDD controller won't even believe that the disk is spinning. ...And finally, there is the question of how to inform the interface to do a particular job. These are all just details I guess. The next thing that comes in mind is, if this is all worth the trouble to play with at all. I know 5.25" drives aren't manufactured since years. ...Does anyone still have 5.25" drives? Would it be a so much more convenient way to go that people dusted off their old 5.25" drives to reinstall them into their new PCs? Best regards, L. Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.