jmpiazza@sunybcs.uucp (Joseph M. Piazza) (08/17/87)
In article <1468@mit-amt.MEDIA.MIT.EDU> ralph@ATRP.MEDIA.MIT.EDU (Amiga-Man) writes: >Bravo ! Let's hear it for the development of a "super" workbench. >While were tossing ideas, let's also consider, > ... >- and ---> *FASTER DRAWER OPENING* <---, like by clustering "*.info" files > so it only takes *ONE* file open and read to get a drawer open. > ( Oops... maybe this isn't in the workbench, but in the "info" library.) OK. Here's a good article; From Byte Vol 11 No. 2 (that's Feb '86 to you and me), BYTE UK: Tripdos--The Roots of AmigaDOS, by Dick Pountain, p. 326: "The only penalties paid, as trade-offs for all the advantages, are that directory listing and file renaming are slower than in conventional systems, because there is no single place to go to look for filenames; the whole tree structure needs to be traversed to find the names. Metacomco is currently considering caching the directory structure to alleviate this problem ..." Hint, hint, hint, hint, hint, hint, hint. "... but from my limited experience of the Amiga, it doesn't seem too bad anyway; it's not much slower than an IBM PC by the time the latter's disk-access and screen-updating speeds have taken their toll." Poor comparison. Remember, each Mac disk has a file called DeskTop which holds copies of each files's icon and filename. If they could do it, why not the Amiga? Please? >Sounds like a hot product which, if written well, could achieve a really >high Amiga market penetration. ... You said it, brother. Flip side, joe piazza --- Cogito ergo equus sum. CS Dept. SUNY at Buffalo 14260 UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@cs.buffalo.edu BI: jmpiazza@sunybcs
john13@garfield.UUCP (08/18/87)
> In article <1468@mit-amt.MEDIA.MIT.EDU> ralph@ATRP.MEDIA.MIT.EDU (Amiga-Man) writes: > >Bravo ! Let's hear it for the development of a "super" workbench. > >While were tossing ideas, let's also consider, > > ... > >- and ---> *FASTER DRAWER OPENING* <---, like by clustering "*.info" files > > so it only takes *ONE* file open and read to get a drawer open. > > ( Oops... maybe this isn't in the workbench, but in the "info" library.) As well, since I don't think the idea of having a textual directory list is anyone's trademark, there should be something similar to the option on the Atari (not sure about the Mac) for "Display icons or text?". The window would then either present the usual icons, or a text dir listing with scroll bars, and the names could be clicked upon for info, rename, etc. Note that I don't really care about alphabetical listings, although I can't see why they should be slower than positional listings. If you want to see why IBM's and such have relatively fast directories, don't go to books of comp theory -- use the intuitive, visual approach. Rip (yeah!) the cover from an IBM drive and do a directory. The head just drops straight down onto the directory track, the disk spins, the directory prints, and that's it. I've done enough Disksalv's to know that, regardless of all the talk about hashed directory structure, all the good stuff is bunched together pretty well in one spot. Bryce, anyone, figure out a good FAST way around this (backwards compatible as well)! The Vorpal loader from Epyx for the C64 shows that it isn't too difficult to mix different types of files on the same disk, some that load like turtles and others that resemble lightning. And they offer a speed increase of about 25X over the normal 64 speed (yes, 2500%). John -- "She's sort of a 'pit baby', with interlocking jaws. We feed her on chicken parts." "But baby-fighting has been outlawed, hasn't it?" -- Tracy Ullman describing her infant daughter to David Letterman
daveh@cbmvax.UUCP (Dave Haynie) (08/19/87)
in article <3887@garfield.UUCP>, john13@garfield.UUCP (John Russell) says: > Keywords: ideas workbench > Summary: look! feel! > > If you want to see why IBM's and such have relatively fast directories, don't > go to books of comp theory -- use the intuitive, visual approach. Rip (yeah!) > the cover from an IBM drive and do a directory. The head just drops straight > down onto the directory track, the disk spins, the directory prints, and > that's it. I've done enough Disksalv's to know that, regardless of all the > talk about hashed directory structure, all the good stuff is bunched together > pretty well in one spot. Close, but no cigar, so to speak. All of the Directories and File Headers on a floppy do usually show up on a floppy grouped somewhere above the root directory block at 880. The big difference between listing an IBM directory and listing an AmigaDOS directory is the place the filenames are listed. You do notice when running DiskSalv that the file names don't show up when a directory is encountered, but when actually when a File Header is found. That's because the file header contains the directory name. The IBM keeps its file names in its directory structure. The result of this is twofold. First of all, if you're doing a directory, the IBM does one seek for a directory header and come up with a big pile of names. It then goes to the exact next block and gets more names, etc. The Amiga fetches one directory block, but then it must do one read, implying one possible seek, for each entry in that directory. As you mentioned, that can involve alot of head movement. If the Amiga file handler were optimized for track buffered floppies (what we're dealing with here) instead of being completely generic, this could be much faster, but it still implies more work than an IBM directory would. The second result of the Amiga disk structure is that all of the directories on a disk can be completely blown away and it's still possible for a program like DiskSalv to get them all back, complete with file names. You can't do this on an IBM disk. > John -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" PLINK : D-DAVE H BIX : hazy "I'd rather die while I'm living, than live while I'm dead" -Jimmy Buffett