WinUAE 4.9.2+ beta series

[GetBoinged!]

Originally Posted by Toni Wilen

Does it stop happening if you set NOBLITTER=YES in uaegfx.info? (I suspect b1 uaegfx updates that implement previously unsupported less common drawing operations are not fully correct)

The glitches are also present with the option.

[Toni Wilen]

Originally Posted by GetBoinged!

The glitches are also present with the option.

Strange (also I noticed RTG blitter was always disabled since b4.. winuae.7z updated).

Which AmigaOS version, Picasso96 version and what is that program that shows the corruption?

[GetBoinged!]

Originally Posted by Toni Wilen

Strange (also I noticed RTG blitter was always disabled since b4.. winuae.7z updated).

Which AmigaOS version, Picasso96 version and what is that program that shows the corruption?

Solution found!

Responsible for the image artifacts is the switched on option of the visual effects in AmigaOS 4.1.
To be found under SYS:Prefs/GUI/Effects.

The functions of Picasso96 are included in the graphics.library of AmigaOS 4.1. So there is no Picasso96 under OS4.1 anymore, so to speak.

You can see the image artifacts by opening the SYS:LIBS folder, for example, and then moving the Intuition GUI bar to the right.

However (I still need to test this extensively), switching to optimize on: -> video memory usage helps.
Also to be found in the GUI adjuster under Effects.

** translated from DeepL **

[enigma776]

Originally Posted by GetBoinged!

Solution found!

Responsible for the image artifacts is the switched on option of the visual effects in AmigaOS 4.1.
To be found under SYS:Prefs/GUI/Effects.

The functions of Picasso96 are included in the graphics.library of AmigaOS 4.1. So there is no Picasso96 under OS4.1 anymore, so to speak.

You can see the image artifacts by opening the SYS:LIBS folder, for example, and then moving the Intuition GUI bar to the right.

However (I still need to test this extensively), switching to optimize on: -> video memory usage helps.
Also to be found in the GUI adjuster under Effects.

** translated from DeepL **

I have those effects working with a Voodoo 3 as the RTG card without corruption on Beta6 but holy hell does it bring everything to a grinding stop. Introduces a lot of slow down.

[Toni Wilen]

Emulating GPU per pixel effects using CPU is usually painfully slow.

Voodoo 3 emulation is not by me (only exception is missing big-endian parts). As usual: I don't want to know how 3D hardware works in low level. It is someone else's problem.

(btw, always test with previous official version before posting in this thread)

[Ponki1986]

Originally Posted by Toni Wilen

Sysinfo is useless test (JIT speed won't change without host CPU/memory speed upgrades...

I made speed measurements using SortBench. I hope this program is more reliable than SysInfo.

SORTBENCH 1.1 (Gunnar von Boehn)
Its a CPU benchmark that stresses CPU, DCache and branch prediction.
-------------------------------------------------------------

WinUAE x86 4.9.9 Beta 7 27.11.2022
1 K Element : 231.20 MB/sec
2 K Element : 231.39 MB/sec
4 K Element : 231.20 MB/sec
8 K Element : 230.55 MB/sec
16 K Element : 230.92 MB/sec
32 K Element : 230.61 MB/sec


WinUAE x86 4.9.9 Beta 7 26.11.2022
1 K Element : 231.72 MB/sec
2 K Element : 231.98 MB/sec
4 K Element : 231.90 MB/sec
8 K Element : 231.98 MB/sec
16 K Element : 231.85 MB/sec
32 K Element : 231.84 MB/sec


WinUAE x86 4.9.9 Beta 6 19.11.2022
1 K Element : 230.90 MB/sec
2 K Element : 231.35 MB/sec
4 K Element : 231.32 MB/sec
8 K Element : 231.24 MB/sec
16 K Element : 231.22 MB/sec
32 K Element : 230.78 MB/sec


WinUAE x86 4.9.9 Beta 5 06.11.2022
1 K Element : 261.18 MB/sec
2 K Element : 261.43 MB/sec
4 K Element : 260.99 MB/sec
8 K Element : 261.07 MB/sec
16 K Element : 261.05 MB/sec
32 K Element : 260.60 MB/sec


WinUAE x86 4.9.1 02.02.2022
1 K Element : 258.17 MB/sec
2 K Element : 258.36 MB/sec
4 K Element : 257.99 MB/sec
8 K Element : 257.93 MB/sec
16 K Element : 257.64 MB/sec
32 K Element : 257.59 MB/sec


WinUAE x86 4.9.0 06.12.2021
1 K Element : 259.41 MB/sec
2 K Element : 259.56 MB/sec
4 K Element : 259.56 MB/sec
8 K Element : 259.51 MB/sec
16 K Element : 259.53 MB/sec
32 K Element : 259.23 MB/sec

WinUAE x86 4.4.0 01.07.2020
1 K Element : 259.72 MB/sec
2 K Element : 260.01 MB/sec
4 K Element : 259.69 MB/sec
8 K Element : 259.05 MB/sec
16 K Element : 259.40 MB/sec
32 K Element : 259.28 MB/sec

WinUAE x86 4.3.0 19.12.2019
1 K Element : 259.89 MB/sec
2 K Element : 261.48 MB/sec
4 K Element : 261.19 MB/sec
8 K Element : 261.25 MB/sec
16 K Element : 261.10 MB/sec
32 K Element : 260.90 MB/sec

WinUAE x86 4.2.1 16.05.2019
1 K Element : 257.67 MB/sec
2 K Element : 258.17 MB/sec
4 K Element : 257.99 MB/sec
8 K Element : 257.55 MB/sec
16 K Element : 256.69 MB/sec
32 K Element : 256.75 MB/sec

WinUAE x86 4.2.0 08.04.2019
1 K Element : 260.34 MB/sec
2 K Element : 260.59 MB/sec
4 K Element : 260.17 MB/sec
8 K Element : 260.12 MB/sec
16 K Element : 260.06 MB/sec
32 K Element : 259.87 MB/sec


WinUAE x86 4.1.0 05.12.2018
1 K Element : 258.87 MB/sec
2 K Element : 258.80 MB/sec
4 K Element : 258.76 MB/sec
8 K Element : 258.56 MB/sec
16 K Element : 258.37 MB/sec
32 K Element : 258.19 MB/sec

[Toni Wilen]

https://download.abime.net/winuae/fi...nuae_4990b8.7z
https://download.abime.net/winuae/fi...ae64_4990b8.7z

Beta 8:

- RTG to chipset mode (non-interlaced) switch didn't enable native mode filter (b7)
- If CIA-A TOD counting was PSU tick based, ticks that were delayed until next scan line (due to CIA internal TOD counting delays) were lost. (b1)
- Added GVP A1208 Z2 RAM + SCSI board. It is basically GVP Series II Z2 SCSI controller + RAM expansion in different form. Uses usual GVP Series 2 SCSI ROMs. If A1208 is emulated and Z2 RAM is enabled, Z2 RAM gets GVP A1208 Z2 RAM autoconfig data. A1208 GVP internal device ID is 0x97.
- JIT mode interrupt handling restored, JIT needs "different" interrupt handling than non-JIT modes for best performance. (b5)
- uaegfx blitter emulation was accidentally disabled since b4.
- uaegfx b1 update had wrong operator in masked 8-bit DST=SRC blitter function (Turbotext scrolling in 8-bit) (b1)
- uaegfx non-basic blitter functions (for example mask set or not commomly used) didn't handle overlapping source and destination correctly. (Turbotext scrolling in 8-bit mode)
- gfx_left_windowed and gfx_top_windowed config file entries replaced with gfx_x_windowed and gfx_y_windowed. Reason was swapped coordinates but to keep backwards compatibility, new config entries have been added instead of fixing it by swapping them. Old config entries still work.
- A4000 Quickstart mode set PSU tick CIA-A TOD timing but A4000 does not have PSU tick hardware.
- 68020 cycle-exact timing adjustment (Lionheart whdload slave v2.3)
- Increased A1200 68020 approximate speed slightly. (Many AGA demos had slowdowns). CE mode is not changed.
- Rare SupraDrive 2000DMA boot ROM was finally dumped. Support added.
- Debugger memwatch command parsing changed. Some parameters got skipped. Value match is now V<value>.
- Debugger string to integer parser error condition support added. Potentially dangerous commands are now aborted if expected address can't be parsed (like 'g <typo in hex address that does not parse>'), previously failed string to integer conversion returned zero value.

This version should restore performance (CPU and uaegfx) back to 4.9.1 levels.

If there is no major issues left, official should get released in next 2 weeks. Plan that rarely works but maybe this time..

[Mclane]

Thanks Toni, I can only imagine how nice it will be to see a final of this particular cycle of the emulator.

Your work and time is always appreciated..

[PeterK]

beta8 with Jit is better now than 4.9.2 b1, non-Jit has the best results now Thanks!

        020/noJit 020/Jit  040/60  020/PAL

4.4.0     2.88     0.511    0.504   1.638
4.9.0     2.96     0.545    0.540   2.182  Jit/RTG 107%, PAL 133%
4.9.1     2.88     0.543    0.541   2.24
4.9.2 b1  3.00     0.593    0.587   2.24   Jit/RTG 116%, PAL 137%
4.9.9 b4  2.756    0.593    0.575   freeze                                      noJit 96%
4.9.9 b5  2.714    0.774    0.875   2.628  Jit/RTG 151%, PAL 160%, 040/60 174%, noJit 94%
4.9.9 b6  2.69     0.772    0.873   2.663                                       noJit 93%
4.9.9 b7  2.732    0.790    0.88    2.639  Jit/RTG 155%, PAL 161%, 040/60 175%
4.9.9 7z  3.056    0.605    0.603   2.76
4.9.9 b8  2.626    0.584    0.581   2.21   Jit/RTG 114%, PAL 135%, 040/60 115%, noJit 91%

[rutra80]

Useless info, but I once got WinUAE hang with RectFill() in P96Speed.
JIT, AmigaOS 3.2.1, uaegfx, 2560x1440x32
Couldn't reproduce once more...

[Ponki1986]

After enabling a PNG image as Overlay, the image is black in Direct3D 9 mode. Native modes display correctly without Overlay. In Direct3D 11 mode everything is OK.SortBench shows similar performance to Beta6, SysInfo gives a score of 430 MIPS.

You can see a big increase in performance while using Wazp3D. The GLExcess demo runs very fast compared to version 4.9.1

[paraj]

Hi Toni,
I think something got messed up with the JIT code in the latest beta.
For example with quickstart A4000/68030+best compatibility, disabling interrupts+dma and then changing color00 in a loop makes WinUAE hang (no crash dump).
Running a debug build it looks like random memory corruption with a crash from:

>	winuae.exe!is_color_changes(draw_info * di) Line 3676	C++
 	winuae.exe!pfield_draw_line(vidbuffer * vb, int lineno, int gfx_ypos, int follow_ypos) Line 3748	C++
 	winuae.exe!draw_frame2(vidbuffer * vbin, vidbuffer * vbout) Line 4528	C++
 	winuae.exe!finish_drawing_frame(bool drawlines) Line 4739	C++
 	winuae.exe!vsync_handle_redraw(int long_field, int lof_changed, unsigned short bplcon0p, unsigned short bplcon3p, bool drawlines) Line 4951	C++
 	winuae.exe!vsync_handler_render() Line 11083	C++
 	winuae.exe!vsync_display_render() Line 11149	C++
 	winuae.exe!hsync_handler() Line 13137	C++
 	winuae.exe!do_cycles_slow(int cycles_to_add) Line 296	C++
 	winuae.exe!do_nothing() Line 5322	C++
 	winuae.exe!m68k_run_jit() Line 5464	C++

-		di	winuae.exe!0x03f13548 {first_sprite_entry=0x000006f8 last_sprite_entry=0x00000000 first_color_change=...}	draw_info *
		first_sprite_entry	0x000006f8	int
		last_sprite_entry	0x00000000	int
		first_color_change	0x00bbbb88	int
		last_color_change	0x000006f8	int
		nr_color_changes	0x00000000	int
		nr_sprites	0x00bbbb99	int

Might be caused by commit f58dc0463f71283b86f255141cbbe7178fadb5d4 (reverting it seems to fix it, but only tested very lightly). To reproduce run the attached executable for ~10 seconds.

EDIT: can't attach the binary for some reason, but it's simply:

    lea.l       $00DFF000,a6
    move.w      #$7FFF,d0
    move.w      d0,$009A(a6)
    move.w      d0,$009C(a6)
    move.w      d0,$0096(a6)
.l: move.w      d0,$0180(a6)
    addq.w      #1,d0
    bra.b       .l

[Toni Wilen]

JIT + too much compatibility can get tricky because if JIT is too fast, it can overflow buffers doing impossible things like writing to custom registers thousands of times/scanline.

Attach your config, explaining the config is not enough to guarantee exactly matching config. (Possibly this config shouldn't even allow JIT)

[paraj]

20221203.uae is "repro" configuration, "20221203_actual.uae" is the one I actually use. 20221203-log.txt is log output.

Noticed it because I had done a whdload install and left the game disk inserted, rebooted and it hung on a flashing loading screen. Then reproduced it, wasn't trying to be difficult

EDIT: Rechecked, and isn't new in b8 like I thought, sorry. Seems to work in 4.9.1 but maybe just because that one was slower.

[jotd]

SMC detector is now super-slow. It used to log addresses and fly, but now it's crawling.

I know it's been fixed to take caches into account in a previous beta.

[freddy]

Toni, can you activate the string for translation ?

[Toni Wilen]

Originally Posted by jotd

SMC detector is now super-slow. It used to log addresses and fly, but now it's crawling.

I know it's been fixed to take caches into account in a previous beta.

"now" means what? Previous beta didn't have any SMC changes.

[Toni Wilen]

Originally Posted by Ponki1986

After enabling a PNG image as Overlay, the image is black in Direct3D 9 mode. Native modes display correctly without Overlay.

Can't duplicate. Probably need config and log.
EDIT: of course I managed to duplicate it after posting this..

winuae.7z fixed.

I made speed measurements using SortBench

I'll upload test version tomorrow.

You can see a big increase in performance while using Wazp3D. The GLExcess demo runs very fast compared to version 4.9.1

No interest whatsoever in these things, sorry.

[jotd]

Originally Posted by Toni Wilen

"now" means what? Previous beta didn't have any SMC changes.

I remember you fixing issues with code wrongly detected as SMC even when caches were flushed. I don't know exactly in which version it was but it's pretty recent.

[jotd]

Paraj tested it too and here's his conclusions

Regarding SMC detection being slow in WinUAE. I tried it on the slave, and it is crazy slow if you have Z3 fast mem enabled (all the cache flushes are killing emulator performance), and maybe there's something about 040+. It's fine with 030+8MB Z2 though.