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.