Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!wagner
From: wagner@utcs.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Great big huge floppy disk? (actually, disk details)
Message-ID: <1986Dec24.185704.2125@utcs.uucp>
Date: Wed, 24-Dec-86 18:57:04 EST
Article-I.D.: utcs.1986Dec24.185704.2125
Posted: Wed Dec 24 18:57:04 1986
Date-Received: Wed, 24-Dec-86 19:35:48 EST
References: <736@vaxb.calgary.UUCP> <1164@cbmvax.cbmvax.cbm.UUCP>
Reply-To: wagner@utcs.UUCP (Michael Wagner)
Organization: University of Toronto Computing Services, general purpose UNIX
Lines: 39
Checksum: 36692

In article <1164@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes:

>The Amiga floppy disk is controlled by a 
>section of the Paula custom chip.  This chip is told by the 68000
>what track to read or write, then it goes about reading or writing 
>during a specific DMA slot assigned to disk I/O.  

Actually, there are three DMA slots (hardware manual, pg. 187).  
Why so many?  If I understand the disk section of the hardware manual, 
each time slot transfers two bytes to/from DSKDAT(R) (pg. 235).
Each slot should be good for 30K of data transfer (15K+ scans per second*2).
The disk can only produce 28K/second of data (5 RPS*.5Ksectors*11sectors/rev).
Are the second and third DMA slot always unused?  Are they used for
interleaving other disk work?  Can any other disk work be interleaved?
Can one disk seek while another transfers data?  Can two transfer data
at the same time?  Can it walk and chew bubble-gum at the same time? :-)

>You always read full
>tracks with this controller.  Once a track has been read in by Paula,
>it must be decoded (Paula reads raw MFM data).  The blitter is used to
>decode this, usually a sector at a time, and it achieves this decoding
>in one blitter pass (though as I recall, it takes three passes to encode
>the data).  

Can the blitting to decode a sector overlap with reading another track?
(I think that Matt first suggested this).
In current practice (V1.2), does overlap occur?  Is it envisioned for a
future release?  Presumably, it would require double-buffering for the
tracks (not a bad idea, in and of itself).  Perhaps it should be an option,
so that storage-constrained systems wouldn't be hampered.

>Because of all this, floppy disk buffers are constrained to
>reside in Chip memory.  

I presume this is true only for the track buffers, and not for the cache?
(although I notice that, in the current release, the memory comes out of
chip and not fast memory).

Michael