antitrack_at_networld.at
Date: 2005-11-22 17:33:12
Zitat von MagerValp <MagerValp@cling.gu.se>:
> >>>>> "MM" == Marko Mäkelä <marko.makela@hut.fi> writes:
>
> S> - Optimised the new GCR conversion routines (about 3s gain). With
> S> this version I managed to make a 35 tracks d64image in 22.6s, which
> S> I believe to be a new record on the 64! Correct me if I am wrong.
>
> AT> Never heard of "15 seconds copy"? It needs 8 secs to read a disk and 8
> secs
> AT> to write it, without verify. What's so great about 22 secs?
>
> MM> I guess "without verify" also means that the GCR data will not be
> MM> decoded (or checked for validity). You cannot make a sector dump
> MM> ("d64image") without decoding the GCR data and interpreting the
> MM> sector headers.
>
> Also, when writing to IDE devices, there are mandatory 400 us delays
> after writing to the command registers, and there's handshaking for
> every byte as it's written to the command buffer. If the IDE device is
> FAT formatted there are extra FAT writes every 4k or so (unless you
> keep the FAT in RAM, which I doubt here). The 1541s on the other hand
> can just stream bytes over the parallel cable.
>
> Apples and oranges.
This still does not add up to 14 seconds of wasted time, especially if you
consider you have the whole rest of the c64 memeory for GCR-decoding-tables to
waste.
A harddisk ought to write 170 kilobyte in 1/10th of a second, if she's slow.
Okay, lets add that up to ONE second, because it's a 64. Good. Still 13 seconds
left. GCR decoding as a 13 seconds excuse? Come on dudes, never heard of fast
GCR routines?
--------------------------------------
Ein Service von http://www.networld.at
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.