erd@tut.cis.ohio-state.edu (Ethan R Dicks) (01/15/90)
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? I am looking to adapt this technique for a quick and dirty "zoom" process, whereby I feed the blitter a byte which gets expanded into 16, 32, 64, or 128 bits for a graphic editor/inspector. If the MFM code can double/halve ths input data width, up to four more shifts should be available. Any pointers? ;-) -ethan -- Ethan R. Dicks | ###### This signifies that the poster is a member in Software Results Corp| ## good sitting of Inertia House: Bodies at rest. 940 Freeway Drive N. | ## Columbus OH 43229 | ###### "You get it, you're closer."
ccplumb@lion.waterloo.edu (Colin Plumb) (01/16/90)
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
sjorr@sunee.waterloo.edu (Stephen_Orr) (01/17/90)
The blitter first copies the track next to itself, and shifts that second section by one bit. This means that in the first section you have all of the odd bits (in the odd bit positions), and in the second section you have all of the even bits (also in odd bit positions). This is then 'clocked' and written out to the drive. An article on this very topic (and the source of my knowledge) was written by Betty Clay, and appears in V3 I1 of the Amiga Transactor. Stephen
a186@mindlink.UUCP (Harvey Taylor) (01/19/90)
In <19804@watdragon.waterloo.edu>, ccplumb@lion.waterloo.edu (Colin Plumb) writes: |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? | [how it works] | |This gets the job done quite neatly, but doesn't use the linear stretch |technique you want for graphics magnification. Sorry. | There is a description of this (and some disassembly) in the Abacus Amiga Disk Drives Inside and Out [Chapter 9]. | |(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.) | Have you implemented RLL on the Amiga, Colin? "Puritanism is the haunting fear that someone, somewhere may be happy." -H.L. Mencken Harvey Taylor Meta Media Productions uunet!van-bc!rsoft!mindlink!Harvey_Taylor a186@mindlink.UUCP
ccplumb@lion.waterloo.edu (Colin Plumb) (02/02/90)
In article <242@sunee.waterloo.edu> sjorr@sunee.waterloo.edu (Stephen_Orr) writes: >An article on this very topic (and the source of my knowledge) was written >by Betty Clay, and appears in V3 I1 of the Amiga Transactor. It is also wrong in a couple of points, most notably in asserting that GCR, due to its 4/5 data rate, achieves greater density than MFM's 1/2 rate. It does not point out the need for the two differnt bit clock rates (2us and 4us) due to the different minimum run lengths in the codes. Since it's safe to clock out MFM at twice the rate, it gets 20% more bits in the same amount of disk space. The interaction of encoding schemes and analog channel design (everything that talks to the read/write head) is a complex one. See Magnetic Recording (especially volume II, computer data storage) by C. Denis Mee and Eric D. Daniel for all the details. This three-volume set has more than you ever really wanted to know on the subject. -- -Colin