Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!cornell!batcomputer!braner From: braner@batcomputer.tn.cornell.edu (braner) Newsgroups: comp.sys.atari.st Subject: Re: A challenge to you disk experts Message-ID: <1895@batcomputer.tn.cornell.edu> Date: Sun, 21-Dec-86 02:41:10 EST Article-I.D.: batcompu.1895 Posted: Sun Dec 21 02:41:10 1986 Date-Received: Mon, 22-Dec-86 05:36:41 EST References: <1866@batcomputer.tn.cornell.edu> <492@atari.UUcp> Reply-To: braner@batcomputer.UUCP (braner) Organization: Theory Center, Cornell University, Ithaca NY Lines: 48 Summary: Why I don't like file-by-file copy [] > [Allan Pratt wrote that file-by-file copy is OK, just have coffee...] File-by-file copy of a whole disk, especially when there are many small files on the disk, not only takes a long time (no big deal) but also puts a big load on the disk drive (including a lot of (unnecessary, in my view) head movement back and forth over the tracks). My home computing is critically dependent on the one drive in my 1040ST, and I do my best to make its job light. > [suggestions about special drivers to read SS disks expanded to > a nonstandard DS format] What I would like is to take a SS disk, say "open, sesame" and end up with a normal DS disk, that may be used anytime without loading any special drivers, just like standard SS and DS disks may be mixed in a session. So I would still like to see a realization of the programs I described. The more urgent one is a real fast AUTOCOPY, and I would write one if I knew the way to read a bunch of tracks as fast as possible (ever used STCOPY? :-). The version of AUTOCOPY I posted recently already uses a 27K buffer, and will not be very much faster just by reading tracks instead of files. (It now takes me about 55 seconds of disk-turning time from the time I turn on the ST until all my usual stuff is on the RAMdisk ready for use, including micro-C-Shell, microEMACS, and Megamax compiler, linker and libraries. Not bad, but far from the theoretical limit!) Hint for making AUTOCOPY (current version) work as fast as it can: Put the files to be copied close to the beginning of the disk (simply by writing them on the disk first, then the rest of the files...). Write them to the disk in the order they are to be copied. Also, when possible, copy a few large files rather than many small ones. In extreme cases it may be faster to transfer an ARC file and ARC.TTP and then extract the files on the RAMdisk (an operation easily incorporated into the login file of the shell you run off the RAMdisk). - Moshe Braner PS: I would love to see a program that allows the use of programs for one monitor (b&w or color) with the other. But I'm afraid the recent suggestion (process a video line during Hblank) won't work, since there isn't enough time then even for an optimized AL routine. Perhaps it could be done during Vblank, and if not the whole screen, then part of it each time. E.g. if I'm using the b&w monitor (70 frames per second) and transfer the color (logical) screen (with some translation) to the physical screen, one QUARTER each Vblank, I would still get 17.5 full frame redraws per second, quite enough for most purposes.