| ??? 07/09/07 14:23 Modified: 07/09/07 14:44 Read: times |
#141627 - It\'s because I know \"nothing\" about the controller Responding to: ???'s previous message |
Jan Waclawek said:
Richard Erlacher said:
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,[...] OK, that's 5MByte / s for me, if you deserialize the data. It's a digital stream coming out of the drive, I hope, not the raw analog output of the head amplifier... ? Yes, it's captured via an RS422 a receiver from the data cable. It also means 83kByte of data per track, isn't it. Yes, though I have to allow for speed tolerance (+/- ~1%) because there's a physical drive involved. However, the external "ROM" is also copied into one of the four SRAMs, in order to allow full-speed execution of the code, for which the BBRAM is too slow, and once the additional memory is provided, one might as well fill the memory map. There's some chance this hardware may be of use again in the future. I'm also allowing for overlapping two track buffers, and for doubling the sample rate, just in case that turns out to be helpful. Richard said:
[...] digitally synchronized with the data from the controller,[...] Do you really need that sort of synchronisation? I thought the point of using oversampling is to be able to "digitally lock" to the captured data afterwards... It saves a number of steps to do it this way, and makes the use of a table realistic, as opposed to sequential processing of the entire sample as a random bit stream. I mean, you could greatly simplify the capturing hardware if you simply capture at a fixed rate. I do capture at a fixed rate, but I adjust the phase whenever there's an invlaid pattern of bits, indicating a slip of the bit-frame relationship due to slightly differing crystal oscillator rates. Richard said:
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. I still have problem to understand why do you want to transmit the data at full speed. I thought, you could capture a single track, stop the capturing, transfer it to PC at whatever rate available, and only when the track has been transferred, tell the drive to move on to the following head/track. At least this is what I would try to do. The tracks are going to be formatted at the physical drive's rate rather than an arbitrary one. Since I know very little about the specifics of the DEC controller firmware, I can't anticipate how the controller will respond to too-long a response time from the drive, hence I have to use a drive that works. Therefore, I have to meet the real-world timing that the formatting procedure imposes. Is it too complicated to move between heads/tracks? Do you need the controller to be involved in this? How much control do you have over this? Why would I do that? I'm trying to determine details of the DEC controller's undocumented behavior. DEC imposed certain restrictions on the drives that they used. What these were was not published. It's anybody's guess how much speed tolerance the controller firmware will tolerate, and it's anybody's guess how much delay in the "Seek Complete" signal pr "Drive Selected" signal they tolerate. There's also no indication of how long they'll tolerate between a head select tag and the appearance of data on the data cable. I want to start with real-world figures for these values before proceeding with the rest of the job. Keep in mind that the DEC firmware provides a routine to format a drive, but provides no routine to format a single track. Aside from invoking that routine from the VMS command line, I have no option at all. Jan
Does that answer your questions? RE |
