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.