Re: GCR specification - where?

[nparker@cie-2.uoregon.edu (Neil Parker)]

In article <5dvt32$idf@wanda.vf.pond.com> russotto@wanda.vf.pond.com (Matthew
T. Russotto) writes:
>In article <5dtns1$ajp@staff.cs.su.oz.au>,
>Fred the Wonder Worm <ftww@cs.su.oz.au> wrote:
>}
>}I've recently unearthed my Apple ][+ and was somewhat surprised to find
>}that everything was in working order (I did clear the spiders out of the
>}case first, though).  Anyway, I want to find out precisely how the data
>}is laid out on the disk; much searching through FAQs and various other
>}places has revealed little more than that GCR (group code recording) is
>}used.
>
>Best bet is to track down a copy of Beneath Apple DOS by Worth and
>Lechner (sp?).  Although no one seems to have a description of the
>T0S0 nibblization for 13-sector disks. 

I've never seen such a description anywhere myself, so I offer the
following to help fill the gap:

The denibblizing routine on the 13-sector controller is as follows.  At
entry the accumulator contains 0, and locations $26 and $27 contain a
pointer to $300, and location $2A contains the number 3.  The raw data is
in two buffers--the primary buffer at $300-$3FF, and the secondary
buffer at $800-$899.  These two buffers were filled in the usual order--
secondary buffer backwards, and then primary buffer forwards.  The
checksum computation is identical to the ordinary 13-sector and 16-sector
checksums.

        TAY
L1      LDX #0
L2      LDA $800,Y
        LSR
        ROL $3CC,X
        LSR
        ROL $399,X
        STA $3C
        LDA ($26),Y
        ASL
        ASL
        ASL
        ORA $3C
        STA ($26),Y
        INY
        INX
        CPX #$33
        BNE L2
        DEC $2A
        BNE L1

Following the logic through, we see that the before-and-after pictures
look like this:

                BEFORE
            Primary buffer
$300 -> 0  0  0  a7 a6 a6 a4 a3
                   |
                   |
                   v
$333 -> 0  0  0  b7 b6 b5 b4 b3
                   |
                   |
                   v
$366 -> 0  0  0  c7 c6 c5 c4 c3
                   |
                   |
                   v
$399 -> 0  0  0  d7 d6 d5 d4 d3
                   |
                   |
                   v
$3CC -> 0  0  0  e7 e6 e5 e4 e3
                   |
                   |
                   v
            Secondary buffer
$800 -> 0  0  0  a2 a1 a0 d2 e2
                   |
                   |
                   v
$833 -> 0  0  0  b2 b1 b0 d1 e1
                   |
                   |
                   v
$866 -> 0  0  0  c2 c1 c0 d0 e0
                   |
                   |
                   v


                 AFTER
$300 -> a7 a6 a5 a4 a3 a2 a1 a0
                   |
                   |
                   v
$333 -> b7 b6 b5 b4 b3 b2 b1 b0
                   |
                   |
                   v
$366 -> c7 c6 c5 c4 c3 c2 c1 c0
                   |
                   |
                   v
$399 -> d7 d6 d5 d4 d3 d2 d1 d0
                   |
                   |
                   v
$3CC -> e7 e6 e5 e4 e3 e2 e1 e0
                   |
                   |
                   v

Comparison with figure 3.18 of _Beneath_Apple_DOS_ reveals that this is
essentially the same process that happens with other sectors, but in a
different order.  Also, if you look carefully at the code, you'll see that
it only decodes 255 bytes, not 256, so that the decoded sector ends at
$3FE.  The missing byte would have been made up of bits from $3FF and $899,
which the boot ROM reads from the disk, but ignores during the denibblizing
process.

               - Neil Parker
-- 
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker
                     "Bad move, Neil!"  -- The Tick

Unsolicited commercial e-mail to my address will be discarded unread.