Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!COGSCI.BERKELEY.EDU!bryce From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) Newsgroups: comp.sys.amiga Subject: Re: Faster directories under AmigaDOS Message-ID: <8705131021.AA17984@cogsci.berkeley.edu> Date: Wed, 13-May-87 06:21:18 EDT Article-I.D.: cogsci.8705131021.AA17984 Posted: Wed May 13 06:21:18 1987 Date-Received: Sat, 16-May-87 02:10:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: na Lines: 106 Summary: Duplicate efforts -> you are not alone > > Shit. > > It seems like every time I come up with something resembling a useful > utility, someone else beats me to it, and comes out with something almost > the same. > > Now it's happened again. I *WAS* going to write a program for > publication in Amazing Computing that did faster directories. Then I found > out that Dave Haynie has been working on almost the exact same program for > the exact same magazine. No problem, thinks I, I'll just clean it up a bit > and throw it at the Net, or RoboCity News, or something. > > Now I log in to find this gentleman has already posted a program to > help speed up directories. It's enough to make a guy beat his head against > the keyboard. In fact, I think I will. > Was that your head or mine? :-) Well you are not alone. Here's my list: ** I wrote a icon merger, sent it off to a AmigaWorld (they like simple things like that). Then comes V1.2. Yup an icon merger. ** I wrote something on the lines of MORE. I started this AFTER V1.2 was out, but BEFORE I got V1.2. (March 78. Circumstances saw to it that Developers got upgraded from Gamma 1 to Release last) ** A friend spent months working on figuring out how to open windows and create menu strips. Then out came 'power windows'. ** I had just finished this neat hack and was going to post it for the entire net to see. I called it "TrackDiskMon". I dialed up and read the few messages on the net. You guessed it! TDEBUG had been posted not an hour before. -> And who wrote that? <- Matt Dillon who lives just up the street. ----> To add injury to insult HIS WAS BETTER! hmmph. <--- Well that kicked me in the right place and I dragged out some code I wrote a long time ago when I proposed that C-A put a certain change in V1.2. That change? Sort by track, not hash. The program? speeddir. > Oh well, you may as well have the program to see what I did. It > uses the AmigaDOG ACTION_GET_BLOCK packet to get raw disk blocks off the > disk and do things to them. Speeddir was a demonstration program, unfinished. It also works in a different way. It patches the pr_PktWait field and intercepted any ACTION_EXAMINE_NEXT packets. It did not re-call DOS with a GET_BLOCK but rather called trackdisk.device. The difference is that any directory list program is faster. > A couple of questions/comments for Bryce and Leo: > > On Bryce's "speeddir": > > As you pointed out, the drive motor for df1: does not turn off after > doing a "dir". It *does* turn off though after doing a "copy dfd1:foo ram:", > or similar command. Is it any "file system write" that deselects the drive, > or what? The actual DOS filesystem gets a "ACTION_TIMER" packet every so often. It uses this to tell the trackdisk.device to turn off after several seconds. Speeddir and DOS don't really talk to each other. Speeddir is actually a parisite and as such can't really tell if it is safe to turn the drive off without upsetting DOS. What *could* be done is to twoggle some bits or belch some packet that lets the DOS filehandler know that it should get around to turning the drive off soon. ----> This and how to access cached buffer are mysteries me <--- > Also, it is interesting that after installing speeddir, the little power > LED (not the drive LED) blinks alot when doing a "dir", or "copy" command. > Any idea what is causing that to happen? (BTW, this is using the Manx > "ls" command for "dir", and the built-in "copy" command of shell v2.05M.) Gee, I hope so. I said "HACKERS ONLY" and other expletives like "UNFINISHED". What you are seeing is my handy-dandy all-purpose BLINK macro. I just sprinkle a few BLINKS's in all my code and I know when it executes past that point. Here's BLINK: blink MACRO ;XOR the power LED move.l d7,-(a7) move.b $bfe001,d7 eori.b #2,d7 move.b d7,$bfe001 move.l (a7)+,d7 ENDM This code is also significant because it was the SECOND thing I ever wrote in 68000 or on the Amiga. The FIRST was a RTS. (both worked fine once I got ignored the mess of $%@!* that was passed off as assembler documentation and hacked it out alone) On BLINK per directory entry, just after it returns the packet. It was left in to remind people that the code is unfinished, buggy, experimental, etc. -bryce-