MFM IC's (Was RE: Any AMIGA users?)

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sun Jan 6 10:47:30 2002

see below, plz.

Dick

----- Original Message -----
From: "Pat Finnegan" <pat_at_purdueriots.com>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, January 06, 2002 8:39 AM
Subject: MFM IC's (Was RE: Any AMIGA users?)


>
>
> On Fri, 4 Jan 2002, Fred Cisin (XenoSoft) wrote:
>
> > Several of the newer variants of the 765, such as the 37C65, handle the
> > switch betwen FM and MFM entirely in software. Those will do FM/SD.
> > Almost any controller card that uses one of those chips can do FM/SD.
>
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.
>
> OK, With all this talk of drive controllers, I've got two questions that
> I've had little luck finding answers to:
>
> 1) Are there any IC's available today that will do MFM and
> write-precompensation, but very little else? Basically it'll need to do
> the MFM, have a PLL for decoding the MFM, some sort of 'start read' and
> 'start write' inputs I can trigger from a sector pulse, and a
> write-precomp. Another question: Is write-precomp that important?
>
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,
from what I've read, here in the list, I'd say it will be difficult to
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.
>
> 2) Where can I get one?
>
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.

> I'd prefer to have a 1, 2, or 3 chip solution to that at max, with a
> minimum of components. If you're wondering what I'm doing, I'm trying to
> put together an interface board that'll let you hook your RL02 up to a
> peecee (and a linux driver... hey I don't have experience in writing for
> other OS's).
>
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!
>
Received on Sun Jan 06 2002 - 10:47:30 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:53 BST