| ??? 07/09/07 05:10 Read: times |
#141588 - it's part of a larger process Responding to: ???'s previous message |
Jan Waclawek said:
Richard,
I followed you halfway through - you want to capture a serial stream of what we can see as random data at first glance. It would help if you'd tell us what amount of data are you talking about (how many bits (= heads) at once, and how long are you capturing (how long is a track) at which rate). Disk drives of that generation rotate at 3600 rpm. They only allowed you to use one head at a time. The MFM data was stored at 5 Mbits/sec, so there are 83333 bit windows per rotation, nominally, and, if one samples at 8x that rate, or 40 MHz, digitally synchronized with the data from the controller, one has a pretty good chance of capturing everything that the controller has to say. One does have to allow for speed variation during the capture process, since the controller is, at that time, talking to a real drive which has mechanical imperfections that result in slightly off-nominal rotation rate, index width, response to command tags. However, I got lost where you started mentioning the PC. You don't need to decode this on the fly, do you? What is the "formatter"? Or do you want to use fully those disks with modern PC, not only read old data?
Jan No, the data doesn't have to be processed on-the-fly, but it does have to be captured in real time, and transmitted to the PC while the next track is being "formatted" and at a rate sufficient to ensure that the controller doesn't overwrite its previous track. The controller on a microVAX 2000 is an SMC 9224, though I really don't care what the controller/formatter is. I know what a fixed disk format contains and how to recognize it. The only mystery is the ECC polynomial, and I should be able to extract that from the raw format as written by the controller. No, use of the disk drives is not a factor. I'm only trying to capture and study the format as written by the DEC controllers. Using 15-year-old hard disks would be quite foolhardy. The 805x really has very little involvement. I plan to attempt to reduce the effective sample density from 8x to 4x in the 805x, if preliminary examination suggests that it will work out, however, since the higher sample rate is just to detect any asynchronism between controller and sampler, and that can be accomplished via table lookup. The result will be that only half as much data has to be transferred to the PC. A one-clocker operating at 40 Mhz should manage that, and, in fact, even at 20 MHz it should work out OK, time-wise. The real question is whether the PC can keep up with the data transfer. The sampling will be at ~625 kB/second. With the data reduction I mentioned, it should be straightforward to transfer the data to the PC at half that rate, and doing the table lookup and resulting compression should present no problem. The only real issue is transferring somewhat fewer than 41KB of data to the PC in somewhat less than 16 ms. If I write the PC code in ASM, it should manage it on a 2 GHz notebook. RE |
