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 <email@example.com> 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.