silverdr_at_inet.com.pl
Date: 2005-11-08 01:10:30
On 2005-11-07, at 23:29, MagerValp wrote:
>>>>>> "ST" == Spiro Trikaliotis <ml-cbmhackers@trikaliotis.net> 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.