From: MagerValp (MagerValp_at_cling.gu.se)
Date: 2005-11-22 18:01:00
>>>>> "AT" == antitrack <antitrack@networld.at> 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.