There are gray bars at the top and the bottom of the screen since 2410b3 (2410b2 was ok). The PAL screen size is 640x512 on an 800x600 PC screen.

Does http://www.winuae.net/files/b/winuae.zip fix it? (btw, when reporting screen glitches that change when resizing window or refreshing it, always test both d3d and directdraw, it makes debugging much faster if I can't duplicate it and this time I couldn't)

There are gray bars at the top and the bottom of the screen since 2410b3 (2410b2 was ok). The PAL screen size is 640x512 on an 800x600 PC screen.

That's probably related to use of a border-blanking utility. (Border-blanking requires ECS Denise or AGA.) I noticed probably the same issue, I run MultiCX which has a border-blanking feature in my startup-sequence.

My WB is PAL interlaced. The grey bars sometimes go away if I run a program which opens a non-laced screen then return to Workbench.

When the bars are present, if you drag the WB screen down, the revealed/empty parts of the screen are grey, not black as they should be with border-blanking enabled.

If the bars have gone away, they sometimes/occasionally return if you change your WB screenmode (e.g. from a non-laced to an interlaced mode). I only noticed the bars using PAL interlaced, not other modes like NTSC, Euro36 etc.

Edit: A possibly-related issue. PAL ECS machine, Workbench NTSC 640x400 interlaced, border blanked. I ran a program which opened a PAL high-res 640x260 screen (the Hex file editor). On putting the Hex screen to the back, there are a couple of scanlines of "garbage" (actually part of the Hex screen contents) below the NTSC WB screen area. No filter, no scaling, Direct3D (running under Wine). With DirectDraw instead, because the Amiga display isn't centred in the larger WinUAE window, the "garbage" area is much larger when I switch to the NTSC screen.

The garbage remaining below the NTSC area also happens with no ECS Denise (so no border-blanking), and moving a non-lace PAL screen behind a non-laced NTSC WB (so it isn't interlace-specific).

No, the issue with these gray bars disappeared for ever as soon as I used the screenmode preferences and just modified and saved the screenmode at least once. So, there was probably a minor change in the screenmode "database" since WinUAE 2410b3 ?!

Update: Unfortunately, this issue comes back when I quit WinUAE and then start it again. The same problem happens with DirectDraw and Direct3D. The method mentioned above cures this only as long as I reboot or "Restart" WinUAE from the GUI. Launching a new WinUAE from Windows brings it back.

No sorry, the WinUAE 2410bb4 didn't help and the same happens with Direct3D and DirectDraw (update above). I will try to investigate a little more now to get closer to the roots of the problem (switch off borderblank etc).

Edit: The "colour 0 bar at top when using border-blanking program" issue doesn't seem to be present with WinUAE 2.4.0. However, the "couple of lines of garbage at bottom of screen when switching from overscan PAL non-laced to NTSC laced screen" issue is in 2.4.0. So that at least isn't beta-related. Edit 2: The top bar issue looks to be first present in 2.4.1 beta 3 like PeterK mentioned.

Thanks a lot Toni,
it now works as it did before with WinUAE 2410. That's ok for me.

(Although there are still some bars on the right and the bottom when the screensize is reduced from SuperPlus (800x600) to PAL (640x512) for example. The bars will survive a normal reboot but can be removed with a "Restart" from the GUI. The bar on the right appears only with DirectDraw. This also happens with older WinUAE versions. Looks like the PC screen buffer is not cleared completely) But not so important to fix it. I can live with this "issue".

(Although there are still some bars on the right and the bottom when the screensize is reduced from SuperPlus (800x600) to PAL (640x512) for example. The bars will survive a normal reboot but can be removed with a "Restart" from the GUI. The bar on the right appears only with DirectDraw. This also happens with older WinUAE versions. Looks like the PC screen buffer is not cleared completely) But not so important to fix it. I can live with this "issue".

It's the same configuration as in my previous post with the WB31.adf again. I've only removed some unnecessary files to get some free space and then added the SuperPlus monitor driver from Ratte and the screenmode preferences editor.

Change the screenmode first to SuperPlus hires laced 800*600 and then back to PAL 640*512. In D3D only the bottom line will survive, but in DirectDraw the right border will also remain.

HMM, maybe it's because I'm using an old XT system. Don't care about it if you can't reproduce it on your system. It's not worth to waste too much time for this....

With the full ECS A2000/68030-like config I'm using, border blanking seems to be disabled/non-working with beta 5. The WB screen looks identical to if I boot with an ECS Agnus-only config (where border blanking is not possible with no ECS Denise).

With the full ECS A2000/68030-like config I'm using, border blanking seems to be disabled/non-working with beta 5. The WB screen looks identical to if I boot with an ECS Agnus-only config (where border blanking is not possible with no ECS Denise).

Border blanking did work (albeit with the top bar issue) with beta 4.

Do you really use same config because borderblank executable does not seem to do anything at all when running under ECS. (Copperlist does not have borderblank bit set)

I have MultiCX in my startup-sequence which has a border-blanking function. But I can also use BBlank to toggle border blanking, which does work as it should under 2.4.1 beta 4.

Which OS version are you testing with? The BBlank program at least requires V39+ graphics.library.

Oops, I did select 3.1 ROM but then later when I checked copperlists, I accidentally used 2.x ROM

Confirmed, happens if BPLCON3 is only modified outside of displayable area. (Which happens in ECS, AGA modifies BPLCON3 a lot during color changes). Border blank is quite different than anything else and does not really fit in emulation design very well.. Will be fixed again in next beta.