@LiveForIt

Thank you, with the latest version I did not encounter the slowdown issue yet. But this versions seems to be a bit slower than the previous one. But it is still okay on 1920x1080x8bit.

And I am using TuneNet, WookieChat, IBrowse and Odyssey in parallel. With the old version the issue triggered even without using any of these programs.

I am testing with X5000 and OS4.1 FE Update 2 (Kickstart 54.30, Workbench 53.18).

Update:
The version on OneDrive is the latest one now.

@LiveForIt

Not sure, if it is caused by more aggressive/intense calculations, uae should be slow from the start, and the performance should not drop suddenly after some time.

Also, this would not explain why a thread keeps running after I quit uae using "CRTL + ALT + Q".

Thanks for the new changes. But they did not help; if at all they made the issue trigger faster for me. With the new binary the slowdown happened after a minute or so with just loading and compiling one example in StormC.

Before, it was quite hard to trigger the issue.

BTW: You can download the new binary from OneDrive. The object behind the link is updated.

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.

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

@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.

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

Magnificent work! I did some smaller tests, and the AmiGFX version seems to be much faster than SDL.

For example, opening the text editor in StormC4 takes several seconds on SDL, while it is instantaneous on AmiGFX.

There are two smaller issues with hosting directories as drives that might be worth looking into:

- Mounting the root directory of a host drive (e.g. RAM:) duplicates the entries when running "dir" on the guest.

For example, I mount the host RAM: as Shared: in AmigaOS 3.2:


- Setting the "s", "p" or "h" permission on a file will create a _UAEFSDB.___ file with the permissions. But on AmigaOS4, you could just set the permissions directly.

There are a couple of issues with the configure tests. To fix the issues with the wrong sizes, I use the following:



I made some smaller fixes to the e-uae codebase (#-key under SDL, fix for setting timestamps on mounts) at https://github.com/salass00/e-uae.

When I am thinking about it, you could use ssh2-handler or SMBFS to store your logs on a different PC or NAS. That will prevent corrupting your local filesystems if the system freezes.

The best way is to use a second PC/laptop.

But I understand that most people do not have additional hardware or space for that.

I am using an X5000 with RadeonHD 3.7, and for me the RAD never survived a (warm) reboot.

And yes, with warm reboot I mean CRTL+WIN+WIN, or the "reboot fast" cli command, or using "Restart AmigaOS" of the Shutdown option in the menu.

No, I am telling you I cannot make a make that can make a make.

Sorry, not yet. After aligning the FileInfoBlock to longword boundry, the version started to show signs of life. Still not much yet:

- It does not use the file Makefile by default, you have to use -f Makefile
- The implicit rules are behaving weird.

I did not manage to execute a Makefile fully. make clean seem to work, but nothing much more.

That would be great. This is the only thing that it does at the moment:

This my current state: https://github.com/josefwegner/make/tree/amigaos

It needs hacking the Makefile to compile and link amiga.c.

I will work on this issue later. Maybe we can get it to work without running configure. This would also allow me to build it with SAS/C.

Although it compiles, it does not do much yet. Most likely we need to rewrite the Amiga specific parts in src/amiga.c to use the new AmigaOS 4.x methods.

I guess you are talking about Bartman's excellent Visual Studio plugin. Yes, it contains make, gcc and gdb, but they are not native versions, but run on Linux, Mac, or Windows.

We are talking about a native make version; one you can run on your Classic or NG Amiga.

@walkero:

I guess the first decision is if we want to keep support for AmigaOS < 4.0 (= classic AmigaOS).

Trying to keep AmigaOS 3.x compatible, I do not see a lot of needed changes to the code.

But if you want to scrap support for older OS versions, we might want to rewrite major parts to be closer to the other OSes. But in this case I am not in a position to help as I lack inside in major parts of AmigaOS 4.x inner workings.

Well, a bit. Do not expect wonders, though.

Right now I hit the limits of my knowledge. Make is doing something strange with replacing functions with defines. GCC really does not like this. Has anybody any idea how I have to update these to make them working?



It defenitly does not like the first set of brackets (the one of the function).

Okay, and the next issue is that make assumes that Amiga compilers define _AMIGA instead of __AMIGA (not the two underscores).

Use this configure command to activate the Amiga parts in code (executed in abc-shell):


This fails later, though: