On Sun, 16 Feb 2003, Bryan Parkoff wrote: > Date: Sun, 16 Feb 2003 17:52:29 -0600 > From: Bryan Parkoff > Newsgroups: comp.sys.apple2 > Subject: Disk II Family's Phase > > It seems to be interesting that standard Disk Drive only uses Phase0 > that is turned on for reading and writing, but all Phase0, Phase1, Phase2, > and Phase3 are always turned off. Whether you read from or write to the disk has nothing to do with the phase. The phase is only used to move the disk's head to a track. As someone mentioned in an earlier post, turning the phase on and off moves the step motor a bit (i.e. a half-track) either towards track 0 or towards track 34. > I wonder why Phase1, Phase2, and Phase 3 > are not used for turning on. They all are. > Please explain what Phase do. I understand that it is used for stepping > arm to move from outer toward inner. Or vice versa. > Is it true that stepping arm always move from outer toward inner by > reading SELECTIVE track and sector? I'm not sure what you mean by that. The answer is probably "Uh, no, not quite." Please allow me to try and explain what happens. It is the job of the RWTS (Read-Write-Track-Sector, a special part of DOS 3.3 that deals with the hardware) to look for the track and sector. Since there is no way to tell the current track by somehow looking at the hardware, the RWTS has to keep track of the track everytime it moves the head, i.e. the track information inside the RWTS is either increased or decreased. If you are interested in how the disk drive's head is moved, please take a look at the DOS 3.3 function SEEKABS at address $b9a0: X = slot number * 16 A = new track STX $2b; slot number * 16 STA $2a; new track to be set to CMP $478; compare with old track BEQ done; exit function via RTS LDA #0 STA $26; counter loop: LDA $478; load current track STA $27; save current track for later SEC SBC $2a; subtract new track BEQ endloop; are we there? BCS dec; decrease or increase? EOR #$ff INC $478; OK, increase current track BCC label1; jump always dec: ADC #$fe; #$ff, because of carry ==> -1 DEC $478; decrease current track label1: CMP $26; compare track with counter BCC label2 LDA $26; the lesser of the two will be put in A label2: CMP #$c; lesser than 12? Than new index to table BCS label3 TAY label3: SEC JSR phaseon; $b9ee LDA $ba11,y; get first delay value for waiting loop JSR MSWAIT; $ba00 ==> wait a bit LDA $27; old track number CLC JSR phaseoff; $b9f1 LDA $ba1d,y; get second delay value for waiting loop JSR MSWAIT; $ba00 ==> wait a bit INC $26; increment counter BNE loop; jump always endloop:JSR MSWAIT; wait again CLC phaseon:LDA $478; current track phaseoff: AND #3 ROL ; phase on or off depending on carry ORA $2b; slot number * 16 TAX LDA $c080,x; switch phase on/off LDX $2b; reload x with slot number * 16 RTS $ba11: BYT $01,$30,$28,$24;delay value for switching phase on BYT $20,$1e,$1d,$1c BYT $1c,$1c,$1c,$1c $ba1d: BYT $70,$2c,$26,$22;delay value for switching phase off BYT $1f,$1e,$1d,$1c BYT $1c,$1c,$1c,$1c > Does it mean that software has NO WAY > TO TELL hardware to LOCATE track and sector. Yes, there is no way. It all has to be done by the RWTS. All that comes from the disk is just a simple bitstream which has to be followed by the RWTS to detect a sector. This is why it is necessary to put a sector header in front of the data field to tell the RWTS which track and sector it is reading at the moment. Perhaps you have wondered, why you hear this strange "clack-clack" noise coming from your disk drive when you switch on your AppleII. This occures, because the slot rom at $c600 (normally) will move the disk head to track 0. Since it has absolutely no way to tell where the drive head is, it just moves the head 80 times (see address $c63b) towards track 0. After this, the head must be on track 0, because there are no more than 80 half-tracks found with a standard 5 1/4 disk drive. The noise you hear comes from the step motor (or the drive's head? I'm not sure), because the program still wants to move the drive head even more outside towards track 0, although it is already there. The hardware does not quite like this and starts to groan. How much depends on where the drive head was before you've booted your AppleII. BTW.: There are about 70 half-tracks (at least) on your disk of which only 35 are used by DOS. The logical track number (0..34) is doubled internally to give the hardware half-track number (0..68). This was done, because the original disk drive's head was not precise enough to read and write data from/to half-tracks, because it could happen that data was also partly read from/written to the halftrack next to it. Still, IIRC some copy protections used the half-tracks to store the data (but then again with a full two half-tracks gap between them) to stop standard copy programs from copying the tracks since these only moved the head to the usual half-tracks (0, 2, 4, 6, ...) and not the odd ones (1, 3, 5, ...). > The hardware's job is to > retrieve each bit by reading from outer toward inner. Not necessarily from outer to inner. That depends on how you store your data on the disk. You may want to start at track 0 and end at 34, or start at 34 and end at 0. The filemanager layer which is put over this is a bit more abstract using track sector lists (TSL) etc. The DOS 3.3 image is stored on the first tracks of the disk, and the slot rom ($c600) will always load track 0, sector 0, but the rest remains up to you. > In fact is that it is the software's job to SEARCH track and sector > before track and sector are compared to match user's desire track and > sector BEFORE 256 bytes in a sector dump into memory. > Does it make sense? Yes, the RWTS has to move the drive's head to the right track and then searches for the sector before it can read it into memory. In case you are interested in learning more about how the disk drive works, and you also know a bit of C, may I advice you to take a look at the source code of some AppleII emulators that also emulate the disk drive. If you want, you can download the source from AppleWin ("http://www.jantzer-schmidt.de/applewin/") or Dapple ("http://sourceforge.net/projects/dapple"). Both source codes are publicly available with the AppleWin source code probably being the more accurate one. You will find here in much more detail how the disk drives actually work. Kind regards Holger