Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!decvax!decwrl!sun!imagen!atari!apratt From: apratt@atari.UUcp (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: Re: A challenge to you disk experts Message-ID: <496@atari.UUcp> Date: Tue, 23-Dec-86 14:39:53 EST Article-I.D.: atari.496 Posted: Tue Dec 23 14:39:53 1986 Date-Received: Wed, 24-Dec-86 00:01:23 EST References: <1895@batcomputer.tn.cornell.edu> Organization: Atari Corp., Sunnyvale CA Lines: 67 > 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. The only way I can think of to say, "open, sesame" on an SS disk is to write a program which would (A) format the second side, (B) compact the data from its current, all-on-one-side format to the DS alternating-sides format, and (C) diddle with the boot sector to inform the system that this is a DS disk. That would take considerable head movement (which I take it you want to avoid) but could be done, and would only need to be done once per disk. The formats are just too different to allow some simple changes to make it all work out. > 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. The first suggestion is good: it will minimize the distance from the directory and FAT to the data. However, the second doesn't matter. The head-seek distance is conserved no matter what permutation of those files you use (provided they are all contiguous and the first files on the disk). The thing which will speed up your copy operation the most is a disk-block caching program like Beckmeyer's hard-disk accelerator. If it could be instructed to cache the blocks in the FAT and root directory, you would only have to read them once for the first file, and the directory searches involved in opening the subsequent files, as well as the FAT hits to determine where they are, would be done without any disk head movement at all. In that case, it really would pay to copy the files to the disk in the order they're to be copied to RAM, because then the head would march across the disk in one direction, until all the files were copied. The reason people don't write block-caching programs for floppies is that they can be asynchronously dismounted: you can pop the disk at any time. When you do that, you have to invalidate your cache. But to determine that this has been done, you have to ask about media change. Sometimes the routine which determines media change has to hit the disk, to check its serial number (that is, when the state it "maybe media has changed"). Hitting the disk undoes all the benefit of having a cache in the first place. Therefore, people don't write such caching programs, and you are out of luck. Finally, the way to read lots of disk blocks without stopping is to use a large buffer and the GEMDOS system call Rwabs. The Fread call uses this to get its blocks. You shouldn't have to touch it. If you are using the runtime library (GEMLIB's fread call), this explains your troubles. Also, you mentioned using a 27K buffer. Why not use a buffer as large as you can (whatever's left after your ramdisk and copy program have started)? You can find out how big it is, and where it is, by examining your own basepage. Finally, consider the time you have spent worrying about this. You will not make up that much time in saved disk accesses. Moreover, head seeking is exactly what disk drives are made to do -- I wouldn't worry about the wear and tear, especially if you have preventive maintenance done occasionally -- make sure no screws are loose, speed is within spec, etc. Things like that, and head wear, will cause failures long before your stepper motor gives out. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/