Hello! silverdr@wfmh.org.pl 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 correct): ; 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. Regards, Michau. Message was sent through the cbm-hackers mailing listReceived on 2013-01-15 15:00:45
Archive generated by hypermail 2.2.0.