danbabcock@eklektik.UUCP (/dev/ph1) (04/11/90)
dannys@csd4.csd.uwm.edu wrote in <3342@uwm.edu>: > ...I left the RDY line connected to the autoconfigure > part of the interface circuit but not connected to any drive signals. > Why does this work? Does software wait 500ms after motor-on before doing > any read/writes? I would think you would wait for the RDY line to become > active... I would assume that the trackdisk.device waits 500ms before bothering to check the ready line. After all, the ready line does not generate an interrupt, so this is the most efficient method. However, almost all custom disk code that I have seen (this includes many games and probably copy programs as well) uses the disk ready signal exclusively; they just sit in a loop waiting for it to be asserted. > What is software doing to make the drives click? (etc.) The drives are supposed to latch the disk change signal when the drive steps a track, so the Amiga steps the drive periodically to determine when a disk is changed. All the code does is step one track, inverting the direction each time. I don't recommend defeating this in hardware; it would probably be incompatible with many programs. There is an easy way to defeat this in software, though - just change the code to step in one direction instead of alternating directions. Many drives have logic to detect when they have stepped past track zero (track zero is the outermost track) and refuse to step further - but still latch the disk change signal! The change may be made directly via a one-bit patch on the kickstart disk (if you're a 1000 owner) or in EPROM (if you're a 500/2000 owner with one of those kickstart switchers) or by using SetCPU (if you're a '020-with-MMU or '030 owner) or by using a program such as NoClick (anyone). In fact, I wrote the first version of NoClick (it didn't work very well, but other people fixed it up). -- Dan Babcock / voice (412)-373-1753
deven@rpi.edu (Deven T. Corzine) (04/12/90)
On 10 Apr 90 21:47:31 GMT, danbabcock@eklektik.UUCP (/dev/ph1) said: danbabcock> The drives are supposed to latch the disk change signal danbabcock> when the drive steps a track, so the Amiga steps the drive danbabcock> periodically to determine when a disk is changed. Now what confuses me is this: WHY is stepping a track a requirement to update the signal?? Surely the drive detects it by some sort of mechanical or perhaps optic switch which is activated by the actual disk insertion -- so why not update the signal instantly? Is there supposed to be some value to it? Is there some technical obstacle, or was there? Was it just the semantics of whatever drive it was convenient to use? I don't get it. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
new@udel.EDU (Darren New) (04/12/90)
In article <DEVEN.90Apr12055052@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: >Now what confuses me is this: WHY is stepping a track a requirement >to update the signal?? I think the signal gets CLEARED when the drive is stepped. That is, once set, it stays set until the drive is stepped. Therefore, read the signal and then step the drive. The next insert or remove will set the signal again. -- Darren
deven@rpi.edu (Deven T. Corzine) (04/12/90)
In article <DEVEN.90Apr12055052@netserv2.rpi.edu> I write:
Deven> Now what confuses me is this: WHY is stepping a track a
Deven> requirement to update the signal??
On 12 Apr 90 12:17:58 GMT, new@udel.EDU (Darren New) said:
Darren> I think the signal gets CLEARED when the drive is stepped.
Darren> That is, once set, it stays set until the drive is stepped.
Darren> Therefore, read the signal and then step the drive. The next
Darren> insert or remove will set the signal again. -- Darren
Meaning it's a latch bit set by a pulse when the disk is inserted and
cleared when the drive is stepped? No, that can't work either; it
still seems in any evet that the drive must "know" at some level
whether or not there is a disk there... and it seems it must know
whether or not you step the heads. So stepping the heads makes it
tell the computer. Is this right? If not, what? If so, why?
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.tell@oscar.cs.unc.edu (Stephen Tell) (04/13/90)
In article <DEVEN.90Apr12101123@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: > >In article <DEVEN.90Apr12055052@netserv2.rpi.edu> I write: > >Deven> Now what confuses me is this: WHY is stepping a track a >Deven> requirement to update the signal?? > >On 12 Apr 90 12:17:58 GMT, new@udel.EDU (Darren New) said: > >Darren> I think the signal gets CLEARED when the drive is stepped. >Darren> That is, once set, it stays set until the drive is stepped. >Darren> Therefore, read the signal and then step the drive. The next >Darren> insert or remove will set the signal again. -- Darren > >Meaning it's a latch bit set by a pulse when the disk is inserted and >cleared when the drive is stepped? No, that can't work either; it >still seems in any evet that the drive must "know" at some level >whether or not there is a disk there... and it seems it must know >whether or not you step the heads. So stepping the heads makes it >tell the computer. Is this right? If not, what? If so, why? >Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu From looking at the hardware and a discussion here long ago, I believe its like this: The bare drive has a signal that says whether or not a disk is in the drive. This signal goes to the little interface board between the drive and the DB-23 connector (The interface is on the motherboard for internal drives, but a seperate board on the 1010.) Whenever this signal goes to "disk removed," even for an instant, it sets a latch on the board. Every so often, the system comes along and polls this latch. Then, it steps the drive, which clears the latch. If there's no disk in the drive, the latch immediately gets set again. The reason for the hardware latch is because otherwise it might be possible to change disks really fast while the software wasn't looking, or was tied up on some poorly-behaved system-stealing program. If there wasn't a hardware latch, the system wouldn't know that a disk had changed, and would procede to trash the filesystem on the disk. For example, re-writing a cached directory entry from one disk onto another. It probably could have been done some other way instead of stepping the drive. I don't think there is an extra pin in the cable; some of the alternative schemes could have been worse. It looks like the idea was to change from the standard drive interface as little as possible with that little interface board; the other things the board does like latching the motor on signal and reporting drive-id at powerup also fit nicely into unused bandwidth in the original (34-pin) drive connector. -------------------------------------------------------------------- Steve Tell tell@wsmail.cs.unc.edu CS Grad Student, UNC Chapel Hill.
deven@rpi.edu (Deven T. Corzine) (04/13/90)
On 12 Apr 90 17:14:53 GMT, tell@oscar.cs.unc.edu (Stephen Tell) said: Stephen> From looking at the hardware and a discussion here long ago, Stephen> I believe its like this: Stephen> The bare drive has a signal that says whether or not a disk Stephen> is in the drive. This signal goes to the little interface Stephen> board between the drive and the DB-23 connector (The Stephen> interface is on the motherboard for internal drives, but a Stephen> seperate board on the 1010.) Whenever this signal goes to Stephen> "disk removed," even for an instant, it sets a latch on the Stephen> board. Stephen> Every so often, the system comes along and polls this latch. Stephen> Then, it steps the drive, which clears the latch. If there's Stephen> no disk in the drive, the latch immediately gets set again. Okay, this makes sense. It would have been nice had they found a somewhat less obstrusive way to do it, or maybe they should have had the ROMs always try to step past track 0 instead of alternating -- it's officially a requirement for a proper Amiga drive that such not cause actual head motion, right? If it would always make a lot of noise on an Amiga, rather than the current clicking, you can bet few such Amiga drives would be sold... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
p554mve@mpirbn.UUCP (Michael van Elst) (04/13/90)
In article <DEVEN.90Apr12055052@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: >danbabcock> The drives are supposed to latch the disk change signal >danbabcock> when the drive steps a track, so the Amiga steps the drive >danbabcock> periodically to determine when a disk is changed. >Now what confuses me is this: WHY is stepping a track a requirement >to update the signal?? The drives will SET its diskchange signal just when the disk is ejected. You have to poll the drive to know the state. It will RESET the diskchange if a disk is inserted AND the heads are stepped. This is done to tell the drive that the diskchange state has been detected. You need this, if you poll the drive in long intervals, otherwise you'd miss a diskchange. The drives have ususally a separate line for the acknoledge signal. But the Amiga hasn't, so the stepping signal is used for that. -- Michael van Elst p554mve@mpirbn.mpifr-bonn.mpg.de