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.