Date: 2005-11-22 17:33:12
Zitat von MagerValp <MagerValp@cling.gu.se>: > >>>>> "MM" == Marko Mäkelä <firstname.lastname@example.org> 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.