Re: Fast GCR decoding?
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.