Incorrect floppy drive IDs
darrenfreeman opened this issue · comments
From the Amiga Hardware Reference Manual, 2nd edition page 357, or 3rd edition page 371, the first few drive IDs are as follows:
0000 0000 0000 0000 0000 0000 0000 0000 Reserved ($0000 0000)
1111 1111 1111 1111 1111 1111 1111 1111 Amiga standard 3.25($FFFF FFFF)
1010 1010 1010 1010 1010 1010 1010 1010 Reserved ($AAAA AAAA)
0101 0101 0101 0101 0101 0101 0101 0101 48 TPI double-density,
double-sided ($5555 5555)
Note how a standard Amiga drive, plugged into the external interface, should read as FFFFFFFF. This is because the /RDY signal is active low, so when the drive pulls /RDY low to signal its presence, the drive ID bits should read as all '1'. A missing drive, or DF0:, should therefore read as 00000000, which in the table above is reserved.
The code 55555555 is used for a 5.25" drive. This leaves AAAAAAAA as the high density 3.5" drive, which spins at half the usual speed.
ATK v1.3 correctly shows missing drives as 00000000, and standard drives as FFFFFFFF. However it shows HD 3.5" drives as 55555555, which indicates a shift-by-one issue in the ID reading algorithm.
ATK v1.18 is displaying 00000000 and FFFFFFFF interchanged, or in other words, the bits have been inverted. I'm guessing this was done to fix up the HD drive ID, but it's not correct. There are now two issues.
The drive IDs listed in the HRM do not agree with the definitions in the disk.resource header file, as used by the Amiga ROM:
DRT_AMIGA EQU $00000000
DRT_37422D2S EQU $55555555
DRT_EMPTY EQU $FFFFFFFF
DRT_150RPM EQU $AAAAAAAA
The drive-id reading algorithm in TestKit matches closely with that in a disassembly of disk.resource, which also agrees with the HRM. Just steps 2 and 3 as listed in HRM are merged into one in the disk.resource assembly code (MTRXD- and SELxD- are taken HIGH in one single write to CIABPRB)
FC491C not.b D3 ; inverts select bit
FC491E lea $BFD100,A0 ; CIA-B prb
FC4924 move.b #$7F,D0 ; prepares motor on
FC4928 move.b D0,(A0)
FC492A and.b D3,D0 ; motor on for selected drive
FC492C move.b D0,(A0)
FC492E move.b #$FF,(A0) ; deselect drive
FC4932 move.b D3,(A0) ; motor off
FC4934 move.b #$FF,(A0) ; deselect drive - this resets drive shift id port
FC4938 moveq #$1F,D1 ; loop 32x
FC493A moveq #0,D0
FC493C lsl.l #1,D0
FC493E move.b D3,(A0) ; select drive
FC4940 btst #5,$BFE001 ; check the /RDY bit
FC4948 beq.s $FC494E
FC494A bset #0,D0 ; if not set particular bit
FC494E move.b #$FF,(A0) ; deselect drive
FC4952 dbra D1,$FC493C ; process all 32 bits
FC4956 move.l D0,(A3)+ ; store result in DR_UNITID
FC4958 not.b D3 ; turn back select bit
FC495A rts
Note that this code is from a 1.2 ROM disassembly, but this exact same code is found in Kickstart 3.1 too (I just checked).
Kickstart 3.x trackdisk.device uses the DRT_ values directly on the IDs returned by above assembly code. No inversion. No shifting. Also note that above assembly code sets each ID bit (FC494A) iff /RDY is HIGH (FC4940 - FC4948). Hence the ID does not account for /RDY being active low.
In summary, TestKit was fixed to reflect the Amiga includes and how Kickstart behaves, whereas previously the ID was cooked (inverted) to fit the HRM Reserved and DD 3.5 values. I am confident it's now correct.
Fair enough! So the HRM is wrong, I can live with this.