From: MagerValp (MagerValp_at_cling.gu.se)
Date: 2005-11-22 18:01:00
>>>>> "AT" == antitrack <firstname.lastname@example.org> writes: AT> This still does not add up to 14 seconds of wasted time, AT> especially if you consider you have the whole rest of the c64 AT> memeory for GCR-decoding-tables to waste. AT> A harddisk ought to write 170 kilobyte in 1/10th of a second, if she's slow. You're seriously overestimating polled IDE performance here. IDE is only fast when using DMA, and even then you're limited to 1 MB/s on the C64. As far as I know IDE64 doesn't use DMA, leaving all the work to the C64. AT> Okay, lets add that up to ONE second, because it's a 64. Good. AT> Still 13 seconds left. GCR decoding as a 13 seconds excuse? Come AT> on dudes, never heard of fast GCR routines? If you look at the IDE64 performance measurements: http://www.volny.cz/dundera/compar.html you'll see that IDE64 can do sustained writes at about 40-45 kB/s. That leaves about 10 seconds for GCR decoding and drive delays (track and sector seek, etc). At about 44 cycles per byte, I'm guessing there's still a little room for improvement, though the effort needed might not be worth it as it'd be hard to gain more than maybe 5 secs. And still: you can't compare streaming raw gcr data without error checks from one drive to another with fully decoding sectors. And to get this thread back on topic: does anyone have fast, table based GCR decoding routines? Patrycjusz, what does your solution look like, if you don't mind sharing? -- ___ . . . . . + . . o _|___|_ + . + . + . Per Olofsson, arkadspelare o-o . . . o + MagerValp@cling.gu.se - + + . http://www.cling.gu.se/~cl3polof/ Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.