Re: Fast GCR decoding?

silverdr_at_inet.com.pl
Date: 2005-11-08 23:57:00

On 2005-11-08, at 09:16, Spiro Trikaliotis wrote:

>
>> ST> in the 157x, there are other functions than in the 154x which are
>> ST> table driven. These are much faster.
>>
>> The problem with table based routines are that they're hard to fit in
>> the 1541's RAM - only 1.25k are available if you don't replace the
>> 1541's kernal routines.
>
> Yes, that's right. Anyway, silverdream did not tell us if he wants a
> general solution or not, thus, I gave him something better.

I wanted a general method, which would be substantially faster than  
the "bitshifter". What you gave me was exactly that.

> Another thing to consider: It might be worth to transfer raw GCR  
> data to
> the C64/C128/whatever and do the decoding there.

I shall do the basic tests and see what can be done with it. Actually  
right now I have a working code that transmits GCR in RT (one track  
at a time ATM) and decodes it in the computer but it is slow... on  
decoding of course.

> The disk can read in
> the next track while the decoding is done on the computer.

Without track buffer, you mean?

> The overhead
> of transferring more data (320 byte vs. 256 byte) might be less  
> than the
> time you gain by moving the decoding into the computer.

The best way would of course be to have both: decode faster AND  
transfer less :-)

If, however, the faster routines with large tables won't fit in the  
drive then either - as you say - the decoding should be done inside  
the computer or something in-between will have to be employed.

>
> This scheme is also used with the "warp" routines of
> SC/cbm4linux/cbm4win.

Yeah - that's exactly what I did first but the decoding performance  
was eating most of the fast transfer benefits.


-- 
The true hackers never die. It's just that at some age they tend to  
GOSUB and forget to RETURN.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.