Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!rutgers!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.programmer Subject: Re: Direct hardware drive access Message-ID: <20238@cbmvax.commodore.com> Date: 1 Apr 91 22:17:17 GMT References: <2147@pdxgate.UUCP> <20215@cbmvax.commodore.com> <20221@cbmvax.commodore.com> <2171@pdxgate.UUCP> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 72 In article <2171@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >jesup@cbmvax.commodore.com (Randell Jesup) writes: >>In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>>motor_wait btst.b #5,CIAA_PRA ; check READY line >>> bne.s motor_wait ; busy wait until drive is ready >>> rts >This code works perfectly fine on my A500. In fact, it's what I'm using >now. Of course, when taking over the machine it may not matter that this >is a busy loop. Checking every .1 seconds seems like a good compromise. >But you say it checks up to .5 seconds. Does it return an error if the >drive is not up to speed within .5 seconds? We specify that drives must be up to speed in .5 seconds. The .5 second max has two reasons: paranoia, since we hadn't been actively using the signal in 1.3, and also performance, since dskrdy may not be active for as much as .7 seconds after motor-on, even though the motor is up to speed (it has to wait for the magnet to come by the sensor). >I modified most of my routines to use constants as you mention. Like you >say, it's a good idea. I have my own include file that I have been adding >to since starting my assembler projects. I never quite figured out where >the common constants are listed so I just pick a suitable name and use it >from there on out. It is, of course, much easier than trying to memorize >bit numbers. They aren't in an include file. They're in the timing diagrams in the 1.3 HW manual and in the text of the low-level disk access article I wrote for AmigaMail a couple of years ago. >The Chinon timing diagrams in the Hardware Reference Manual explicitly show >that the direction should be set prior to stepping the drive. However, they >don't show how long, so I'm assuming just doing it in two different >instructions is the main thing. That is, using two different instructions >would still work on a 68030 machine? The 1.3 HW manual says explicitly that they must be set by two separate writes. 68030 has no affect on this. >Okay, what book should you use when accessing the drives at such a low >level? The Hardware Reference Manual is a good reference, but is somewhat >lacking in detail when it comes to such a low level of drive operation. I'm afraid the HW manual is about it. If you're really careful, know what you're doing and what is legal and illegal by inspection, the abacus book can be used a bit as a reference. It requires a LOT of separating the wheat from the chaff. >One final thing. A third party manufacturer is producing a high density >3.5" drive for the Amiga. Does anyone know what ID string it uses? Was >this ID string assigned by Commodore? Also, will the high density 3.5" >drives in the 3000UX be compatible with this third party drive? Is >Commodore going to set a standard for high density 3.5" drives? I assign ID strings. I assume you're talking about applied engineering. Normally there's no need for you to know other people's id numbers, the same way we keep HW manufacturer numbers private. If there is some reason, let me know. Since their interface to the HD modes is funny, the ID number won't help you. The new HD drives for the tower/UX are just 150 rpm versions of the current drives. They change ID depending on the disk in them, and 2.0 trackdisk reads the id on each disk insertion. Other than that, you merely read or write twice as much data. If you have need for more detailed info, contact CATS. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)