braner@batcomputer.tn.cornell.edu (braner) (12/18/86)
[]
The fastest way to copy a disk's data is to copy the whole disk
(rather than file-by-file copy which is very slow).
A consequence is that most disks I got with PD software, and all
commercial disks, are single sided - and so are their back-ups!
Since I have a double-sided drive, I resent wasting half of each
of those disks. There are at least two possible solutions:
(1) Devise a way to copy the complete contents of a SS disk onto
a DS disk quickly, resulting in a half-full, fully functional
DS disk (on which you can save a lot of other files). I guess
this would be done by reading the whole disk into RAM, analyzing
it, modifying the stuff in RAM a bit (FATs, etc), formatting the
target (DS), and writing the data on it.
(2) Achieve the same or a similar result, but by post-processing an
existing SS disk (leaving the data in place, formatting the other
side, and modifying the FATs, etc). If making it into a DS disk
without moving the file data is impossible, perhaps it is possible
to make it work like two separate single-sided disks. It might be
necessary to run a little program to activate each side when it is
wanted (by modifying the boot sector).
Any disk experts up to the challenge?
I would also appreciate any info explaining how to emulate the incredible
disk-reading speed demonstrated by STCOPY 2.0.
- Moshe Branerapratt@atari.UUcp (Allan Pratt) (12/19/86)
Moshe Braner asks about single- and double-sided disks. You could make one physical DS disk into two logical SS disks by writing a device driver for a DS floppy disk drive which would treat one surface as one logical SS disk, and the other surface as another logical SS disk. This would involve linking in to the RWABS vector (like RAMDISKs do) and translating the device and logical record numbers for your two logical devices (M: and N: or whatever) into less-logical record numbers for the physical device (A:). You can also post-process an SS disk to make it a DS disk without copying the original information: you would have to write a device driver which modified the current DS logical record sequence (head 0, then head 1, then on to the next track) into a new one: track 0-79 on head 0, then tracks 79-0 on head 1. That way the existing data on an SS disk would not have to be moved at all. The information on the boot sector would have to be modified to reflect all the new tracks you're getting, and Side 1 would have to be formatted, but otherwise nothing changes: the FATs are the same size for SS and DS. Note that in neither case will the normal desktop format/copy routines work, not only because these disk formats are "foreign" to it, but because it checks explicitly for drive identifiers A and B. Ever notice that you can't copy a 360K RAMDISK to a floppy, except file-by-file? Same reasons. Having said all this, I think it all doesn't matter anyway: it doesn't take THAT long to copy an SS disk file by file. You can just go get a cup of coffee, or read a book, while the copy is taking place. If you have one drive, of course, you want to get a RAMdisk, so you can copy (file by file) from the original to RAM, then from RAM to the backup. Does everybody know that you can copy ALL the files on one disk to another, without selecting the files? If you want to copy B to A file by file, you can open A (the destination), then drag the icon for B into the open window for A. This will copy all the files, one at a time, including (of course) the directory structure. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
braner@batcomputer.tn.cornell.edu (braner) (12/21/86)
[] > [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.
apratt@atari.UUcp (Allan Pratt) (12/23/86)
> 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 \----------------------------------------------/
braner@batcomputer.tn.cornell.edu (braner) (12/24/86)
[] Thanks to Allan for the expert advice. My goal is not to minimize disk head movement, but to minimize disk use. Period. Unnecessary head movement causes longer disk-turning periods --> more disk (and head) wear (and more waiting time). I used a 27K buffer for disk read in AUTOCOPY since the speed does not increase significantly for larger buffers. (Indeed, the speed is almost up to its max with 9K!) There I used Fread() to read into the buffer. In AUTODISK (recently posted) I used Rwabs(), as Allen suggested. The whole idea behind AUTODISK is that I copy the whole disk as a block, starting with reading the boot sector and FAT, so I know how much to read on without re-reading anything. I very much wish I had a good disk-cache program. That would eliminate not only the need for dirty tricks like AUTODISK, but also (with a BIG cache) the need for a RAMdisk! The problem of handling disk-swappings (by the user, with no warning) is serious, but not insurmountable. For example, one could write a cache program that would keep track of the disk things came off of (not just sectors and drives), and would NOT delay WRITING of data to the physical disk. The former feature would allow handling data from two or more disks with one drive and no extra swapping, and the latter would avoid writing on the wrong disk and also after-the-fact reporting of write errors (common on floppies...). If the user does not swap disks too often, the program would not need to check the disk ID very often, and GREAT increases in disk throughput would become possible!! If I had the time for a large project like that, a GOOD disk-cache program would be my very first choice! Anybody out there up to it? Of course I've spent time on AUTOCOPY and AUTODISK, perhaps more than I'd ever regain from them. But EVERYBODY can now use them for free! It's part of my share in the great world of Public Domain Software. - Moshe Braner