Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: MFM format and possible improvments
Message-ID: <1388@cbmvax.cbmvax.cbm.UUCP>
Date: Tue, 10-Feb-87 15:19:02 EST
Article-I.D.: cbmvax.1388
Posted: Tue Feb 10 15:19:02 1987
Date-Received: Wed, 11-Feb-87 20:23:10 EST
References: <8702050359.AA01021@cory.Berkeley.EDU> <4410003@hpcvcd.HP>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 25

In article <4410003@hpcvcd.HP> charles@hpcvcd.HP (Charles Brown) writes:
>While reading the Hardware Reference Manual, I got the impression
>that the decoding of the floppy bits to real bits is done in
>software.  I hope that is not true.  Perhaps that is part of the
>explanation for why the A1000 is so infernally slow.  With several
>floppy controller chips on the market, this seems counterproductive.
>
>	Charles Brown hplabs!hp-pcd!charles

The MFM encoding/decoding is not done by the floppy controller function
of Paula, however it is done using the Blitter hardware, rather than
software "bit-bashing".

While this has to be slower, in an absolute sense, than using a standard
controller chip, it does not neccessarily follow that this is a limiting
factor on system performance...

The advantage (if any) of this scheme is that you can read (or write) any
floppy format using standard constant bit cell timing.


-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)