see below, plz. Dick ----- Original Message ----- From: "Pat Finnegan" <pat(a)purdueriots.comTo: <classiccmp(a)classiccmp.orgSent: Sunday, January 06, 2002 8:39 AM Subject: MFM IC's (Was RE: Any AMIGA users?) The only "catch" in many PC-based controllers is that the FM mode is suppressed by the hard strapping of one of the controller pins. There are two problems here. (1) the "available today" part is always iffy. (2) no controller chipset I've ever seen can do the MFM and PLL functions without additional support for a couple of reasons. (a) Though the PLL provides "bit-synchronization," byte-framing is established by the use of "address marks" in a soft-sectored environment. A system that writes essentially one sector per revolution of the disk, which is what I've gathered the AMIGA does, is an exception, since it's essentially hard-sectored. These address marks signify the nature of the data to follow, i.e. is it an ID address mark, and, if so, what sort, e.g. track or sector, or is it a data A.M. This practice resolves the ambiguity in which phase of the extracted clock is "clock" and which is "data." Some MFM chipsets used in HDC's, notably the WD1100 chipset, generated signals that were used to indicate the PLL was locked and that, having acquired synchronization, the PLL filter bandwidth should be reduced to retain lock. All of these functions were based on assumptions described in the overal structure of the format scheme, and, by omitting some of these features, as was done in the AMIGA, replicate the functions of the AMIGA's hardware/software scheme with hardware and software other than theirs. There is hope! With a little effort in cooking up a firmware set for the extremely inexpensive UBICOM SX28-100 microcontroller, which is very similar to a small PIC, it should be quite straightforward, at that MCU's 100 MIPS execution rate, to bit-bang the bitstream in order to incorporate both the PLL function and the byte-framing functions in a single part. Since these cost well under $10 each, and are in-circuit programmable using hardware you can easily build yourself and software available at no cost, this can be done at minimal expense. Another alternative would be the somewhat more costly, somewhat larger, and somewhat slower (not much, though, since the instruction set is more diverse and the program/data store on board is larger) DALLAS 89C420. That's a 50-MHz core on the 805x model, with a modified clock circuit that generates one instruction cycle per clock cycle. Either of these, and a wide range of others can easily handle floppy disk interface by conventional "bit-banging" techniques, while the faster ones I've mentioned can easily process a hard disk too. All that's required is a thorough understanding of the task requirements and thorough understanding of the controller's operation. This amounts to what is essentially building your own custom chip, but since the devices are generic and the tools are readily available, I'd say it's an attainable goal. Write precompensation is definitely necessary. With floppy disks, it required imposing a bit shift of about between 1/16 and 1/8 the bit rate. With MFM hard disks, the most common amount was about 60 ns against a 200 ns bit window. The most common compromise I observed in FDC's intended for both 500 and 250 MHz bit rates was about 160ns, or, essentially a 6 MHz clock. For hard disks of the '80's a 16 MHz clock would have worked just fine. Wherever current-generation single-chip microcontrollers are sold, though you might do better requesting a sample. If your experiment works out, you can write them an application note that they can publish. That, if you can convince them you're likely to succeed, will help get you the samples you need. That Dallas part is being sampled currently. The part is available in PLCC-44 on short notice with about a 6-week lead time on the DIP-40 package. ISTR that Mouser, among others sells the UBICOM (formerly SCENIX) parts in onesies if getting samples is a problem. You should have no trouble doing this with a single part, though it's a big job for evenings and weekends. ... good luck! Beware of trying to expand the range of capabilities too much, though!

----- Original Message ----- From: "Pat Finnegan" <pat(a)purdueriots.com> To: <classiccmp(a)classiccmp.org> Sent: Sunday, January 06, 2002 11:25 AM Subject: Re: MFM IC's (Was RE: Any AMIGA users?) I've of required 500 I can send you some PAL equations that will fit both functions into a 22V10 if you like (and I can find 'em again). Once you get to the point of programming a PAL and building hardware, I think you'll find it attractive to run an SX, as I mentioned before, at a convenient harmonic of the data rate you want to support and have it kick the data out in parallel format into a RAM buffer driven with some external counters. One advantage of using the DALLAS 50 MIPs part is that it has sufficient data memory space (64KB) to hold an entire track, even if it's oversampled, and then process it into NRZ or parallel format. It even has a built-in serial port so it can send the data to your host system as a block of data formatted for sync or async, however you like. You can combine the PLL and SIPO function by sampling the data each time the counter overflows and resetting the counter each time, or some similar scheme. A 66 MHz clock should produce the precomp you want, but if you want precisely that interval, it will probably have to happen externally to the MCU. If all you're doing is recovering the data, you won't need to deal with precomp. If you want to write, you absolutely want to precompensate. Picking a sample rate is, for me, a choice between 8x and 16x the nominal bit rate. 8x falls within the capbilities of the SX but is a stretch for the Dallas part. Sampling might have to be done in external hardware. Once you're to that point there's another approach you may want to examine. OTOH, many drives of that era produced both data and clock when they presented read data. You might find that helpful. These microcontrollers would mean a really small circuit. One of about three or four components. That would appeal to me. Another option would be to try to fit the schematic-based design of the original controller into a CPLD. (NOT and FPGA!!!) I've found that schematics of "old" logic seem to yield useable circuits in CPLD's, while FPGA's totally seem to want to ruin the timing. That would lead to a circuit about the size of half a dollar, that's easily modifiable, since the parts are in-circuit-reprogrammable. Dick

The PLL that seems to work the best for MFM is one that's in quadrature with the data in a sync field such that the VCO goes high 90 degrees before the sync waveform does. When there's a transition during the positive phase of the VCO, the data, presumably, but only if verified by some unique data pattern (Address Mark) or other signal, is a one. There are other approaches based on 2x clocks that accomplish the same decoding using two-bit codes, but if a timer is reset to the nominal bit window in quadrature with the negative transitions on the data stream, it doesn't matter which approach you use. For that PDP-8 controller, it would be useful to know the precise timing relationship between the sector pulse and the next valid bit, including the jitter. Once that's know, the recovery of data should be straightforward. The common thing used in data recovery circuits for MFM was an 8T20, which, IIRC, was a bidirectional one-shot. Such a function is ideally suited for recovering ones from the modulated stream. The same could be produced, methinks, with the state of the MFM latched at the leading edge of that data window to which I referred above, and the MFM then XOR'd with that during the window. If there's a transition, then there's a one. Otherwise, well, it's not a one. I'm puzzled at how one is supposed to discriminate between clock and data without Address Marks that have "missing" clocks. Unless the relationship between the sector flag and the record ID are quite precise and stabile, I'd say reliability is in trouble. As for simply entering the schematic into the CPLD software and running a fit, I'd feel quite comfortable that a '70's design would work find so long as all events are synchronized to a single clock and that all "one-shot" events are digitally synthesized in sync with the global clock. Because all the macrocells in a CPLD are just that, as opposed to lookup tables as they are in FPGA's, the "schematic of yesteryear" can be made to fit quite realistically, particularly in timing. Moreover, since most of the macrocells are directly associated with pins, they're quite observable at the device boundaries so you can hook your 'scope or logic analyzer to them if you like. You can do the same with an FPGA, but I believe the CPLD is inherently better suited for simple import of already working schematic designs. The software's free, so give it a try! Dick ----- Original Message ----- From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca> To: <classiccmp(a)classiccmp.org> Sent: Sunday, January 06, 2002 6:51 PM Subject: Re: MFM IC's (Was RE: Any AMIGA users?) circuit are