The hardware isn't the principal challenge in this case, friends, it's the software to interpret what's read or to-be-written. Moreover, trimming the file size down is just a part of the process, since it has to be reduced and then re-inflated in order to position the transitions correctly to effect write-precompensation. That requires diligent study of the various formats, modulation schemes, and error-detection/correction codes. Reducing the sampled data to binary files is not trivial, but once one has the hang of finding the data field after a probably somewhat disorderly write-splice on the diskette it's probably not that bad. Since the time used in the write-splice is limited, it can be found easily enough, simply counting bit-times. This is a VERY achievable task, and particularly with the inexpensive XIlinx CPLD's. Please see embedded comments below. Dick ----- Original Message ----- From: <CLASSICCMP(a)trailing-edge.com> To: <classiccmp(a)classiccmp.org> Sent: Tuesday, July 04, 2000 2:53 PM Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever mA multiple so ohms - What can be done in this case is to take a page out of IBM's book and terminate with 1K and keep the cable short. Now, they terminated with 1K on BOTH drives, but since it works on one, it works on both. If the cable is quite short, you can get away with a 1k pullup. The limit on package dissipation, can be dealt with by considering that only a very few lines will ever be driven at one time: DSn*, STP*, DIR-IN*, WG*, and DATA*. If you're worried about the dissipation, you can use multiple pins to drive these lines, and spread them around the device so you don't get "hot-spots" on the die. Some have open-drain outputs, but the tristate ones are as good. Instead of driving a negative going signal into the cable, you drive a buffered ground to the cable, enabled with the data. It's as fast as OC and just as easy.