Date: 2005-11-08 01:10:30
On 2005-11-07, at 23:29, MagerValp wrote: >>>>>> "ST" == Spiro Trikaliotis <email@example.com> writes: > > s> Does anyone know if there is a known, substantially faster GCR > s> decoding algorithm than the one in the drive's ROM? > > 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. I know, but I am generally looking for the method first. Then I'll see to what I can do with it. The 1541's GCR decoding is quite small and straightforward but slow as a dog. I was too lazy to do the cycle counting so I wrote a test code to check how many sectors per diskette revolution can I decode using that algorithm. I was naively hoping to get the decoding time to be similar to the read time but it showed that with read-decode-transfer I got between three and four sectors per revolution, which translates to decoding being about five times slower than reading... > > I worked a bit on improving Lasse Öörni's irqloader (based on Marko > Mäkelä and K.M/Taboo's code), and the best I could do was to partially > decode the GCR bytes into nybbles while reading. Do you mean you were able to split the GCR nybbles in RT? What do you mean by "partially" though? Could you elaborate a bit on the method and results, please? -- Staring into a computer screen is like staring into an eclipse. It's brilliant and you don't realize the damage until its too late Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.