Re: Fast GCR decoding?

From: Michał Pleban <>
Date: Tue, 15 Jan 2013 15:47:54 +0100
Message-ID: <>
Hello! wrote:

> According to my count 186 cycles, although the answer is somewhat more difficult than that: I /would/ need 186 cycles, provided that I would read the incoming bytes off the VIA and be able to decode them on the fly (and the routine is bug-free :-). Since with 40+ cycles on most bytes I can't do it on the fly, I need to read/decode off-the buffer. That would add cycles and put me in the range of 200+ cycles, which is about the same as what 1571 routines do off the buffer.

OK, suppose you have 5 GCR bytes read from a disk, and stored in a small
buffer. They contain 8 nibbles to be decoded, something like this (most
probably I got the bit ordering wrong, but the general idea should be

; GCR:     0000000011111111222222223333333344444444
; nibbles: 0000011111222223333344444555556666677777

Suppose this buffer resides on a zero page, for speed efficiency.

Now, to decode first byte from GCR, you would need a routine similar to
this (again, probably I got the bit ordering wrong, I am just writing
this off the top of my head):

lda in+0	; 3 	First byte from GCR buffer
tax		; 2	First GCR nibble in X
and #%00000111	; 2	First part of second GCR nibble
sta tmp		; 3
lda in+1	; 3	Second byte from GCR buffer
and #%11000000	; 2	Second part of second GCR nibble
ora tmp		; 3
tay		; 2	Second GCR nibble in Y
lda table0, x	; 4	Decoding table of first nibble
ora table1, y	; 4	Decoding table of second nibble
sta out+0	; 3	First byte decoded

The idea is that one decoded nibble is always found in one GCR byte
(these are nibbles 0, 2, 5 and 7), and for the other nibble you need to
look at this byte and one extra GCR byte. So each decoded byte is
constructed from two GCR bytes.

The code above uses 31 cycles, and needs to be repeated four times (with
different bit and byte patterns of course). That makes 124 cycles, well
below your limit. Some optimizations could also be made, because some
GCR bytes are read twice.

You also need eight 256-byte lookup tables, that is 2 kB.


       Message was sent through the cbm-hackers mailing list
Received on 2013-01-15 15:00:45

Archive generated by hypermail 2.2.0.