kim@amdahl.amdahl.com (Kim DeVaughn) (05/12/87)
[ Some days you eat the line ... some days the line eat's you ... ]
Many kudos to Bryce, Leo, and (in advance) Dave Haynie for their work on
speeding up directory listings! This is *greatly* needed, and *long*
overdue ... thank you, thank you, thank you!!!
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?
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.)
On Leo's "eless":
Nice implementation! Looks alot like the Manx "ls", with the sorting done
in a variable number of columns, and the directories displayed in the cursor's
color (UNIX(R) "ls -FC" style).
Question: After I run Manx's "ls" a couple of times, further directory
listings are almost "instant", the data being obtained from the AddBuffers.
If I then run "eless", the 1st time the data seems to come from them
also, but on subsequent successive invocations of "eless" the data is *always*
obtained from disk. Any comments on what's going on here?
Thanks again for contributing to "the common good"!
/kim
--
UUCP: kim@amdahl.amdahl.com
or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim
DDD: 408-746-8462
USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086
CIS: 76535,25scotty@l5comp.UUCP (05/14/87)
In article <6561@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >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? Kim, have you studied Leo's use of the dos packets to request direct disk I/O? It kinda looks like it might do it, but I'm still studying what he has done there myself. >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. Many people are not aware that the "power LED" is actually under CPU control. One hack I made using this fact was to use it in a rebuilt MicroForge hard disk driver so that the power LED became a "hard disk activity LED" :). However, it is more often used for debugging code that can't use any "high level" means of communicating with the programmer. A perfect example would be in a IRQ service routine where you can't risk any I/O thru the system. I'd type in the manual reference for flipping the LED, as per Leo's request, but my hardware manual is currently 20 miles away... 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)
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/19/87)
In article <6561@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >On Leo's "eless": > >Nice implementation! Looks alot like the Manx "ls", with the sorting done >in a variable number of columns, and the directories displayed in the cursor's >color (UNIX(R) "ls -FC" style). > >Question: After I run Manx's "ls" a couple of times, further directory >listings are almost "instant", the data being obtained from the AddBuffers. >If I then run "eless", the 1st time the data seems to come from them >also, but on subsequent successive invocations of "eless" the data is *always* >obtained from disk. Any comments on what's going on here? > Good question. Wish I knew the answer. I noticed this behavior during testing. I am going through the DOS for the data blocks, so any weirdness you observe is the DOS's fault (isn't it always? :-) ). I can only assume that the ACTION_GET_BLOCK packet somehow trashes the buffering scheme, perhaps marking buffers as invalid (which, of course, makes no sense). I'm convinced MetaComCo is trying to sabotage the Amiga :-). Would anyone at Commodore care to explain this? Side note: I've received a couple of notes (one private, one public) concerning the size of my .signature. Odd, thought I, since it's only 564 bytes. However, not wishing to aggrevate the net.gods who so graciously provide me with this (largely) free information source, I've made a new one, which is 360 bytes. So, if you have a copy of the old one, save it; it may become a collector's item :-). _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor