Re: [hatari-devel] "Desktop Info..." freezes with VDI mode

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 10/12/19 11:58 AM, Nicolas Pomarède wrote:
> Le 12/10/2019 à 06:50, Thomas Huth a écrit :
> > Am Sat, 12 Oct 2019 02:28:10 +0300
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > > I experimented a bit with this and came up with the attached test
> > > patch.
> > >
> > > Would it make sense to enable that stuff unconditionally for VDI?
> > >
> > > I don't think it would slow it down noticeably and VDI mode isn't
> > > significantly faster than normal ST/STE video mode anyway.
> >
> > IIRC we had Timer-B enabled in VDI mode in the past, until someone
> > disabled it for performance reasons?

Good point, it's actually a *regression* from the last v2.2.1 release,
as "Desktop info..." works fine in VDI mode with TOS v1.04 - 1.62 there.


> > So I'd rather not revert that now.
> > I think a better way to fix this is to add a TOS patch to disable that
> > loop in the affected TOS versions. We even already got a TP_VDIRES
> > condition that perfectly matches this case.
>
> +1 for patching TOS instead of mfp.c or video.c
>
> For maintainabilty reason, the less tos/vdi specific code we put in 
> lower level part like mfp.c, the better it is. It's better if hte HW 
> component can remain as close as possible of the specifications.

Note: my proposal was *removing* code for special cases (from places
indicated in my patch).

However, it seems to interact badly with Thomas GEMDOS HD changes,
as with it, enabling VDI mode without enabling GEMDOS HD mode crashes.


> I'm always concerned when I want to improve low level emulation of some 
> parts and encounter some cases for tos/vdi/others which need to be 
> merged back in the new code. It often leads to errors/regressions


	- Eero