Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.sys.amiga
Subject: Re: Faster directories under AmigaDOS
Message-ID: <126@l5comp.UUCP>
Date: Sat, 16-May-87 23:19:12 EDT
Article-I.D.: l5comp.126
Posted: Sat May 16 23:19:12 1987
Date-Received: Tue, 19-May-87 06:26:55 EDT
References: <8705131021.AA17984@cogsci.berkeley.edu>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Distribution: na
Organization: L5 Computing, Edmonds, WA
Lines: 61
Summary: Smaller blinker and discussion of turning floppy drives off.

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)