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

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



Le 10/12/2020 à 00:22, Roger Burrows a écrit :
Hi all,
On the EmuTOS list, Eero reported that the program Bomb Squad
(http://www.atarimania.com/game-atari-st-bomb-squad-falcon030_21766.html) runs
a lot more slowly under EmuTOS (latest version) than under TOS4.04 (both
running under Hatari 2.2.1).  After lengthy investigation, I believe that this
is caused by a Hatari problem.

Using the following synbols:
   H    Hatari
   TR   TOS 4.04
   ER   EmuTOS in ROM
   EP   EmuTOS as a PRG
   BS   Bomb Squad
   ->   "runs"
here's a summary of what I found:
   H->TR->BS        ok
   H->TR->EP->BS    ok
   H->ER->BS        slow
   H->ER->EP->BS    slow

I first thought that EmuTOS was failing to initialise something that TOS4
initialises, but I was unable to find anything.  However, I turned on MFP
tracing ("trace mfp_start") and noticed a difference in the entries for CD
handler 7 (the one used for Timer D).  For TOS 4.04, the entry says:
  ..... data=100 ctrl=7 timer_cyc=20000 .....
whereas for EmuTOS it says:
  ..... data=100 ctrl=1 timer_cyc=400 .....

After reading the comments in Hatari's mfp.c, I interpret this to mean that
when running EmuTOS, Hatari will have to evaluate the interrupt queue much more
often than it would on TOS 4.04, causing a major slowdown on my somewhat slow
system.  I made a simple change to Hatari (in mfp.c, commented out the line:
	bAppliedTimerDPatch = true;
in function MFP_TimerCDCtrl_WriteByte()), and re-ran the above tests and
tracing.  The "trace mfp_start" output under EmuTOS looked the same as under
TOS4.04, and there was no slowdown.

Of course, my change almost certainly is much too simplistic, but I believe
that the above test shows that this is a Hatari problem that ought to be fixed.

Hi

it seems you made your test with hatari 2.2 ? Because in hatari 2.3 there's no more "bAppliedTimerDPatch = true;" in MFP_TimerCDCtrl_WriteByte()

This was replaced by pMFP->PatchTimerD_Done ; can you test with Hatari 2.3 and the related sources ?

Also note that the patch is applied if "pc >= TosAddress && pc <= TosAddress + TosSize" ; maybe this condition is not true in case of emutos ? (but this shouldn't)

And indeed, evaluating the MFP's interrupt queue when using a timer with ctrl=1 will require more cpu for emulation.


Apart from finding why you get slowdown in your case, note that in the case of the TOS, this timer D is useless, because it's set to ctrl=1, timer enabled, but timer mask is 0 ; this means the interrupt for timer d will never happen, it's just running "for nothing". Do you use ctrlD=1 under emutos to mimick original TOS or is there another reason ? If timer D is not used, you'd better set it to ctrl=7 or even disable it completely (write 0 to timer D control register).


Nicolas



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