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

["Roger Burrows" <anodyne@xxxxxxxxxxxx>]

Hi Nicolas,
On 10 Dec 2020 at 10:26, Nicolas Pomarède wrote:
>
> 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 ?
>
I will do.

> 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)
>
It's true for EmuTOS in ROM (but not for EmuTOS as a program AFAICS).

> 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).
>
You're right, that's true on Falcon hardware, although of course it must be set
for serial port support on other systems.  It's there because TOS does it, and
I try to do hardware stuff the same as TOS to avoid introducing more
incompatibilities than already exist ;-).

Roger