bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (05/13/87)
> > 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-
scotty@l5comp.UUCP (Scott Turner) (05/17/87)
In article <8705131021.AA17984@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >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. In my p-System port to the Amiga I had to deal with this. I even got to ask Bob Pariseau about it :-). Basically C-A wasn't too sympathetic about not having trackdisk.device auto-powerdown the drives. Bob saw this as a "feature" and I was supposed to be tickled pink at having to turn the motor off. :( So, everyone gets to do the following: 1. Setup a timer.device sub-system that gets the eqv of ACTION_TIMER packets for your code. 2. All your accesses to trackdisk.device must pass thru a "gateway" that lets the timeout code know a. drive # b. that it is being used c. When done that it is no longer being used, BUT restart powerdown time out. 3. The timer sub-system SHOULD, upon timeout, issue a flush call AND a motor off call. NOTE: in V1.0 and V1.1 there is a bug in the trackdisk.device dealing with flush that if it attempts to flush to a writeprotected disk it will bomb with an addressing error (someone did a move.l to the I/O Result byte :-) 4. Tinker with what exactly is a good time out period. :) 5. Fight with AmigaDOG over when the drive should shut down. Note that 5 isn't bad news, if you shut the drive off and the dog wants to use it, trackdisk.device will turn it back on. Just results in some extra speed loss, but hey, hard disk's have to have SOME advantages :). >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. A diskchange action packet maybe? >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 A smaller blink: blink MACRO ;Flip the power LED BCHG #1,$BFE001 ENDM The smaller blink has another advantage as well, it's atomic. The larger blink can cause "weirdness" in the system since an IRQ could occur just after the move.b $bfe001,d7, This IRQ could cause some sub-system to modify $bfe001. Then at the end of the IRQ the blink would un-do whatever changes were made with the move.b d7,$bfe001 with the OLD contents in d7. The BCHG however is non- interruptable and will complete properly in all cases except someone grabbing the buss from the CPU. In my new MicroForge driver I use a BCLR/BSET pair around the disk read/write code to blink the power LED to "simulate" a built in hard disk drive. I can dream right? :-) The explicit dim/full toggling is used rather than flipping it to give a measure of how long it takes to execute the operation. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)