Re: [hatari-devel] Re: Hatari floppy drive detection with EmuTOS

[David Savinkoff <dsavnkff@xxxxxxxxx>]

Hi,

With the patch:
TOS 2.06 UK crashes with 4 bombs if both floppies are off,
and works properly otherwise. (I think Hatari needs fixing)

EmuTOS can only detect Drive b, or no drives properly. Drive A
is never detected.

The patch attached is the same one Nicolas added to the previous
email's text.


----- Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:
> Le 14/01/2014 22:21, Roger Burrows a écrit :
> > On 29 Nov 2013 at 15:59, Nicolas Pomarède wrote:
> >>
> >> There was a small bug in Hatari when drive was not correctly disabled
> >> from the command line -but it was OK from the UI).
> >>
> >> With this fixed, I see that both drives' icons are shown with emutos
> >> when drives are off, but if you click on them, nothing happens, so
> >> emutos seems aware that the drive is indeed off and commands should not
> >> be sent in that case (which is different from normal TOS, whether this
> >> is a better behaviour or not is a matter of personnal preferences I guess)
> >>
> > I just did some testing on this issue, and found the following:
> >
> > 1. Hatari hacks the drivebits to show both A & B present if you have a GEMDOS
> > drive defined.  This may be what you are seeing here.  So all of the remaining
> > applies when the GEMDOS drive is NOT defined.
> >
> > 2. With the current Hatari snapshot, if drives A & B are configured, EmuTOS
> > only detects drive B.  If only drive A is configured, EmuTOS detects no drives;
> > if only drive B is configured, EmuTOS detects it.
> >
> 
> Yes, hatari currently patches tos memory to always enable both drives, 
> by setting ConnectedDriveMask to 3.
> 
> You can try these 2 patches to remove drives being forced on :
> 
> diff -r e7b82fba5832 src/stMemory.c
> --- a/src/stMemory.c    Tue Jan 14 01:40:27 2014 +0100
> +++ b/src/stMemory.c    Tue Jan 14 23:21:10 2014 +0100
> @@ -242,7 +242,7 @@
> 
>          /* Create connected drives mask: */
>          ConnectedDriveMask = STMemory_ReadLong(0x4c2);  // Get initial 
> drive mask (see what TOS thinks)
> -       ConnectedDriveMask |= 0x03;                     // Always use A: 
> and B:
> +//     ConnectedDriveMask |= 0x03;                     // Always use A: 
> and B:
>          if (GEMDOS_EMU_ON)
>          {
>                  for (i = 0; i < MAX_HARDDRIVES; i++)
> diff -r e7b82fba5832 src/tos.c
> --- a/src/tos.c Tue Jan 14 01:40:27 2014 +0100
> +++ b/src/tos.c Tue Jan 14 23:21:10 2014 +0100
> @@ -41,7 +41,7 @@
>   Uint32 TosAddress, TosSize;             /* Address in ST memory and 
> size of TOS image */
>   bool bTosImageLoaded = false;           /* Successfully loaded a TOS 
> image? */
>   bool bRamTosImage;                      /* true if we loaded a RAM TOS 
> image */
> -unsigned int ConnectedDriveMask = 0x03; /* Bit mask of connected 
> drives, eg 0x7 is A,B,C */
> +unsigned int ConnectedDriveMask = 0x00; /* Bit mask of connected 
> drives, eg 0x7 is A,B,C */
>   int nNumDrives = 2;                     /* Number of drives, default 
> is 2 for A: and B: - Strictly, this is the highest mapped drive letter, 
> in-between drives may not be allocated */
> 
> 
> Maybe you will get closer results to what you expect on real HW. This 
> autoforcing of both drives should be removed later I think, and leave 
> TOS decides instead by doing the same tests as on real HW.
> 
> 
> 
> >>> I can post a summary here of how EmuTOS does drive detection, if that would
> >> be
> >>> helpful.  If there's an error in the logic, I'll certainly fix it.
> >>>
> >>
> >> Yes, that's would be interesting to post the summary; from the traces of
> >> emutos 0.91, the detection seems not correct to me.
> >>
> > Detection mechanism in EmuTOS:
> > For each of drive 0, 1:
> >   a) select drive via PSG
> >   b) send 0x03 to 1772 command/status reg
> >   c) wait up to 3 seconds for gpip bit 5 to clear
> >   d) if it doesn't clear, timeout, no device [this is what happens for drive A]
> >   e) if it does clear, read 1772 command/status register
> >   f) if the TR00 bit is set, the device exists.
> >
> > NOTE: If I change the code to test drive 1 before drive 0, then drive 1 is not
> > detected, drive 0 is.  So somehow, it's the first timeout that is not working
> > correctly.
> >
> >> One can test for a enabled drive by doing a restore with verify=off and
> >> then check in the status register if the TR00 bit is set. This bit will
> >> be set even if drive is empty, but it will remain clear if the
> >> corresponding drive is OFF, even when head is on track 0.
> >>
> > That's what EmuTOS does (see above).
> >
> >> This is what EmuTos does, by sending a restore command on each drive :
> >>
> >> fdc change drive/side io_porta_old=0x7 io_porta_new=0x5 side 0->0 drive
> >> 0->0 VBL=69 HBL=52
> >> fdc write 8606 ctrl=0x80 VBL=69 video_cyc=26724 308@52 pc=e06e4e
> >> fdc write 8604 data=0x3 VBL=69 video_cyc=26800 384@52 pc=e06e5e
> >> fdc write 8604 command=0x3 VBL=69 video_cyc=26800 384@52 pc=e06e5e
> >> fdc type I restore spinup=on verify=off steprate=3 drive=0 tr=0x0
> >> head_track=0x0 VBL=69 video_cyc=26800 384@52 pc=e06e5e
> >> fdc start motor with spinup VBL=69 video_cyc=27520 88@54 pc=e5e758
> >> fdc start motor : no disk/drive VBL=69 video_cyc=27520 88@54 pc=e5e758
> >>
> >> fdc change drive/side io_porta_old=0x5 io_porta_new=0x3 side 0->0 drive
> >> 0->1 VBL=249 HBL=24
> >> fdc write 8606 ctrl=0x80 VBL=249 video_cyc=12780 80@25 pc=e06e4e
> >> fdc write 8604 data=0x3 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> >> fdc write 8604 command=0x3 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> >> fdc write 8604 while fdc busy in prepare+spinup, current command=0x3
> >> replaced by command=0x3 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> >> fdc clear irq VBL=249 HBL=25
> >> fdc type I restore spinup=on verify=off steprate=3 drive=1 tr=0x0
> >> head_track=0x0 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> >> fdc start motor without spinup VBL=249 video_cyc=13576 368@26 pc=e5e758
> >> fdc start motor : no disk/drive VBL=249 video_cyc=13576 368@26 pc=e5e758
> >> fdc complete command VBL=249 video_cyc=13588 380@26 pc=e5e75a
> >>
> >> But as you can see from the warning in the traces, the restore on drive
> >> B is sent *before* the restore command completed on drive A. This is not
> >> correct, as the WD1772 doc says a new command will be ignored as long as
> >> the busy bit is set for the current one.
> >
> > The restore is sent to B before the restore completes on A because the restore
> > on A times out (after 3 seconds).  For testing, I increased the timeout to 9
> > seconds.  You can clearly see that the delay is really happening during EmuTOS
> > bootup, but it still times out looking for drive A.  So it seems that the GPIP
> > bit is not being cleared.
> >
> > The current EmuTOS code works on real hardware (just tested on my ST with two
> > drives).
> >
> 
> Do you mean that if you set timeout to 9 sec, then command 0x03 on drive 
> A stops after 3 sec and bit 5 of fffa01 is cleared (=command over) ?
> 
> On my STF, I had the feeling that command 0x03 (with spinup ON) will 
> never complete on an empty/disabled drive, because in that case the 
> WD1772 can't count index pulses, so spinup sequence will never stop. 
> Maybe my tests were wrong ? I would need to retest in that case.
> 
> That's not really related, but when you decide to timeout a command, I 
> think you should send a force interrupt command, not send the next 
> command immediatly ; Hatari might be wrong on that timeout case, but at 
> least with a force int command it would have worked.
> 
> 
> Nicolas
> 
> 
> 
> 

diff -ur hatari/src/stMemory.c hatari/src/stMemory.c
--- hatari/src/stMemory.c	2013-12-26 11:14:11.000000000 -0800
+++ hatari/src/stMemory.c	2014-01-14 14:50:59.000000000 -0800
@@ -242,7 +242,7 @@
 
 	/* Create connected drives mask: */
 	ConnectedDriveMask = STMemory_ReadLong(0x4c2);  // Get initial drive mask (see what TOS thinks)
-	ConnectedDriveMask |= 0x03;                     // Always use A: and B:
+//	ConnectedDriveMask |= 0x03;                     // Always use A: and B:
 	if (GEMDOS_EMU_ON)
 	{
 		for (i = 0; i < MAX_HARDDRIVES; i++)
diff -ur hatari/src/tos.c hatari/src/tos.c
--- hatari/src/tos.c	2013-12-26 11:14:11.000000000 -0800
+++ hatari/src/tos.c	2014-01-14 14:49:57.000000000 -0800
@@ -41,7 +41,7 @@
 Uint32 TosAddress, TosSize;             /* Address in ST memory and size of TOS image */
 bool bTosImageLoaded = false;           /* Successfully loaded a TOS image? */
 bool bRamTosImage;                      /* true if we loaded a RAM TOS image */
-unsigned int ConnectedDriveMask = 0x03; /* Bit mask of connected drives, eg 0x7 is A,B,C */
+unsigned int ConnectedDriveMask = 0x00; /* Bit mask of connected drives, eg 0x7 is A,B,C */
 int nNumDrives = 2;                     /* Number of drives, default is 2 for A: and B: - Strictly, this is the highest mapped drive letter, in-between drives may not be allocated */
 
 /* Possible TOS file extensions to scan for */