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

From: David Wood (
Date: 2005-11-22 18:45:31

MV forgot also to mention that the IDE64 has to deal with deblocking
512-byte blocks into the 256 byte blocks the c64 expects.

I'm not sure if the FS assumes 512 byte blocks, but in the event that it
does not, writing a 256 byte block involves three operations: Load the 512
byte block, change one half of the buffer, write the block back.

This is all done in PIO, resulting in 2k of aggregate IO bandwidth: Read
256-byte sector from gcr buffer, read 512-byte sector from ide, copy sector
from buffer to ide buffer, write ide sector).

IDE kinda sucks like that on systems that rely on 256-byte sectors.  I
shudder to imagine all the work the CMD HD does to deal with the odball
sector sizes (which on scsi can range from 128 bytes to 4kbytes per sector.
I think Ive even seen 8k in at least one drive manual).


On Tue, 22 Nov 2005, MagerValp wrote:

> >>>>> "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

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.