WinUAE 4.9.1 beta series

[Toni Wilen]

Originally Posted by amilo3438

Seems the instability starts from winuae_4900b21 !!!

In winuae_4900b20 can not provoke the problem even with several hard resets! (LCtrl+LWin+LAlt+RWin keys)

Ps. Using quickstart A500 1.3 ECS 512+512 configuration.

It is normal that reset can make a difference. Power up startup is designed to be identical every time (if same version). Any kind of reset (or not having disk in drive and then manually inserting it after KS screen comes) will affect timing and can change behavior if program is timing sensitive. This is normal (and happens in real world except in real world every power up is basically "random")

EDIT: this polls vblank intreqr bit so there is also chance it is IPL timing related. As usual.. Not 4.9.1 requirement.

[pjhutch]

Some programs , like web browsers and so on, can use a lot of memory, I have a Amiga OS 4.1 setup with 128 MB of memory for Cyberstorm PPC board and find it restrictive. Any chance of increasing this in future versions - 256Mb or more?

[Toni Wilen]

Originally Posted by pjhutch

Some programs , like web browsers and so on, can use a lot of memory, I have a Amiga OS 4.1 setup with 128 MB of memory for Cyberstorm PPC board and find it restrictive. Any chance of increasing this in future versions - 256Mb or more?

Have you been hibernating last few years or something?

This is both CSPPC and OS4 limit. Since few years ago you can simply use Z3 Fast RAM when using latest OS 4.1 update.

Also, this has nothing to do with 4.9.0/1 betas. See first post.

[hexaae]

I'm still testing the strange (JIT related?) slowdown issue after long run since 4.9.0... but in the meanwhile I wanted to report for this 4.9.1b3 very strange blackscreen freezes on switching screen (RTG<>native issue?) after reboot or when starting/quitting native games. The whole emulator freezes and stays in a limbo with a black screen. F12 or RAMIGA+LAMIGA+CTRL don't work anymore and I have to kill WinUAE task.
It's rare and totally random but it NEVER happens with 4.4.0 doing the same wild things (I run many games, switch Multiview SCREEN<>WINDOW multiple times, open programs etc. in a loop one after another as a stability test...) and I've never seen this before.

Will try using native in-a-window if this still happens, as my default cfg is native res -> fullscreen and Workbench RTG (P96) -> fullscreen borderless.

[Toni Wilen]

Originally Posted by hexaae

The whole emulator freezes and stays in a limbo with a black screen. F12 or RAMIGA+LAMIGA+CTRL don't work anymore and I have to kill WinUAE task..

This is good because in this situation task manager -> winuae.exe -> create dump file should create useful dump file to debug this.

EDIT: use latest official beta (must be official beta) and create dump file when it hangs. Set memory and VRAM size smaller than normal to keep dump file size sane.

[jotd]

I still happen to crash WinUAE when encountering a nasty programming error in my amiga program.

I'd say it's faithful to the non-emulated behaviour when you fucked up the memory/I/O/expansion boards so bad that you have to cycle the power to make it run again.

thanks for the hard work on this superb tool.

[Toni Wilen]

Originally Posted by jotd

I still happen to crash WinUAE when encountering a nasty programming error in my amiga program.

I'd say it's faithful to the non-emulated behaviour when you fucked up the memory/I/O/expansion boards so bad that you have to cycle the power to make it run again.

thanks for the hard work on this superb tool.

It can crash in bad situations if more compatible is not ticked. It shouldn't but it isn't worth the performance loss when config is fast. (and JIT can always crash in bad situations)

[hexaae]

Originally Posted by Toni Wilen

This is good because in this situation task manager -> winuae.exe -> create dump file should create useful dump file to debug this.

EDIT: use latest official beta (must be official beta) and create dump file when it hangs. Set memory and VRAM size smaller than normal to keep dump file size sane.

Here we go with freeze dump: https://1drv.ms/u/s!ApMUGr0cuN39goZP...VHc-g?e=bTNHue
I've set 128MB RAM+128MB VRAM.
I've found a sort of reproducible procedure launching Bo Jackson Baseball from Workbench multiple times (run & quit in loop)... Consider I use fullscreen for native res when the game starts, and WB is using P96 Z3 gfx board emu...

[Toni Wilen]

Originally Posted by hexaae

Here we go with freeze dump: https://1drv.ms/u/s!ApMUGr0cuN39goZP...VHc-g?e=bTNHue
I've set 128MB RAM+128MB VRAM.
I've found a sort of reproducible procedure launching Bo Jackson Baseball from Workbench multiple times (run & quit in loop)... Consider I use fullscreen for native res when the game starts, and WB is using P96 Z3 gfx board emu...

Dump shows it being stuck in CPU halt loop (which might be JIT side-effect, it shouldn't hang). But CPU halt almost always means Amiga side corruption.

Keep log window open, did it show CPU halted: <reason> and/or did window border indicators show Hx?

[hexaae]

...
PFLUSH
Unhandled JIT exception! PC=00f83626
mmu_op F518 PC=60112B50
PFLUSH
mmu_op F518 PC=60112B9A
PFLUSH
Unhandled JIT exception! PC=00f83626
mmu_op F518 PC=60112B50
PFLUSH
mmu_op F518 PC=60112B9A
PFLUSH
Unhandled JIT exception! PC=00f83626
mmu_op F518 PC=60112B50
PFLUSH
mmu_op F518 PC=60112B9A
PFLUSH
Unhandled JIT exception! PC=00f83626
mmu_op F518 PC=60112B50
PFLUSH
mmu_op F518 PC=60112B9A
PFLUSH
Unhandled JIT exception! PC=00f83626
mmu_op F518 PC=60112B50
PFLUSH
mmu_op F518 PC=60112B9A
PFLUSH
....

and goes on with this loop.
EDIT: added new full logfile, running & quitting Bo Jackson Baseball multiple times 'till it started JIT exceptions on a blackscreen freeze (starting from WB RTG P96)...

[Toni Wilen]

46-172 [3926 000-000]: CreateTexture2D (screenshot tx) failed: 8007000e
46-173 [3926 000-000]: CreateTexture2D (screenshot rt) failed: 8007000e

Probably memory leak is the real case.

Do you get similar errors if you switch modes without JIT enabled?

EDIT: what if JIT + D3D9 mode?

EDIT2: does same happen if you simply switch continuously between native and RTG with END+F9?

EDIT3: I can see GPU memory leak when switching modes and checking GPU memory utilization with Task manager GPU performance tab. Lets see..

FINAL EDIT: Fixed. When HDR mode was added, extra buffer creation was put inside loop when it should have been outside of it..

[Toni Wilen]

https://download.abime.net/winuae/fi...nuae_4910b4.7z
https://download.abime.net/winuae/fi...ae64_4910b4.7z

Beta 4:

- uaegfx overlay wasn't synced with screen dragging. It still works strangely if screen with overlay is not in front screen because Picasso96 does not yet support overlay fully during screen dragging.
- Reset filter button didn't reset manual filter settings.
- Added IDE scsi.device disable option to misc panel list.
- if number of planes changed mid scanline, whole line was drawn using planecount that was active when line started. If plane count was increased mid scanline, line was still drawn using lower plane count. If plane count was lowered, output was correct. (vAmiga test)
- Fixed x86 bridgeboard (AT variants only) boot crash if optimized build. Not sure if it was compiler bug or something else but I found a way to work around it. I think this exact same bug has happened previously.
- A1000 left hblank ends 3 lores pixels later than other models.

Later 4.9.0 beta series introduced bugs:

- If VSYNC starts after vertical wraparound (can happen in programmed modes), lines after wraparound before VSYNC was not drawn.
- HCENTER (ECS Denise only) "blanking" didn't work.
- Left side didn't open far enough in extreme overscan mode.
- OCS Agnus + OCS Denise: last blanked line bug on top of screen was not visible if line also had bitplane enabled.
- Direct 3D 11 mode shader buffer leak fixed. Caused crash after few dozens or so display mode switches. (4.9.0)

[hexaae]

Toni for President!

[mark_k]

Originally Posted by Toni Wilen

- A1000 left hblank ends 3 lores pixels later than other models.

Is that specific to certain early Denise revisions? E.g. present with the old no-EHB one?

[Viceroy]

Originally Posted by hexaae

Toni for President!

I Agree, this man keeps so many people happy!

[hexaae]

b4
Marvin's Marvellous Adventure, disappeared left vertical border again...

[ross]

Originally Posted by hexaae

b4
Marvin's Marvellous Adventure, disappeared left vertical border again...

I can see it with Resolution:SuperHires/Subpixel enabled.
If it's expected to be a quarter pixel on real AGA machines then it's correct.
It's just a matter of choosing whether to also view it in Resolution:Hires mode or not..

EDIT: tested with previous WinUAE, the left border seems an half pixel and not a quarter
If confirmed in real machine then in fact there is something to fix

EDIT2: in theory I should remember which way is right as I also fixed some games with the same problem, but no

[hexaae]

Oh, I think I never switched Display > SuperHires since I use WinUAE Nice!
Mmmh, I actually like it 1/4 as it is now, more than how it was before half pixel (too large!), eh eh eh ;D

P.S.
Here is my list of games (WHDLoad or not) affected with left or right border and vertical line issues still unfixed :
T-Racer
Overkill AGA
Prime Mover
Brian The Lion AGA
Shadow of the Beast III

[Toni Wilen]

Originally Posted by hexaae

b4
Marvin's Marvellous Adventure, disappeared left vertical border again...

It changed in 4.9.0. It needs subpixel mode. (shres mode is only needed to see 1 shres pixel differences)

Originally Posted by mark_k

Is that specific to certain early Denise revisions? E.g. present with the old no-EHB one?

It is EHB model A1000. Don't know if non-EHB is different.

[hexaae]

Originally Posted by Toni Wilen

It changed in 4.9.0. It needs subpixel mode. (shres mode is only needed to see 1 shres pixel differences)

I have subpixel enabled, but I can see the vertical left border only if I use "uae-configuration gfx_resolution superhires". Wasn't it 1/2 pixel?