I enclose 12 of ABIv0 Tools compiled for "x86-64-v11".

This is the list of x86-64-v11 Tools included in the archive:

- ZuneARC-x86-64-v11.zip (Fix Config, now you can create LHA, ZIP, TAR, TAR.GZ, TAR.BZ2 Archives,)
- Alac-x86-64-v11.zip
- Ami-PlayMOD-x86-64-v11.zip
- Bin2Iso-x86-64-v11.zip
- DirTree-x86-64-v11.zip
- DiskUsage-x86-64-v11.zip
- JoyTest-x86-64-v11.zip
- Nomarch-x86-64-v11.zip
- ResCode-x86-64-v11.zip
- SkandalfoClock-x86-64-v11.zip
- TimeIt-x86-64-v11.zip
- TinySID-x86-64-v11.zip

That's great! Make sure to post them on AROS-Archives as well.

Amiwell is doing it, whom I thank, I continue to do some other compilations, some are too complicated for me as I am not a developer! to compile I am using AROS One 64Bit v11

I attach 10 more of ABIv0 Tools compiled for "x86-64-v11"

here is the list:

- ZuneSVG-x86_64-aros-v11
- Potrace-x86_64-aros-v11
- QLView-x86_64-aros-v11
- BadApple-x86_64-aros-v11
- Grep-x86_64-aros-v11
- SFSobject-x86_64-aros-v11
- SidDump-x86_64-aros-v11
- UnLZX-x86_64-aros-v11
- UnMount-x86_64-aros-v11
- UnTarka-x86_64-aros-v11

Wow, your of fire with development

I have only compiled simple sources, unfortunately I have no experience in this field.

I have tried to compile some demos, but they all go to Guru because with error on SDL

Well every small bit helps to move us to 64-bit faster

I lightly tested and approved second batch of uploads. I rejected Bad Apple because it does not fully work with true 64-bit memory. It's something that I didn't mention earlier, but when testing make sure your machines has 5-6 GB RAM. As long as it has 4 GB or less, the address space is still 32-bit and certain bugs are not visible.

On the PCs I have 4GB of RAM, 2GB dedicated to WMware, I will see if I can expand the RAM, but are there other methods to get the error?

Should the 6GB be on PC or VMware?

Thanks for looking into the more applications! I hope they work well

The other method is to use AROS Linux hosted x86_64 and assign it more then 640 MB RAM.

Answering your second question: The 5-6GB should be assigned to VMware machine.

Another question but are the 6GB required for compilation or also for using the 64Bit software

No, they are not needed for compilation.

It's only when you have more than 4GB the real 64-bit memory is used and certain 64-bit bugs become visible. This means with your 2GB configuration you can compile and use some software without noticing issues but someone else who will have for example 8GBs will not be able to use that software.

OK thank you! I was not aware of this!

deadwood I have upgraded my PC, it now has 8GB of RAM, on WMware I have set "6GB of RAM", as you can see from the screenshot AROS v11 has split the 6GB to Wanderer Graphics 1.99 GB and Other Mem 3, 83 GB

Bad Apples ran for more than 20 minutes and no errors or Guru appeared.

Unfortunatelly sometimes these issues will go unnoticed on native. Application will keep writting memory that it does not own and everything will seem find until another application allocates that memory and then starts crashing. Hosted in much more stricter with regards to this - I discovered this issue on hosted.

Is it possible to block the lower 4GB, so that memory allocations are above 4GB?

On hosted.

Yes, on hosted first 512 MB are allocated from lower 4GB address range and anything above is allocated from higher memory range with higher range memory having higher priority (so used "before" the first 512M.

I always start hosted with -m 640 which is enough to exposed these issues. Actually same trick can be implemented on native but requires additional kernel work (lower range pages needs to be blocked from being usable via MMU).

EDIT: I checked ADT repo and the change raising priority was not integrated there. I'm not sure why. If you are interested here is the change:

https://github.com/deadwood2/AROS/commit/352eda1e281e5904e8ac5a77f6f450cf7e13e1c3

deadwood to receive the error I would have to find out which software is interfering, I have tried running many Applications simultaneously with Bad Apple, and received no error.

Only if I run Bad Apple from a FAT32 formatted Pendrive after a few minutes the video stops, but no OS crashes..

It's unfortunatelly Catch 22. The more RAM you have the smaller the chance you will find interference. Right now only using hosted is a relialable way to expose these edge case scenarios. On native they wil sometimes be exposed and sometimes not.

I will anyhow test new 64-bit uploads to archives on hosted so these issues don't slip through.

deadwood if it is of interest, i iinstalled the Linux Lite distro 64Bit (Base Ubuntu 24.04.1 LTS) on WMware with 6GB of Ram and BadApple worked fine no errors (ran for 30 Minutes).

As you can see from the screenshot, Wander shows 15.97M of Graphics Memory and 230, 37 of Other Memory, I don't know if these values are correct.

On Linux Lite I also tested AxRuntime and it worked fine, I ran MPlayer, FinalWriter and Shellll