From: David Wood (jbevren_at_starbase.globalpc.net)
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).
-jbevren
On Tue, 22 Nov 2005, MagerValp wrote:
> >>>>> "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
>
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.