| Re: [hatari-devel] Re: Hatari floppy drive detection with EmuTOS |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 16/01/2014 18:28, Roger Burrows a écrit :
On 16 Jan 2014 at 10:46, Nicolas Pomarède wrote:
Do you have the possibility to test this on a real ST :
- connect drive A and disconnect drive B as above
- but in the drive detection test, test drive B first, then drive A..
I'd like to know the delay you get in that case where spinup is made
first on the disconnected drive.
I'll do that as soon as I've finished testing my current EmuTOS update. Today
if things go well :-).
For reference, this is what TOS 1.04 does :
D6 is the command to execute (0x03 in that case)
$fc153e : 3029 0002 move.w 2(a1),d0
$fc1542 : c03c 0003 and.b #3,d0
$fc1546 : 8c00 or.b d0,d6
$fc1548 : 2e3c 0004 0000 move.l #$40000,d7
$fc154e : 3cbc 0080 move.w #$80,(a6)
$fc1552 : 6100 00d2 bsr $fc1626
$fc1556 : 0800 0007 btst #7,d0
$fc155a : 6606 bne.s $fc1562
$fc155c : 2e3c 0006 0000 move.l #$60000,d7
$fc1562 : 6100 00a4 bsr $fc1608
$fc1566 : 5387 subq.l #1,d7
$fc1568 : 6712 beq.s $fc157c
$fc156a : 0839 0005 ffff fa01 btst #5,$fffffa01
$fc1572 : 66f2 bne.s $fc1566
$fc1574 : 6100 00a6 bsr $fc161c
$fc1578 : 4246 clr.w d6
$fc157a : 4e75 rts
timeout_reached_no_drive :
$fc157c : 6104 bsr.s $fc1582
$fc157e : 7c01 moveq #1,d6
$fc1580 : 4e75 rts
send_force_int :
$fc1582 : 3cbc 0080 move.w #$80,(a6)
$fc1586 : 3e3c 00d0 move.w #$d0,d7
$fc158a : 6100 0086 bsr $fc1612
$fc158e : 3e3c 000f move.w #$f,d7
$fc1592 : 51cf fffe dbra d7,$fc1592
$fc1596 : 6100 0084 bsr $fc161c
$fc159a : 4e75 rts
write_command_d6 :
$fc1608 : 6124 bsr.s $fc162e
$fc160a : 33c6 ffff 8604 move.w d6,$ffff8604
$fc1610 : 601c bra.s $fc162e
write_command_d7
$fc1612 : 611a bsr.s $fc162e
$fc1614 : 33c7 ffff 8604 move.w d7,$ffff8604
$fc161a : 6012 bra.s $fc162e
read_status_reg_d7
$fc161c : 6110 bsr.s $fc162e
$fc161e : 3e39 ffff 8604 move.w $ffff8604,d7
$fc1624 : 6008 bra.s $fc162e
read_status_reg_d0:
$fc1626 : 6106 bsr.s $fc162e
$fc1628 : 3039 ffff 8604 move.w $ffff8604,d0
fdc_pause:
$fc162e : 40e7 move sr,-(sp)
$fc1630 : 3f07 move.w d7,-(sp)
$fc1632 : 3e3c 0020 move.w #$20,d7
$fc1636 : 51cf fffe dbra d7,$fc1636
$fc163a : 3e1f move.w (sp)+,d7
$fc163c : 46df move (sp)+,sr
$fc163e : 4e75 rts
The TOS check if motor is already ON in status reg and use $60000 or
$40000 as a timeout counter depending on the result.
Then it sends command 0x03 and check whether command completes first
(OK, return d6=0) or timeout expires first (FAIL, return d6=1 and send
force int command).
Roger
P.S. I will also test with the "disable spin up" bit set in restore, since I
agree that makes sense. If detection is not made worse, I'll update EmuTOS
subsequently with that change.
It can only be faster and should work to detect if the head is moving
and if a drive is available. But it will not detect if the motor works
or not, which could happen on a semi damaged drive (but you need an
inserted floppy for this anyway)
For me, the best would be for real HW :
Test a restore without spinup, then a seek to another track ; if it
works (TR00 on in 1st case, and off in the 2nd case), then the drive is
connected, and the head is moving correctly. You could have a damaged
drive/cable that always report TR00, so it's important to test the
signal is changing on track==0 and track!=0 (this is what normal tos
does, but with spinup).
If this test fails, mark the drive as disconnect.
I don't really see the point of using spinup during the test, because
spinup will fail anyway if there's no floppy in the drive or if the
drive is disconnected (well, that's my understanding of the doc, for now
we see Emutos expects different on real HW as seen in your test).
So, spinup doesn't really bring any extra useful information, just an
extra delay.
Nicolas