mouse artifacts with bitplane.sys driver

[mfro0]

There are (apparently random) mouse artifacts when moving AES windows or browsing through menus

[vinriviere]

I suspect a race condition between the mouse interrupt and main VDI code. But absolutely no clue.

[th-otto]

I can reproduce that too, using Hatari, and the bitplane driver with 16 colors. I'm not entire sure whether that is only mouse related, as there sometimes seem to be some other random garbage:

Also it seems to be an old bug, happens both with the old and new versions.

[th-otto]

There is denfinitely something strange going on there. Attached is an animated gif, where i switch in gemini from the console to a file window, and back. Look at the prompt in the console window...

[vinriviere]

Idea of animated GIF for bug reports is really brilliant 👍

[mfro0]

these artifacts are also observeable on the FireBee, but a lot less prominent. You really need to make an effort to create them (just browsing through a menu is definitely not enough most of the time).

fVDI appears to disable interrupts when calling functions with "special stack". https://github.com/freemint/fvdi/blob/cfb8c689a943d7977fd5f86335b5003c17a4dbf0/fvdi/include/macros.gnu#L87 Depending on how long these functions run, it might well be the cause for all kinds of strangeness.

(and yes, animated gifs are nice ;) )

Hmmm, no. This macro does not seem to be used anywhere.

[vinriviere]

My Amiga drivers (UAEGFX and SAGA) based on the 16-bit driver also exhibit mouse artifacts, occasionally. I suspect a race condition between the mouse interrupt and the main code (to be proved).

[th-otto]

The saga driver has gotten a new flag for accelerated mouse drawing. That should use the hardware mouse capabilities of the card, maybe that works better.

[th-otto]

Some findings so far:

• there is a flag "oldmouse", both in fvdi.sys and for the driver. Setting this would have the effect that the mouse routines from the "old VDI" (ie TOS) are called. Does that make sense? I can't imagine any situation where that should be useful, or even work (the old VDI may have its own idea where the mouse is located)

• when using an "accelerated" mouse drawing function (which is the default case for the bitplane driver), the functions v_hide_c() and v_show_c() check the wk->mouse.type member, which was set in init.c. However, vq_mouse only tests the global stand_alone flag. I could imagine that this causes trouble with AES.

The other pixel garbage from text output seem to be unrelated to this, and maybe cause by other bugs in the text drawing functions.

[vinriviere]

Note that, when working on my drivers derived from Falcon 16-bit, I noticed that there was no mouse support for 16-bit modes. I guess that oldmouse was useful in that case (on Falcon). In other words, use fVDI implementation on Falcon for anything except the mouse. As a result, I needed to invent new fVDI mouse routines for 16-bit modes, when the underlying TOS has no support for those modes.

[th-otto]

I needed to invent new fVDI mouse routines for 16-bit modes, when the underlying TOS has no >support for those modes.

But these were only used for the uaegfx/saga drivers. In the meantime however, similar routines have also been implemented for the generic 16_bit driver. So if i'm not wrong, all supported drivers have now "accelerated" versions. That means, you still have the choice to turn them off for a particular driver using the accelerated option, which should have the same effect and call the TOS functions.

[vinriviere]

There are actually 3 possible implementations for mouse :

• use the underlying TOS routines
• implement mouse routines inside fVDI using bitmap blits
• implement mouse routines inside fVDI using some hardware acceleration (i.e. hardware sprite)

[th-otto]

For hardware sprites, there is already an additional flag hwmouse for the saga driver (the only one that supports it currently).

[th-otto]

Some more findings (maybe not related to the bugs, but still strange):

• in the drivers init() function, graphics_mode is examined. However, several drivers (aranym, uaegfx and saga at least) set that to the actual mode being specified by the driver options. That is done in initialize(), which is called later.
• most drivers have a norestore option, that is nowhere documented. I haven't fully understand yet what it does, but it has something to do with mouse redrawing
• in EmuTOS (and also in TOS i assume), mouse redrawing is protected by mouse_flag. This is definitely needed to avoid for example saving a screen background in v_show_c() that is just being updated by the timer interrupt. No such thing seems to be done by fVDI. Maybe it is expecting the driver to take care of that?

[th-otto]

I can usually rather quickly produce some artifacts with Hatari, when moving the mouse from one menu title to another: Strangely, i cannot reproduce the same using StonX.

[mfro0]

I don't think that's specific to Hatari, I can (although a lot more difficult) reproduce the problem on the FireBee as well.

[th-otto]

While further looking at the code, i'm currently in the mood of rewriting that whole stuff about mouse management. There are so many variables and states currently, that it is difficult to maintain. Amongst others, that are:

• booted. This variable is currently used to indicate that fVDI was booted from auto-folder, and has to be set manually in the config file. This is imho nonsense, or at least obsolete, since running fVDI from the desktop does not work at all.

• fakeboot. Related to above, forcing fVDI into believing it was run from auto-folder, even if it wasn't

• disabled. Intended to just test the boot code, but not loading any drivers. Just a debug feature, and does not seem to work.

• oldmouse (both as global variable, and also as setting for the driver) As already discussed, that variable is currently responsible of calling the previous mouse functions for v_hide_c() etc. Since all drivers now have their own mouse drawing functions, calling any previous functions should not be needed anymore, and i expect that actually to cause that trouble. Amongst others, the vbl-routine of the previous TOS (if already installed), is left alone, and might interfere with fVDI's own drawing.

• wk->mouse.type. Derived from oldmouse, once the driver is loaded.

There are some other srange things that need to investigated. Eg. when opening a (physical) workstation, VEX_CURV and VEX_TIMV are hooked, but VEX_MOTV and VEX_BUTV aren't, these are redirected to TOS instead.

[mfro0]

I'm not sure, but bitplane.sys mouse artifacts didn't happen anymore for me in recent tests?

@th-otto : did you change anything related to this, did they vanish "magically" or is it just my flaky testing?

[th-otto]

On Mittwoch, 6. Januar 2021 08:39:10 CET Markus wrote:

I'm not sure, but bitplane.sys mouse artifacts didn't happen anymore for me in recent tests?

@th-otto : did you change anything related to this, did they vanish "magically" or is it just my flaky testing?

Yes, i changed this to redraw the mouse during the VBL interrupt, instead using a custom timer, just like TOS and EmuTOS does. It now also honors the corresponding flags in the line-A variables. That whole thing made those artifacts disappear. The commit is https://github.com/freemint/fvdi/commit/ c36b7169d921f9607d6425b40ec59e3c1c24b2ee

[mfro0]

Ah, thank you, great! Then I didn't just dream it ;)

I'd suggest we could close this issue now?

[mfro0]

closed with c36b716