What's the best/latest EUAE build for OS4?

@kas1e

The conversion time is not removed, its only hidden until something happens, like picasso96 unlock, DX_Rect or DX_Blit, or color changes, in all this cases, we need to generate new output bitmap.

I expect the issue with mouse, because bitmap locking, causes intuition to lockup, one of these things that’s bad in AmigaOS, if we ever get SMP support, this will be true SMP killer problem, because many of things that need two cores, like graphics will be blocked. Of course, not everything will be blocked.

its massive amount of data that must be converted in a short time, bitmap locking also course memory moved in and out graphic card, WritePixelArray is maybe better because moved data only one way, but then we don’t have accelerated on DX_Blit and DX_Rect. As wrote before pick, your poison. (Bitmap locking/GPU acceleration vs WPA/No GPU acceleration.)

Quote:

Not much, I benchmarked this conversion routines in Basilisk II, so I know they are better than the assembler junk, that was there before, and routines are so simple its hard to make them any more optimized, maybe you can unroll one loop, but that’s about it, and you wont notice much improvement.

@kas1e

Do you see any problems with memory leeks, lockups and exits issues? Are these problems fixed?
Quote:

It’s just a safety precaution, I subtracted 1 from the height.

Quote:

Maybe quake 68k, as it has a FPS counter.

@Leveforit
Issue with exit still there, yes. And mouse problem seems not just mouse problem : its like after some time of 8 bit screen use something bad happens and all start cra. Not just mouse, but everything. You cant run apps, cant move windowses normaly. And it happens not from start. You need to use 8 bit for a minute or so, so then bug happens.

I will make more tests today.

Ps. But this green line will be removed later ?

@kas1e

Quote:

Maybe I should send you my EXE file, can be problem with your GCC or compiler options. Sadly EUAE has lot of uninitialized variables, that can cause strange bugs as well.

I have mostly opened closed screen modes, switched between different AGA, and picasso96 modes, and can’t trigger any memory leeks that way.

(I did try to fix calloc issues you talked about; this should be handled.)

Of course, it can also be in one of this custom changes you can’t push to repo.

@LiveForIt
Quote:

Can you try to do exactly step above:

1). run uae, set in prefs:Screenmode any resolution but should be 32bit, let it be 640x480x32. Save, quit
2). run uae again, and choose to open on 640x480x32bit mode. So we open 32bit os3.x screen on 32bit os4.x screen.
3). Now, when workbench loaded, again run prefs:Screenmode and there pick the same 640x480, but this time 8 bit. And hit “USE”.
4). Now, wait exactly ~70 seconds. You can just do nothing, just wait 70 seconds.

Now, try to move mouse pointer : it start jerky, windowses start to be slow at opening, all crawl. Even on uae screen. But you can switch to os4 screen, it will be the same.

Now, try to “ctrl+alt+q” : you can't, it brings this “parent process has tried to exit before all children have” error.

Can you try exactly those steps, so we can see if you have the same issues or not ?

It looks like after a while of “copy routines code working” something goes bad. Maybe it overflows something, or some negative values happens to be , or so. But the fact is : if i run 8 bit on 32bit screen, after for about 70 seconds, everything goes bad. While first 70 seconds, everything fine.

And yeah, if you can, upload somewhere your binary too, i will give it a try. Potentially it can be those damn “wrong” values in config.f files, about which FlynnTheAvatar says on page 3.

There can be indeed some potential difference, so will be good if you can upload test binary compiled by you somewhere.

EDIT: i just checked when i run 32bit os3-p96 on 32bit os4 screen : no issues. Also, if i run again 32bit on 32bit and run "AGA" demos/etc : all fine too.

The issue only happens when we start using 8bit mode. At first, it ok (first minute), and then, after ~70 seconds, all goes bad. At least on x5000 it takes ~70 seconds. Not sure if it happens with ANY use of 8bit on 32screen, but at least pure workbench surely show this problem.

@LiveForIt
Oh, i found more easy way to reproduce this "after some time" issue together with "quit" issue.

Just do that:

-- run uae, run prefs:screenmode, and choose 8 bit screen. Let it be 1920x1080x8bit. Save, quit.
-- start uae, and in ASK requester select 32 bit mode , so it will be 1920x1080x32 os4 screen, on which we will open 1920x1080x8bit os3's screen.
-- now, once workbench load up (For me on x5000 it take 35 seconds till background and wbdock panel all loads) just move mouse. All fine, all ok.
-- and now just wait ~70 seconds (but for to be sure, wait 100 seconds for example). In this time (in those waiting secods), you can move mouse fine, everything ok. You can work with icons, open drawers, etc. And once 70 seconds pass, everything crawl and start to be choppy. Hitting "ctrl+alt+q" at this point give us this "exit" error.

So probably next step if you can't reproduce it , to just send me your binary, so we will have more details.

@All
Can anyone else check this on their setups ?

Hi,

I tried the lasted commit (#102 - P96: general improvements), and while 32bit P96 on a 32bit OS4 screen feels faster, I did not experience any major slowdowns or hanging uae on exit. Even after working for several minutes (starting and stopping StormC4 and compiling some example programs).

The OS is a fairly fresh AmigaOS 3.2.1 with the Aminet P96 installation. I had troubles in the past using the newer 3.x from IComp.

I will try later with my (rather fresh) AmigaOS 3.9 installation, to see if I can reproduce your issues there.

My specs:
AmigaOne X5000/20, 2.0 Ghz, 4 GB RAM, 240 GB SSD, Radeon R7 250, Sound Blaster Recon3D/Z, AmigaOS 4.1 FE Update 2, Enhancer 2.2, RadeonHD 3.7

@kas1e

Where to fine that latest builds

@FlynnTheAvatar
Quote:

You test wrong things :)

There are no problems with 32bit on 32bit. The concern exactly when you have in OS3 set 8 bit screenmode, save, quit, run uae again, and choose to run on 32bit screen mode. So you have 32bit os4 screen, and running uae where you have 8bit screenmode set.

I.e. you have "8 bit P96 UAE" run on real OS4's 32 bit screen. Only this part is problematic : 8 bit uae screen on 32bit os4screen.

Only in this combo you have slowdowns after ~70 seconds, and only then you have issues on exit as well.

Quote:

Those self build ones from liveforit's repo

@kas1e

No, I did not. I tested 32bit on 32bit and 8bit on 32bit.

32bit/32bit feels a bit faster than 8bit/32bit, but I did not see any issues with running 8bit P96 screens.

Running AmigaOS 3.2.1 with 1920x1080x8bit, P96 Aminet on 1920x1080x32bit OS4 screen.

@kas1e

But I don’t think its actual UAE that has a issues, it’s the OS that gets stuck, or resetting something, It’s a strange thing it seems to only happen in 640x480x8bit.

My CPU monitor, showing some increasing CPU, then going up 100%, and drops down to about 80%, then slowly go’s up again.

I get this errors from the OS on rs232.

[smbus_waitready] smbus stuck
[tmp423_temp_offset64] faild ot read cfg1

I keep having no crash on exit, when I guit the program..

@all

I have made some changes, I stress teste a bit, don’t see any problems so far, but the slowness bug has been hard to find.

@LiveForIt
Quote:

For me, it happens with any video mode, be it 640x480x8bit, or 1920x1080x8bit

Quote:

For me, when all ok (i.e., first 70 seconds), CPU monitor show ~95% of loading. Then, after ~70 seconds passed and slowness come, it drops to just 35%, and stay like this.

Looks very much like some strange priority switch somewhere. But strange that it happens not in all the modes, but exactly when we use 8bit on 32bit.

Quote:

I have no crash too, it just UAE binary didn't exit to the shell, and bring reaction based warning window about "parent processes wasn't blbalablbal". Like some process stuck.

And i should point out one more time on: this only happens when i wait till slowness happens, and then trying to quit. Until there is no slowness, i can quit fine, without this error.


Quote:

Oh ! So you find this issue in the end ? What it was ? If so, commit the changes of course !:)


@FlynnTheAvatar
Quote:

So you reproduce the steps i show running 8bit on 32bit, and then wait ~70 seconds and then start doing tests and no issues ?

Strange that for me, it happens in all the modes, but LiveForIt seems to can reproduce it only in 640x480 mode… Maybe it somehow related to the fact what kind of the background image we had and what we run on the os3 boot.

Hi,
is it possible to have an executable version even if in Beta ?
I always like to try programs

Of course I can't be of any help, as I don't have any real hardware.

But I would like to try this version you are discussing

Thank you very much.

Yes, I did the same steps as you:

1) Ran Prefs/ScreenMode and selected 1920x1080x8 and saved. It really switched to 8bit mode as I now have a green line at the bottom, and background image is dithered.
2) Stopped euae.
3) Started euae and selected 1920x1080x32
4) Waited for 2 mins.
5) Started StormC4 and ran some examples

8bit/32bit mode feels a bit more sluggish than 32bit/32bit, but I did not experience any slowdowns. To be clear, it feels sluggish right from the start, but it does not get slower with time.

This is my version compiled today:
https://1drv.ms/u/s!ApOoV0ole8uGrdcZtrVMUSS2-FI9cw?e=axL7qL

@Flynn
Strange things: i can't now reproduce it like i point out before even with my own binary ! But then, just after a while, i exit from uae, and run it again (still my binary) and bah, it happens just when workbench loads up, even didn't finish loading.

So then i give a go your binary and was able to reproduce it too. This time, what i do is:

-- set 8bit in uae's prefs:screenmode as before, save, quit
-- start uae, choose 32bit mode, and when workbench start to load up i start to open/close dirs on os3's workbench : ram one, works one, system one. And while loading of background image happens, i continue to open dirs, etc, and then bah, even worbench finished loading, all slowing downs.

Next time, i was able to reproduce it with your binary by just running uae, and just starting move mouse pointer while wb loads, and slowdowns come again.

Okay, now I had also your issue. Opening and closing drawers, changing the background, and finally doing a reset triggered it.

OS 4.1 got very slow until I quitted e-uae. And then I got the popup that some parts of uae are still running.

@Flynn
Yeah ! Exactly ! So you were able to reproduce those 2 issues, and that is good! Because it means it's not compiler differences or the way to build binary, or my only setup, but UAE itself.

Now only to find out some real reproducible way…

What make it all strange, is the fact that i was able to reproduce it only when i run 8bit screen on 32bit screen. Never have this when use 32bit on 32bit.

@kas1e

Pushed latest changed, hope it helps.

@FlynnTheAvatar
Thanks,

for the build,
I always try to get more speed,
I hope you all post test builds from time to time,
Thanks again.