Path: utzoo!utgpu!watserv1!watdragon!lion!ccplumb
From: ccplumb@lion.waterloo.edu (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: How does the blitter decode/encode MFM data?
Message-ID: <19804@watdragon.waterloo.edu>
Date: 15 Jan 90 19:06:31 GMT
References: <75676@tut.cis.ohio-state.edu>
Sender: daemon@watdragon.waterloo.edu
Reply-To: ccplumb@lion.waterloo.edu (Colin Plumb)
Organization: U. of Waterloo, Ontario
Lines: 30

In article <75676@tut.cis.ohio-state.edu> Ethan R Dicks <erd@cis.ohio-state.edu> writes:
>I have been poring over the RKMs and have not been able to figure this
>out... how does the blitter convert bit pairs into bits and bits into
>bit pairs for the MFM <-> raw data section of trackdisk.device?

Well, thank you for spelling "poring" right, but I'm sorry I can't offer you
any joy.  You know the basic MFM encoding scheme... between each pair of
adjacent data bits, insert a clock bit, which is 1 if the data bits are both
0, or 0 otherwise.

How the Amiga does it is to encode all the odd data bits, masking out the
even ones and replacing them with clock bits, in one run, and follow this
with the even data bits, the odd data bits masked out and replaced by
clock bits.  To merge them back together, it takes one pass of the blitter
to shuffle the two sets together again, a mask of 101010101010101... selecting
which block should supply the data bit at this point.

To encode binary data abcdefghijklmnopqrstuvwxyz, it gets split in half
to produce a_c_e_g_i_k_m_o_q_s_u_w_y_ and b_d_f_h_j_l_n_p_r_t_v_x_z_,
which are concatenated and the apropriate clock bits inserted in the
blank spaces.

This gets the job done quite neatly, but doesn't use the linear stretch
technique you want for graphics magnification.  Sorry.

(If you want *tricky*, try doing 1,7 RLL which has a 2/3 stretch factor.
The same interleaving technique can be used, although you have to divide
the data into sixths and shuffle the bits together.)
-- 
	-Colin