Subject: Re: proposal for MI floppy formatting
To: John Kohl <email@example.com>
From: Brett Lymn <firstname.lastname@example.org>
Date: 11/22/1996 12:23:40
According to John Kohl:
>Such an ioctl() would not be MI (in either Gordon's or Brett's case).
>The nec765 floppy controller hardware wouldn't be able to handle Brett's
Oops, the last floppy formatter I wrote was for a WDC chip and to
perform a format you fed the chip a byte stream of data complete with
funny codes that told it to write a PLL synch burst and so on. I had assumed
that other floppy controllers did the same sort of thing. My idea was
that you gave the chip this data via an ioctl - of course the contents
of the data buffer are not MI, they may not even work between machines
on the same architecture - if they use differing controllers. Maybe
we also need some way of querying which fdc there is for machines that
could have differing types.
> AFAIK, since it doesn't have the flexibility to do that sort of
>format. The kernel's driver would have to parse the user's buffer and
>reverse-engineer the formatting parameters, hoping they fit something
>that the hardware can handle--yucko!
As you say, yucko - but if you just provide the facility of saying
here is a databuffer, squirt it to the controller and leave the
contents of the databuffer to the caller that should be sufficient for
the wierdos that want to play with interleave and the like (eyes
misting over here remembering when I got a big performance boost
gained by doing 4:1 interleave on a 1Mhz 6809 :-)
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
"Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.