Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Direct hardware drive access
Message-ID: <20224@cbmvax.commodore.com>
Date: 1 Apr 91 07:47:36 GMT
References: <2161@pdxgate.UUCP>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 93

In article <2161@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes:
>   1. The documentation for DSKBYTR states that in read mode data is placed
>      here one byte at a time. I assume this is before DMA is started? For
>      the purposes of syncing or somesuch?

	DIsk data is available in the register.  It's possible to read data
directly with the processor using this, but tricky and highly liable to
break on different processors/machines if it works at all.

>   2. DMAON is DSKBYTR does not refer to actual DMA activity, but rather
>      that DMA is enabled?

	Yup.

>   3. Is there any way to busy loop on the completion of disk DMA? (I
>      realize that an interrupt is more elegant, but this is just a test
>      program.)

	Sure:  just check for a DSKBLK interrupt in INTREQR.  A DSKBLK
interrupt that merely signals your task is trivial, though.

>   4. The hardware manual mentions bugs in both reading and writing data.
>      Now, how am I expected to compensate for these bugs? For reading, I
>      assume I request an extra word?

	Always request 1 more word than you know you need for read (not
a problem, make the maximum read 6814 instead of 6812).  On write, make
sure you have a word of $aaa8 OR $2aa8 (depending on the last bit of the
previous word).

>   5. I use DSKSYNC on $4489. Is this correct, or at least for most disks
>      such as AmigaDOS disks? If $4489 isn't found does it keep searching
>      forever?

	$4489 is the AmigaDos and MSDOS standard (it's an "illegal" mfm
value that is guaranteed by the hardware to be both readable and writable).

>   6. The ADKCON register mentions precomposition. Is there a value for
>      precomposition that I should use with standard MFM data?

	Look at the public unit structures.  Normal amiga disks use no
precomp on cylinders 0-39, 01 precomp on cylinders 40-79.  The values
are available from the public unit structure.

>   7. Does anyone have examples of blitter routines which both encode and
>      decode raw MFM tracks? The hardware manual mentions this as a
>      possibility as have several people on Usenet. I suspect this
>      involves some tricky operation with the line mode, with which I'm
>      just not well enough adjusted to figure it out for myself.

	It's rather tricky (decode is fairly simple, encode is 4-pass).
I advise playing with blitlab a bit.  

	Decode:
	((odd bits word & 0x5555) << 1) | (even bits word & 0x5555)
	This can all be done in one blitter pass.

	The encoding is done in four separate passes.  Two passes
	encode the odd bits, and two passes encode the even bits.  The
	first pass encodes the data bits and the clock bits.  The second
	pass corrects the clock bits of the first pass by unsetting the
	clock bit of a zero cell that follows a one cell.  In all four
	passes input C is a mask of $5555.  This mask will be used to
	"cookie cut" the input into clock and data bits.  In all cases
	C refers to data bits and C* to clock bits.

	Equations are:

		Pass 1: AC + B*C*  (A=odd data bits of the source aligned
to the odd data bits of the dest, B=source data bits aligned for the clock
bits of the dest.  C=clock/data cookie cut mask($5555)).

		Pass 2: A*BC* + BC (B=result of the previous pass, BC
preserves the data from the previous pass.  A=data source delayed for
two bits - results in off bits aligned over the next cells clock. A*BC*
will unset the clock bit of any cell that follows a cell with a data of 1.
C=clock/data cookie cut mask($5555)).

		Pass 3: like pass 1, just for even bits.

		Pass 4: like pass 2, but A is delayed 1 bit instead of 2, and
even bits of course.

>If you are looking for a good article on just what MFM encoding itself is,
>and GCR for that matter, take a look at _Transactor for the Amiga_ Vol. 3,
>Issue 1, "Amiga Disk Encoding Schemes" by Betty Clay, pp. 70-73.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Thus spake the Master Ninjei: "To program a million-line operating system
is easy, to change a man's temperament is more difficult."
(From "The Zen of Programming")  ;-)