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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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;
 			}
 		}
 


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/