Re: D64 with IDE64 and a parallel connected 1541... record beaten!?

From: MagerValp (
Date: 2005-11-22 18:01:00

>>>>> "AT" == antitrack  <> 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:

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         +
     -       +            +    .

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.