No, I'm not even suggesting that the CatWeasel is ver close to what was called for in the earlier discussion regarding an archival format for data normally distributed or contained on FD's. What I was getting at was that, while the CatWeasel seems to work OK for some things, and, in fact, quite a few, it probably doesn't read/write hard sectored disks and it probably doesn't allow minute adjustment sector-by-sector of the data on the diskette in order to make the format and the data fields within it all clock-coherent. It was my suggestion that the device be supported with software to allow not only that data be extracted from the bitwise oversampled data recorded as in Tim's buffer, but also that software be generated to permit the data to be reduced, essentially, to just the data in the data fields with some set of information (which was TBD when I last looked) implying the nature of the format in which it was recorded. Further, it was to be able to write the data into any known format, including known formats not supported by the controller available to the user. My suggestion was that a good test would be to write an Apple][ diskette using a PDP-8. I've also suggested that a "perhaps even better" approach might be to generate FDC code for the Scenix SX to do the job of several different and increasingly scarce FDC chips. This would easily support the function I was going on about earlier. It's easy, of course, to wachs poetic about what things could or should be. I've got a first-attempt at an EPP interfaced board down on the shelf in the basement. It may, someday, have the abilities I've suggested, but I'm not interested in making a large investment in time until I have convinced myself that when the hardware's done, there will be a point in having built it. Without adequate support software to interpret and regenerate the bitstream recorded from a floppy drive, I'm not sure the hardware's worth building. I did want to demonstrate interchangeability between 5-1;4" diskettes written on my Apple-][ and my Ampro, for which I have the needed hardware (if I can find my Apple . . .). I'm quite certain that will work, though I don't know it's needed. OTOH, there are diskettes which are no longer available or for which drives are such a maintenance headache it would be easier to handle them with a different drive type, except the system doesn't support them. That's where I was headed. The Catweasel may be a good model to keep in mind, but the comment about bits moving around over time does give me pause. Have a look at my embedded remarks below, plz. Dick ----- Original Message ----- From: Tim Mann <mann(a)pa.dec.com> To: <classiccmp(a)classiccmp.org> Cc: Richard Erlacher <richard(a)idcomm.com> Sent: Tuesday, July 04, 2000 8:45 PM Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever I'm inherently version of I simply mean that the Catweasel and Tim's buffer/sampler board are two shots at two different targets. There's little point in comparing them unless the overlap more than they appear to do in the writing I've seen up to now. unfortunately, Perhaps it has the capability, but as I said, it's after a different end. We're not trying to replace FDC's here, but rather simply want to read, save, and rewrite formats foreign to our systems with as little pain as possible. see I guess that's as good a reason as any. 48 MHz oscillators are cheap and available almost everywhere. Maybe those would serve in a similar device.

On most of your points, I agree. There's no reason to assume the Catweasel won't work for what's wanted here, and it's possible I'm overemphasizing the harmonic series available with the "right" crystal frequency, but the very fact that you've seen bit shift over time in dealing with the same files suggests something's out of whack. The fact is that, while a crystal frequency of a more or less precise harmonic of the data has a good chance of "doing it" correctly the off-harmonic timebase the Catweasel uses has no chance at all of generating a correctly timed output under any circumstances. I don't know how important this is. It's certainly not an issue for recovering the data. There's no reason it can't read diskettes and it's software interpret the sample data correctly, but it can't, under any circumstances generate the correct timing on writes. This isn't due to the write precompensation, with which it probably doesn't deal at all, but certainly could do closely enough, depending on the drives, etc, but because of the frame-slip inherent in alignment of a bitstream sampled at one rate but having to be resolved to another. What concerns me is that in the Catweasel case, the data is sampled at a rate that allows correct recovery of the data, but there's no timebase for generating a correctly timed output bitstream. It does have to be "close enough" though, since software can correct the stream to within ~70 ns per bit. Crystal oscillators are specified to 100 ppm for commercial applications. With that level of accuracy, a "slip" won't occur very often, and even more seldom close together. OTOH, when the sample rate is at 14x the data rate, a bit will slip into the adjacent window every 128 bits, worst case or 255 on the average, as compared with a crystal that's at a harmonic of the data rate, to within 100 ppm, which will slip every 2e8 bits on the average. Consequently, it's reasonable to believe that there's some software compensation for this inherent asynchronism. Unfortunately, that suggests that there is accomodation in the software for this built in problem. Otherwise, I'd suggest simply changing the oscillator to 16 MHz to see whether that mitigates the bit shift you've observed. please see embedded comments below Dick ----- Original Message ----- From: Tim Mann <mann(a)pa.dec.comTo: <classiccmp(a)classiccmp.orgCc: Richard Erlacher <richard(a)idcomm.comSent: Tuesday, July 04, 2000 10:46 PM Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever quite a You'd have to allow for mechanical variations here so the resulting diskette would have proper timing with respect to the sector hole, but that could, in fact, be achievable. I was thinking it might be a good application for a ninth bit of memory in the buffer so you can adjust the data stream to fit the occurrence of index/sector diskette you're It's absolutely adequate for sampling. I'm not sure it's corect for writing, however. data in Much of that work has already been done, I hope. There was considerable discussion about it a couple of months back. It would be nice, however, to know, not just guess, that the oscillator frequency is correct and not just adequate, for both reading and writing. > > The Catweasel may be a good model to keep in mind, but the comment about > > bits moving around over time does give me pause. > That comment had nothing to do with the Catweasel specifically. What > I've observed is that when reading old 8" disks, some look as though they > were written with way too little write-precompensation. I was speculating > that there was enough precomp initially, but that the bits have moved > over time. I might have been completely wrong about that; maybe there > was not enough precomp initially, but the original data separator circuits > were good enough to read the disks anyway. In any case, you'd see the > same thing with Tim's board or any sampling-based hardware. It's precisely the write precomp and the resulting bit-shift, or, rather, lack of it, that concerns me here. In theory, 14 MHz should be adquate for sampling analog data, the highest frequency component of which is 7 MHz. However, the data that's sampled passes through shaping circuits which mask the actual events at the media/head boundary. > > I simply mean that the Catweasel and Tim's buffer/sampler board are two > > shots at two different targets. There's little point in comparing them > > unless the overlap more than they appear to do in the writing I've seen up > > to now. > They are exactly the same *hardware* approach, except that the Catweasel > has an ISA interface and Tim's has a parallel port interface. The *software* > that comes with the Catweasel is not the software you're proposing, but > that software hasn't been written yet for Tim's board either. If it looks > like a duck and quacks like a duck, we can make duck soup from it even > if the person who raised it was more interested in duck eggs. Clearly, since the Catweasel has an ISA interface, it will work for those who have a free ISA slot, but it's of limited usefulness to folks who don't use ISA. Further, the two approaches, though similar, are not identical, due to the asynchronism between nominal oscillators. Tim was taking into consideration the fact that many folks in this forum don't use ISA-compatible computers, yet would like to be able to read/write foreign diskettes. Of those, perhaps 10% want to build hardware. If the Catweasel offers a solution, I'm all for using it, but there are unknowns, and a significant share of the ones who do build hardware do it so they'll KNOW what they've got, and won't have to guess what it does. A trial run with a 16 MHz oscillator in place of the 14 MHz might be a solution, though it might require a close look at the code to defeat whatever is done to adjust for the asynchronism of the rates, if necessary. It may turn out that it works just fine with that alteration. Building an ISA port isn't terribly complicated, but it's bit more of a job than making/using a parallel port. Since the job of hooking up a CPLD and a RAM is pretty minor and almost anyone who's paying attention, even those who have never built hardware before, can hand-wire one in a couple of hours and program the CPLD with a total investment of less than $20, (mitigating the risk, I'd say) I don't think one should overlook that aspect. It's likely lots of code will have to be written either way. > Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org > Compaq Computer Corporation, Systems Research Center, Palo Alto, CA

There must have been something wrong with my tone to prompt Tony's reply, sorry. Certainly if you're a hardware hacker, it will sometimes be faster to build your own gadget than to buy it off the shelf, and it's easier to modify. If you're a software hacker, it's a lot easier to buy the hardware off the shelf as long as it does what you need. I'm sure there are some of both types on this mailing list, and many shades of gray in between. Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org Compaq Computer Corporation, Systems Research Center, Palo Alto, CA