[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Disk II Family's Phase
On Sun, 16 Feb 2003, Bryan Parkoff wrote:
> Date: Sun, 16 Feb 2003 17:52:29 -0600
> From: Bryan Parkoff <BParkoff@satx.rr.com>
> 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