WinUAE 4.10.1 beta series

[Toni Wilen]

Quick bug fix release (Probably mid January 2023) before missing 5.0 features are implemented.

Post here only if bug is introduced in 4.10.0 or 4.10.1.

https://download.abime.net/winuae/fi...uae_41010b1.7z
https://download.abime.net/winuae/fi...e64_41010b1.7z

Beta 1:

- Fixed possible single scan line graphics corruption if BPLCON0 was changed when horizontal sync started (Caused by last minute 4.10.0 bug fix).
- Interlace config scaling mode was saved as RTG scaling mode which could write incorrect config entry or cause a crash.
- When saving config, check index values of array type config entries, preventing possible out of bounds memory access if entry is invalid (negative or too large) for some reason, like above bug. Config entry is internally index number, index is used to select config file entry value. If invalid value is detected, message is logged and config entry write is skipped.
- Removed useless "Scanlines" option under PAL filter extra settings.
- GDI mode RTG hardware cursor was not fully disabled when emulated Amiga was reset.
- GDI cursor leaved garbage on screen if hardware sprite coordinates were negative.
- Taking screenshot, DF0: is enabled but empty and CD drive is enabled but not empty: select CD image name.
- Disabled move left/right joystick autoswitching mode (was too easy to do it accidentally without noticing what happened). Only buttons are supported now. Improved popup description text of autoswitch option.
- Vblank interrupt trigger was 2 cycles too late. (Cracked The deep hang). This was supposed to be correct but probably some test results were misunderstood. Or something.
- Copper write to DMACON that disables copper DMA: copper stopped 1 cycle too early. (Following copper instruction's first instruction word is still fetched)
- DMACON write that switches blitter DMA on or off when blitter is running was not fully cycle-accurate. Now it is. (Blitter nasty was already correct)
- Yet another sprite DMA conflict found (Thanks ross again ) and emulated. If sprite DMA is switched on exactly 3 cycles before sprite's DMA slot, DMA decision is done and sprite pointer is increased but slot is not allocated, DMA transfer does not happen and RGA bus appears in idle state (0x01FE). If some other DMA channel allocates same slot, it conflicts and usual RGA bus AND and DMA pointer OR operations happens. Bitplane or blitter seems to be only channels that can conflict in this situation. CPU also can use this cycle safely. (Why do sprites have 2 different kinds of undocumented and weird conflicts?)
- Disk DSKSYNC interrupt behavior adjusted (not done any proper tests yet to fully confirm it), INTREQ DSKSYN bit only seems to get set when internal DSKBYTR WORDEQUAL bit changes from 0 to 1 because without drives selected (internal buffer value is static) and causing DSKSYNC match: DSKBYTR WORDEQUAL is one but interrupt only happens once (for example setting DSKSYNC to non-matching value and back to matching will generate single interrupt. Only writing same matching value again won't generate new interrupt). This behavior was never accurate and some versions had different hacks. Hopefully this is more correct behavior. (Retrovision / Insane and others I don't remember)
- Some timing operations still used old 32-bit wrap around timer checks that can return bad results with new 64-bit internal cycle counter. Affected standard vsync mode.
- Clear Harddrives panel list when loading hardware-only config.
- Platform specific config entries ("win32.???") were host only. Separated to host and hardware config entries. Moved win32.rtg_vblank to hardware config (Also this shouldn't be in platform specific anymore..)

[vulture]

Hey Toni!

Mouse pointer in workbench is trashed in 4.10.1 while in 4.10 is fine (as it also is on my real A1200 setup)

screenshots:

4.10.1


4.10

[rutra80]

Can't reproduce on my 3.1, 3.X, nor 3.2.1 - are you using some patches?

[Toni Wilen]

Does it only happen if mode is overscan? (Or if screen is moved very left?)

EDIT: yes, it is off by one when bitplane DMA steals sprite DMA slots due to sprite changes to emulate new conflict situation. Will be fixed tomorrow.

[vulture]

@Toni

Yes on both counts. If I remove the overscan and screen is centered, the pointer is back to normal. If I move it to the left (even w/o overscan) it gets trashed again.

@rutra80

Yes, many patches in fact

EDIT:

Ah! Thx for the quick solution Toni!

[Toni Wilen]

https://download.abime.net/winuae/fi...uae_41010b2.7z
https://download.abime.net/winuae/fi...e64_41010b2.7z

Beta 2:

- Bitplane DMA stealing sprite DMA off by one fix (b1)
- Platform specific hardware specific config entries didn't parse correctly and were ignored (b1)
- B1 sprite/blitter conflict was unreliable (not accurate side-effects in some situations, probably no one really cares as usual..)
- DSKBYTR WORDSYNC bit was previously autocleared after short delay. Now it stays on as long as DSKSYNC matches. Was very old workaround for old and wrong WORDSYNC behavior. Load DSKBYTR only when valid data is available. Real HW does not seem to load DSKBYTR when only zeros are read. (Most likely DSKBYTR is not loaded if PLL is not locked?)

[tygre]

Hi Toni!

Is this the right place to report a crash with a combination of WinUAE and CubicIDE (and maybe some patches)?

I reported in the thread that I opened on CubicIDE here

Take care!

[Toni Wilen]

Only if you can confirm it only happening with 4.10+ (It does not look like it. Looks like the usual side-effect when JIT gets confused, for example too small stack and return address getting trashed)
EDIT: you might get more information if you run winuae with log window open (-log command line parameter). Assuming it can be duplicated easily.

[tygre]

Hi Toni!

Indeed, with 41010b2.7z it doesn't crash anymore but there's some corruption on the screen, please see the three images in attachment. Let me know if there's anything else that I could do?

Cheers!

[tygre]

Hi Toni again!

Another possible bug: I'm playing with AmiSSL, with a program that works well under 3.1 but crashes WinUAE under 3.2. Please see the screenshot: I think that my code is doing something wrong under 3.2, but maybe a Guru should appear rather than this "Arabuusimiehet.WinUAE" window

(Also using 41010b2.7z)

Best!

[Toni Wilen]

Originally Posted by tygre

Hi Toni!

Indeed, with 41010b2.7z it doesn't crash anymore but there's some corruption on the screen, please see the three images in attachment. Let me know if there's anything else that I could do?

Cheers!

Don't use any filters or scaling when attaching screenshots. Blurry screenshots are annoying.

Originally Posted by tygre

Hi Toni again!

Another possible bug: I'm playing with AmiSSL, with a program that works well under 3.1 but crashes WinUAE under 3.2. Please see the screenshot: I think that my code is doing something wrong under 3.2, but maybe a Guru should appear rather than this "Arabuusimiehet.WinUAE" window

(Also using 41010b2.7z)

Best!

JIT can crash unrecoverably. Check without JIT first.

[tygre]

Hi Toni!

So I just deactivated the JIT, changed nothing else, and I got the "same" crash, please see the screenshot below.

Let me know!

[Toni Wilen]

Originally Posted by tygre

Hi Toni!

So I just deactivated the JIT, changed nothing else, and I got the "same" crash, please see the screenshot below.

Let me know!

Enable log window and try again ("winuae.exe -log"). Does anything else appear before the register dump message? (Strange disassembly is a side-effect of disassembler not being fully initialized)
EDIT: tick also log illegal memory accesses in misc panel.

[tygre]

I tried with -log and -logflush but WinUAE doesn't write a log file: instead it opens a "console" window into which the log is printed, what am I doing wrong?

[Toni Wilen]

Originally Posted by tygre

I tried with -log and -logflush but WinUAE doesn't write a log file: instead it opens a "console" window into which the log is printed, what am I doing wrong?

-log = log window. It is better to check the log window than log file because that register dump might not be logged to a file. (debugger output is not logged)

[tygre]

Okay! Here is a log with MMU and FPU enabled (both "more compatible") and without JIT. Strangely, this time the Arabuusimiehet.WinUAE window didn't appear but WinUAE just showed a black screen. I hope that this helps?

[Toni Wilen]

Originally Posted by tygre

Okay! Here is a log with MMU and FPU enabled (both "more compatible") and without JIT. Strangely, this time the Arabuusimiehet.WinUAE window didn't appear but WinUAE just showed a black screen. I hope that this helps?

Why do you keep changing the config? Just switch off JIT and duplicate it and include full log.

This worked as designed, Amiga side did something very bad (double fault) so CPU was halted.

[tygre]

I didn't change the configuration, or did I?

What would be this bad thing that the Amiga side did? (It seems related to AmiSSL...)

[Toni Wilen]

Originally Posted by tygre

So I just deactivated the JIT, changed nothing else, and I got the "same" crash, please see the screenshot below.

Originally Posted by tygre

Okay! Here is a log with MMU and FPU enabled (both "more compatible") and without JIT

Originally Posted by tygre

I didn't change the configuration, or did I?

First you said you only deactivated JIT, then suddenly you mention MMU. Deactivating JIT won't enable MMU automatically.

What would be this bad thing that the Amiga side did? (It seems related to AmiSSL...)

No idea. Incompatible library, out of bounds memory access, stack overflow. Lots of reasons. (Which also is not my problem)

I am more interested about that message because I have never managed to duplicate it and I can't find anything which would cause it (Unless you already used UAE debugger in same session)

I'd have expected "ExceptionFilter Trap.." or "Your Amiga program just did something terribly stupid.." message when log window is open.

(MMU emulation can hide these, especially if MMU is active)

but there's some corruption on the screen, please see the three images in attachment

Assuming you mean that short line in arrow image? (Always include some details, especially when images are blurry..)

Does it happen in 4.9.1 (or older)? (4.10 added more Picasso96 blitter emulation functions)
Does it still happen if you set NOBLITTER=yes (uaegfx.info settings)

[tygre]

Originally Posted by Toni Wilen

First you said you only deactivated JIT, then suddenly you mention MMU. Deactivating JIT won't enable MMU automatically.

Yes, you're right, sorry for the confusion!

Originally Posted by Toni Wilen

No idea. Incompatible library, out of bounds memory access, stack overflow. Lots of reasons. (Which also is not my problem)

I am more interested about that message because I have never managed to duplicate it and I can't find anything which would cause it (Unless you already used UAE debugger in same session)

I'd have expected "ExceptionFilter Trap.." or "Your Amiga program just did something terribly stupid.." message when log window is open.

(MMU emulation can hide these, especially if MMU is active)

And now I cannot reproduce it either
However, WinUAE freezes instead of inviting the Guru.
I attach a new log. Let me know if that helps?