FS-UAE 2.5.26dev: Glitches with Amiga chipset screen if Accuracy >-1

[SnakeCoils]

Lately I have discovered that if I set the accuracy of FS-UAE greater than -1 (in the config file) the screens using the Amiga chipset resolutions are affected by graphical glitches when opening, closing, moving or resizing windows and even if the top-down menus from the Workbench bar are opened and released.
This issue does not occour if the screenmode is from an RTG graphic card so it seems related to how the Amiga chipset is emulated.
This is funny because it reminds me a typical problem with the overheathing of graphic chips on real Amigas where a defective Lisa chip could lead to horizontal flickering stripes near the menus or windows edges so from this point of view the accuracy of FS-UAE matches the real hardware! :-D
This issue can be easily reproduced setting in the config file the accuracy to 0 or 1 on a AGA chipset amiga with a Workbench 3.1 (but it happens also on 3.9).
The last strange thing is that it happens only on the intel version (running on a my MacPro with Xeon 3.46 Ghz running OSX 10.9.5) and not the PPC OSX version (running on a MDD dual G4 1.5 Ghz running OSX 10.5.8).
Both builds have been compiled from the same 2.5.26dev source but I also have tried the official OSX intel build from the download page with the same results. I have to verify if this issue occour also on OCS/ECS emulated chipset.

[FrodeSolheim]

It's possible the problem is caused by some changes in the WinUAE beta versions. I noticed a flickering issue in "The Blues Brothers", which is gone now that I have merged the latest WinUAE beta code. So wait until 2.5.27dev and see if the problem still remains then

[FrodeSolheim]

(I forgot to mention that the code is pushed to git, so you can try it right away if you want to )

[SnakeCoils]

Just finished to compile the latest git archive on MacPro side: the issue is still here Frode, the glitches on workbench graphics (menus and widows) are present as the previous 2.5.26dev release. Same behaviour: all OK with accuracy = -1, not OK with accuracy = 0 or 1 :-(

Edit: as in the initial post I confirm that the also the PPC build of this latest git update is still immune from this issue

[FrodeSolheim]

I have not been able to reproduce this on Linux x86-64 nor on Mac OS X x86...

[SnakeCoils]

It is still here with the 2.5.27dev release, this is the configuration for my WB31 environment:

[config]
amiga_model = A4000/040
uae_a3000mem_size = 16
accuracy = 1
floppy_drive_volume = 0
video_sync = off
fullscreen = 1
viewport = * * * * => 0 0 752 574
hard_drive_0 = A4000_HD/

The appearance of this issue is like some spurious short horizontal lines that quickly appear when the Workbench graphics is moving. To see them is sufficient to drag a window around and then release it: when the window content is redrawn the glitches come out for an instant and then disappear.

[FrodeSolheim]

I can confirm that I too see the spurious glitches when the emulated CPU is running in fastest possible mode (A4000) with the default accuracy level.

One explanation for not seeing the glitches on your PPC machine is that the machine is slower, and thus the emulated CPU is running slower too...

The problem goes away when immediate blitter is enabled (uae_immediate_blits = true, uae_waiting_blits = false) - this happens when you set accuracy = -1.

It is most likely not an FS-UAE-specific problem (confirming with WinUAE would be nice...). Actually fixing this issue probably requires someone with deeper knowledge about Amiga internals.

[jbl007]

I have those glitches with the A1200 model as well, but not using cycle exact emulation (only with accuracy=0 or -1).
In WinUAE it does not happen, but I can only test with wine...

To work around this issue use Prefs/Overscan and move your screen position to something else than the default.
Default is (72,15) in WB3.1. For example (73,15) will do it.
Weired, but it works. :-)

[Toni Wilen]

Disable SPEEDUP define in custom.c(pp), if problem goes away (or changes), it is chipset emulation related.

[FrodeSolheim]

Originally Posted by Toni Wilen

Disable SPEEDUP define in custom.c(pp), if problem goes away (or changes), it is chipset emulation related.

You are right, I cannot reproduce the problem with SPEEDUP disabled

[Toni Wilen]

Does it happen with standard WB 3.1 disk? (non-modified: prefs/env-archive/sys must not have screenmode.prefs or overscan.prefs). If not, find screenmode/overscan combination that causes the problem and attach both .prefs files.

(assuming 3100b6 custom.cpp updates are fully merged)

[FrodeSolheim]

Yes, the problem occurs with:
* a standard/unmodified WB 3.1 disk (Workbench v3.1 rev 40.42 (1994)(Commodore)(M10)(Disk 2 of 6)(Workbench)[!].adf)
* KS ROM v3.0 (A1200) rev 39.106 (512k)
* and what corresponds to a A1200 quickstart, but with cycle-exact disabled

After testing more, the glitches appear (with the A1200 quickstart) with both immediate and waiting blits, but the glitches are more frequent with waiting blits.

I tried to reproduce using WinUAE 3100b6 / Wine, but I haven't been successful (I would have expected to be able to see the glitches there as well, at least with the A1200 model and approximate speed).

Custom.cpp looks correctly merged, so provided there's not any other changes I have left out by accident, perhaps the glitches appear only in FS-UAE due to changes in how gfxvidinfo.drawbuffer is configured? (or something like that)

[Toni Wilen]

It is a bug if SPEEDUP change makes any visible difference.

If blitter config makes any difference, it probably is related to "blitter_dangerous_bpl" that causes bitplane emulation to alternate between bitplane and blitter, cycle by cycle (blitter may modify words that are about to be fetched by any following bitplane DMA cycle) instead of doing both in separate passes. But it should not happen unless cycle exact is enabled.

It still is a bug in "SPEEDUP" even if blitter mode is "wrong".

EDIT: Quick test: remove "blitter_dangerous_bpl = 1;" in blitter emulator. Does the glitch go away?

[FrodeSolheim]

Originally Posted by Toni Wilen

DIT: Quick test: remove "blitter_dangerous_bpl = 1;" in blitter emulator. Does the glitch go away?

No, it didn't have any noticeable effect.

[Toni Wilen]

Quick test:

add something like "if (count > 80) count = 80; between "if(count >= fetchstart)" and "count &= ~fetchstart_mask".

Does glitch go away or change?

More complex testing:

First check what is "normal" stoppos value in SPEEDUP code when using test workbench screen mode, it should be something like $c0-$d0. (update_fetch)

Next only log stoppos values that are not "normal", probably also good idea to add vpos >= 60 && vpos <= 250 test to ignore lines that may have copper activity.

When the glitch happen, does matching vertical lines have "nonstandard" stoppos values? If yes, also include plfstop, ddfstop_to_test and ddf2.

EDIT: perhaps this fixes it (or not)

 				ddfstop_matched = true;
 			}
 			if (pos <= HARD_DDF_STOP && stoppos > HARD_DDF_STOP) {
-				plf_state = plf_passed_stop_act;
+				if (plf_state < plf_wait)
+					plf_state = plf_passed_stop_act;
 			}
 			if (pos <= ddfstop_to_test && stoppos > ddf2) {
 				plf_state = plf_passed_stop2;

[FrodeSolheim]

Originally Posted by Toni Wilen

First check what is "normal" stoppos value in SPEEDUP code when using test workbench screen mode, it should be something like $c0-$d0. (update_fetch)

Next only log stoppos values that are not "normal", probably also good idea to add vpos >= 60 && vpos <= 250 test to ignore lines that may have copper activity.

When the glitch happen, does matching vertical lines have "nonstandard" stoppos values? If yes, also include plfstop, ddfstop_to_test and ddf2.

I have created frame buffer dumps showing the graphical corruption, and also logged the following:

             count &= ~fetchstart_mask;
             int stoppos = pos + count;
+            if (vpos >= 60 && vpos <= 250) {
+                fprintf(g_fs_frame_f, "0x%x (vpos: %d, plfstop 0x%x, ddfstop_to_test 0x%x, ddf2 0x%x)\n",
+                       stoppos, vpos, plfstop, ddfstop_to_test, ddf2);
+            }

Test case is plain A1200 configuration with cpu_cycle_exact = false, A1200 kickstart 3.1, unmodified Workbench 3.1 disk.

The flickering *always* occurs when the workbench screen is redrawn after moving a open drawer window for example. Three frame dumps are attached in png format (file name is just sequential frame number), which shows what happens when the mouse button is released, and the window is moved (just ignore that red and blue channels are swapped ), along with corresponding log files for the same frame.

Looking at 2014.txt (the frame with corruption), it seems that for every vpos the bug occurs (at less all the ones I checked), there are four lines in the log (while one or two lines per vpos is more normal according to the log):

0x50 (vpos: 67, plfstop 0xd4, ddfstop_to_test 0xd8, ddf2 0xd8)
0x60 (vpos: 67, plfstop 0xd4, ddfstop_to_test 0xd8, ddf2 0xd8)
0xa0 (vpos: 67, plfstop 0xd4, ddfstop_to_test 0xd8, ddf2 0xd8)
0xb0 (vpos: 67, plfstop 0xd4, ddfstop_to_test 0xd8, ddf2 0xd8)

I have also tested with earlier versions of FS-UAE, and found that the problem was introduced when updating the emulation code from WinUAE 2.7.0 to 2.7.1b4 (this was done in a single commit).

@toni Do you see anything obvious from the screens and/or stoppos logs?

I haven't been able to figure out yet why this only happens in FS-UAE and not in WinUAE, but I have compiled a (somewhat stripped) version of WinUAE 3.1.0 with MSVC now, so I can try debug both and look for discrepancies.

Originally Posted by Toni Wilen

add something like "if (count > 80) count = 80; between "if(count >= fetchstart)" and "count &= ~fetchstart_mask".

Does glitch go away or change?

No noticeable effect.

Originally Posted by Toni Wilen

EDIT: perhaps this fixes it (or not)...

No noticeable effect.

[Toni Wilen]

Screenshots confirm it is not display emulation related, at least not directly. Corruption would be completely different (horizontal shifting etc..).

It looks like blitter is doing something wrong or it was programmed incorrectly.

[FrodeSolheim]

Originally Posted by Toni Wilen

Screenshots confirm it is not display emulation related, at least not directly. Corruption would be completely different (horizontal shifting etc..).

It looks like blitter is doing something wrong or it was programmed incorrectly.

Hmm, it does not hurt for me to double-check if there's any blitter-related differences between FS-UAE and WinUAE. But it's also still the case that the problem disappears when SPEEDUP is not defined...

[Toni Wilen]

Originally Posted by FrodeSolheim

But it's also still the case that the problem disappears when SPEEDUP is not defined...

SPEEDUP changes too many things, it can easily cause all kinds of side-effects if something else is even slightly wrong.

EDIT: Perhaps it is caused by some accidental undefined C case..

[FrodeSolheim]

Originally Posted by Toni Wilen

EDIT: Perhaps it is caused by some accidental undefined C case..

I have been wondering about the same thing...

I have compiled without any optimizations, and also, on OS X I compile with Clang. In either case, the problem persists, both for x86 and x86-64. However, this does not rule out undefined behavior.

I might have to "backtrack" to last FS-UAE commit using WinUAE 2.7.0 emulation, and merge 2.7.1b1, b2, b3, b4 in succession, and see if I learn/find anything interesting...