English Amiga Board


Go Back   English Amiga Board > Support > support.FS-UAE

 
 
Thread Tools
Old 24 January 2015, 12:43   #1
SnakeCoils
Registered User

 
Join Date: Mar 2014
Location: Italy
Posts: 163
FS-UAE 2.5.26dev: Glitches with Amiga chipset screen if Accuracy >-1

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.

Last edited by FrodeSolheim; 24 January 2015 at 13:31.
SnakeCoils is offline  
Old 24 January 2015, 13:34   #2
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
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 is offline  
Old 24 January 2015, 17:17   #3
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
(I forgot to mention that the code is pushed to git, so you can try it right away if you want to )
FrodeSolheim is offline  
Old 24 January 2015, 18:12   #4
SnakeCoils
Registered User

 
Join Date: Mar 2014
Location: Italy
Posts: 163
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

Last edited by SnakeCoils; 24 January 2015 at 18:30.
SnakeCoils is offline  
Old 24 January 2015, 23:01   #5
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
I have not been able to reproduce this on Linux x86-64 nor on Mac OS X x86...
FrodeSolheim is offline  
Old 25 January 2015, 10:14   #6
SnakeCoils
Registered User

 
Join Date: Mar 2014
Location: Italy
Posts: 163
It is still here with the 2.5.27dev release, this is the configuration for my WB31 environment:
Code:
[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.
SnakeCoils is offline  
Old 25 January 2015, 11:02   #7
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
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.
FrodeSolheim is offline  
Old 25 January 2015, 12:47   #8
jbl007
Registered User
 
Join Date: Mar 2013
Location: Leipzig/Germany
Posts: 442
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. :-)
jbl007 is offline  
Old 25 January 2015, 13:48   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 47
Posts: 25,367
Disable SPEEDUP define in custom.c(pp), if problem goes away (or changes), it is chipset emulation related.
Toni Wilen is online now  
Old 25 January 2015, 13:55   #10
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
Quote:
Originally Posted by Toni Wilen View Post
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
FrodeSolheim is offline  
Old 25 January 2015, 18:09   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 47
Posts: 25,367
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)
Toni Wilen is online now  
Old 25 January 2015, 20:29   #12
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
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)
FrodeSolheim is offline  
Old 25 January 2015, 21:16   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 47
Posts: 25,367
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?

Last edited by Toni Wilen; 25 January 2015 at 21:29.
Toni Wilen is online now  
Old 25 January 2015, 23:25   #14
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
Quote:
Originally Posted by Toni Wilen View Post
DIT: Quick test: remove "blitter_dangerous_bpl = 1;" in blitter emulator. Does the glitch go away?
No, it didn't have any noticeable effect.
FrodeSolheim is offline  
Old 26 January 2015, 18:00   #15
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 47
Posts: 25,367
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)

Code:
 				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;

Last edited by Toni Wilen; 30 January 2015 at 20:53.
Toni Wilen is online now  
Old 15 August 2015, 12:54   #16
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
Quote:
Originally Posted by Toni Wilen View Post
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:
Code:
             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):
Code:
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.

Quote:
Originally Posted by Toni Wilen View Post
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.

Quote:
Originally Posted by Toni Wilen View Post
EDIT: perhaps this fixes it (or not)...
No noticeable effect.
Attached Thumbnails
Click image for larger version

Name:	2013.png
Views:	274
Size:	7.9 KB
ID:	45061   Click image for larger version

Name:	2014.png
Views:	225
Size:	8.9 KB
ID:	45063   Click image for larger version

Name:	2015.png
Views:	259
Size:	7.7 KB
ID:	45065  
Attached Files
File Type: txt 2013.txt (11.9 KB, 115 views)
File Type: txt 2014.txt (24.5 KB, 135 views)
File Type: txt 2015.txt (12.6 KB, 126 views)

Last edited by FrodeSolheim; 15 August 2015 at 13:14.
FrodeSolheim is offline  
Old 15 August 2015, 13:23   #17
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 47
Posts: 25,367
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.
Toni Wilen is online now  
Old 15 August 2015, 13:29   #18
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
Quote:
Originally Posted by Toni Wilen View Post
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...
FrodeSolheim is offline  
Old 15 August 2015, 13:31   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 47
Posts: 25,367
Quote:
Originally Posted by FrodeSolheim View Post
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..

Last edited by Toni Wilen; 15 August 2015 at 13:39.
Toni Wilen is online now  
Old 15 August 2015, 21:03   #20
FrodeSolheim
FS-UAE Developer
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 41
Posts: 4,005
Quote:
Originally Posted by Toni Wilen View Post
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...
FrodeSolheim is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Screen glitches with mouse movement or key press Sparticle Coders. C/C++ 7 31 December 2014 10:11
Questions regarding 030 + CE accuracy vagrant support.WinUAE 2 22 March 2014 02:01
Amiga CD32 Sound Glitches Experiment T support.WinUAE 0 02 April 2009 23:13
Which is your all-time favourite Amiga chipset? Paul_s Nostalgia & memories 15 28 August 2007 05:47

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:00.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.11640 seconds with 13 queries