Picasso IV Z3 (cgx4) has the same fluctuating framerate but no hpos crashes in beta5!

56kaudio does seem to help bringing the refresh rate upto 60Hz from 50Hz mking the experience much better. (Refresh=Chipset in rtg settings) Due to that cgx setting being buggy with whdload I prefer to set 56k audio through Ahi on my real and emulated amiga.

"Addaudiomodes DBLScan refresh quiet"

I have test two twice with either CB64 and PicassoIV with no sync no error.
With sync ieither CB64 and Picasso IV demo run correctly but when i esc i have a glich in worbench screen without block.

Only with CyberVision 64 i have the start sceen error but if i click continue wb start normaly.

320x240 already create in normal , no doublesca.
I retest with doublescan?

In atthacment all.

Note: It possible are the driver of my pc?

Glich_Log.zipGlich.JPG
RoxxierError.JPG

Toni I have attached a screenshot showing the versions of CyberGraphx, in the video I used the 800x600x16 Resolution but it works well with 320x240x24

It looks like something (CGX?) gets confused if vsync period is too long, probably if it is less than 60Hz. Setting for example 75Hz RTG refresh rate (RTG panel) fixes it.

Unfortunately PCem SVGA emulation does not seem to have any support for querying current SVGA chip programmed refresh rate.

EDIT: and I think I found the bug that causes hpos error. S3 emulation runs blitter and 3d in a thread and when it finishes, it generates interrupt. Interrupt generation calls custom chipset emulation function that handles it. Only main thread can do this or things can go very wrong.

Interrupt bug fixed (uses thread safe method that was designed for PPC emulation)

https://download.abime.net/winuae/files/b/winuae.7z

Does this fix "hpos" errors and other unexpected glitches?

Is Very Very surgical work....in fact you are the mind and we are the arms :)

Great Work!

With Picasso IV i have winaue crush but with dumb (not always)

With CV64 not glich ,is ok.

With CV3D/64 i have a glich (not always) but error "h4.." NO :)
WarpTest don't see again image 3d.

WinaueBeta5Err8_PicasssoIV_Crush.zip
WinaueBeta5Err8_CV3D64_Glich.zip

Your results aren't very useful if you don't compare them to previous version. Almost everything you listed happened with previous version. This update mostly affects jittery behavior/"hpos" error.

CGX4 + 3D stuff not working is totally different issue and so far there is not enough information and nothing will happen unless someone finds some 3D program that makes debugging possible. (Or if warp3d _driver_ sources exist)

And following should be always included:
- CGX or P96
- Resolution used and also does it happen in other resolutions/color depths. (Very important)

Also never use Restart-button when logging/testing! It can cause extra side-effects.

Testing with Cgfx v4. After testing all the progs that would instantly crash for me, the HPos fix seems to be a success!!! A positive side effect is that the Warp3D framerate has doubled since Beta3 in the Engine demo and is now much more stable. Still some random flickering. The XIII demo now also runs without causing hpos crash.

Wipeout is almost running at a blistering 0.2 (maybe) fps!! ;)

Without Rest Button the probleam seems to be fixed!
Thanks a lot!

These strange issues seem gone with latest non-public beta

This is fixed in next beta.

Which is strange because all changes only affect PCem boards. Retest when next official beta is released.

I still haven't done any JIT checks why JIT Direct now works strangely with display cards.

Toni on my AfA One JIT works well with UAE Zorro III and Picasso IV, with some very rare RTG games to avoid a crash I have to set "Default" to RGB Refresh Rate

I noticed a big improvement with P96+Z3 with software like Elastic Dreams: I use to play an animation I created to test WinUAE:

baboon blinking
https://i.ibb.co/Br1VfZz/image.png

I always noticed a strange behaviour with all previous WinUAE versions: when I was moving mouse, animation usually played a bit faster... Now with latest beta it's ALWAYS faster at constant speed and is no more mouse movements dependent which is good (I use a 60Hz 1920x1080 WB, on a 144Hz g-sync display). Makes sense due to latest changes in 4.5.0 beta?

How do you know my sister in law????

:)

Lol

https://download.abime.net/winuae/fi...nuae_4500b6.7z
https://download.abime.net/winuae/fi...ae64_4500b6.7z

Beta 6:

- Fixed CV64/3D 3D vertical clipping. Fixes at least warptest corruption when test texture goes out of screen vertically.
- Fixed CV64 and CV64/3D weird behavior (pauses, possible "hpos" error dialog) due to interrupt triggering being called from a thread.
- Fixed possible crash if hardware mouse pointer was very near to end of VRAM.
- Debugger TO, Te and Tf didn't fully use current mmmu mapping mode. (For example TO output was corrupted if system was A3000 with loaded superkickstart)
- x86 bridgeboard VGA display stopped updating every time display when mode changed. (b1)

Previously known issues: CGX + Warp 3D: no textures (reason unknown, 3D part of Virge is not accessed at all when running warptest if texturing is enabled but is accessed normally if texturing is disabled). JIT direct + hardware RTG mode = glitches.

Ok, my bugs are back in public b6 (I still have that b5 17-10-2020 exe if needed)

Hi Toni,

The 4.5.0 betas crash the emulator for me when booting a config with A2386SX Bridgeboard. I tried both 4500b1 and 4500b6. I know the earliest 4.4.1 pre-betas did not crash this way.

My config is based on OS 2.1 with Janus 2.1 software. The exact point where the crash occurs is when BindDrivers is called from the Startup-sequence, so it's got something to do with loading janus.library and initializing the Bridgeboard.

The attached archive includes the config, hdf, nvr, and crash dump. I've commented out the BindDrivers line from the Startup-sequence, so the config will at least boot to Workbench. To reproduce the crash, open the Shell and run BindDrivers.

Does same happen using both 32-bit and 64-bit version? (see below)
And does winuae.7z always behave differently? (It is not fully optimized)

This might be caused by a compiler bug or some undefined behavior somewhere in pcem code. It also only happens in optimized build.

64-bit version seems to work.