Re: [hatari-devel] Suspected problem iwith TimerD patch

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 12/11/20 3:51 AM, Roger Burrows wrote:
> On 11 Dec 2020 at 0:24, Eero Tamminen wrote:
> > * There's a command line option and GUI setting to
> >     enable/disable timer-D patching, one doesn't
> >     need to change Hatari code for that (by default
> >     Timer-D patching is disabled in Hatari)
> If you disable the old timerD patching via the GUI, neither Hatari nor EmuTOS
> have good performance.

Timer-D patching improves Hatari performance
because there's less emulated interrupts for
Hatari to process.

If I disable Timer-D patching, Hatari takes
15% more CPU during Bomb Squad game under EmuTOS.

(This is with DSP emulation disabled so that
Hatari CPU usage keeps in both cases <100%.)


> If you make my change, both have good performance.
> That was my point about the patch.  My change does NOT disable patching.

Ah, I see.

With your change, patching is done every time Timer-D is started, not 
just on first time:
https://git.tuxfamily.org/hatari/hatari.git/tree/src/mfp.c?id=v2.2.1#n2063

Attached is same patch for v2.3 (+ removal of
the old obsolete variable).

However, I don't see any noticeable change from it
either to Hatari or game perf under EmuTOS. Hatari
still takes about same amount of CPU, and game
still takes 8 VBLs to move objects, same as
earlier, with and without Timer-D patching.

(Whereas under TOS4 game does those moves in 2VBLs.)


> > * While Timer-D can have very noticeable *Hatari*
> >     performance impact, I don't see any noticeable
> >     impact on the emulated game, EmuTOS or TOS4
> >     performance.  They still have the same 4x
> >     performance difference, regardless of whether
> >     timer-D is patched or not.
> I did see a difference.  That's why I posted.

Problem here isn't Hatari CPU usage, like was
the case with DSP / STOP issue, but game performance with EmuTOS, as 
measured by the
emulated 680x0 clock, instead of the host clock.


> I will be following up on
> Nicholas's suggestion re testing on 2.3.  At some point (subject to shipping
> from China), I'll be receiving EPROMs so I can burn EmuTOS for the Falcon.  If
> the cause of the problem is still undetermined by then, I'll be testing Bomb
> Squad on real hardware with TOS & EmuTOS.  That should conclusively prove
> whether it's an EmuTOS issue or a Hatari issue.

Testing with EmuTOS PRG version shows that with
TOS4 in ROM the game has good perf, so testing
this on real HW really requires EmuTOS in ROM. :-/


	- Eero

diff --git a/src/mfp.c b/src/mfp.c
index 22216c11..3f8e0186 100644
--- a/src/mfp.c
+++ b/src/mfp.c
@@ -343,8 +343,6 @@ MFP_STRUCT		*pMFP_Main;
 MFP_STRUCT		*pMFP_TT;
 
 
-static bool bAppliedTimerDPatch;    /* true if the Timer-D patch has been applied */
-
 #define	PATCH_TIMER_TDDR_FAKE		0x64		/* TDDR value to slow down timer D */
 
 
@@ -458,9 +456,6 @@ void	MFP_Reset_All ( void )
 {
 	int	i;
 
-	/* Reset MFP internal variables */
-	bAppliedTimerDPatch = false;
-
 	for ( i=0 ; i<MFP_MAX_NB ; i++ )
 	{
 		MFP_Reset ( &(MFP_Array[ i ]) );
@@ -3050,7 +3045,7 @@ void	MFP_TimerCDCtrl_WriteByte(void)
 			if ( new_tcdcr & 0x07 )			/* apply patch only if timer D is being started */
 			{
 				new_tcdcr = IoMem[IoAccessCurrentAddress] = (IoMem[IoAccessCurrentAddress] & 0xf0) | 7;
-				pMFP->PatchTimerD_Done = 1;
+				pMFP->PatchTimerD_Done = 0;
 			}
 		}