Remove A2024 artifacts option

[mark_k]

WinUAE's remove interlace artifacts option got me thinking...

Would it be feasible to add a "remove A2024 artifacts" option for A2024 modes?

For those that aren't aware, the A2024 monitor allows 1024×800 or 1024×1024 4-level greyscale modes on any Amiga. The large display is refreshed in four or six panes, giving an effective overall update rate of 10Hz or 15Hz. So on an A2024 screen with a large CLI window (say), scrolling text in the window can have tearing artifacts due to the different panes being updated at different times.

With an option to remove artifacts the effective update rate could be increased to 50/60Hz, removing the tearing.

The idea would be like this (only for fields output by the Amiga which have valid A2024 control data):

• For each field, remember the bitplane pointers and control data (10Hz/15Hz, bit depth, which pane and pane type).
• Check the control data to see which pane is being updated.
• Compare the control data with that for the previous several fields. If this field is not the same type (10Hz/15Hz and depth) you can assume the front screen has probably changed. So don't try to remove artifacts in that case; only refresh the current pane.
• If the field is the same type as the previous field, you can remove artifacts. Do that by refreshing the entire A2024 display. The current field is obviously no problem. You would read the data for other panes using the previously-remembered bitplane pointers. (If you haven't remembered the bitplane pointers for a particular pane yet, just skip that pane.)

If/when you see a field with no A2024 control data, reset/invalidate the remembered bitplane pointers for each pane.

Maybe some optimisation could be done for the case where a pane's data is unchanged since the last field output (1/60th second ago). (That would require being able to check which parts of the Amiga bitplanes have been written since the last field.)

[Toni Wilen]

It would increase complexity of chipset emulation greatly. Sorry, answer is no.

A2024 emulation was only implemented because it is completely self-contained, core emulation does not know anything about A2024.

IMHO better option is to use existing chipset emulation and create high resolution programmed modes that are normally not possible when using real monitors and chipset using monitor "driver" editor programs. (Increase chipset horizontal frequency or something like that to allow high resolution and high vertical frequency. Perhaps it could work semi-automatically)

[thomas]

For those that aren't aware, the A2024 monitor allows 1024×800 or 1024×1024 4-level greyscale modes on any Amiga. The large display is refreshed in four or six panes, giving an effective overall update rate of 10Hz or 15Hz.

There is already HighGfx monitor driver which allows 1024x768 or 1280x720 at 50 Hz in colour, so what is the point in using A2024?

[pandy71]

Hmmm how data for A2024 are stored in memory? As one large screen or as 4/6 small screens?

[mark_k]

A2024 screens are stored in memory as one large screen. The A2024 monitor driver handles outputting a different part for each Amiga output field. It has some intelligence; if you're moving the mouse pointer, it will output the pane containing the pointer more frequently, so mouse movement is smoother.