deadwood, is it possible to correct the graphic artifacts when dragging an Icon ? If you try to drag a native AROS Icon but also a DualPNG Icon, around the Icon you notice black graphic artifacts, see screenshot I specify that on AROS 68k the problem does not exist, especially the DualPNG Icon when dragged and clean and clear !

FYI: The master branch of my AROS repository has been updated with around 220 changes from main AROS repository and is now up-to-date with it. If you have local linux-hosted compilations, it's best to do a full rebuild. The latest builds on build server, for both 64-bit and m68k, contain these changes. Known issues: a) Synchronization of usb 3.0 related work has been delayed to later date. As far as I understand the work is not done and it's possible that is introduces problems with existing 2.0 support b) if you have local pc-x86_64 builds, InstallAROS process is currently broken - it will be fixed before next release. If you detect addition issues after this update, let me know.

I don't find any anomalies

Ok so I can proceed to build the new AROS One 2.5. Regarding the USB image I will probably still use Rufus v3.2 and VHD format, unless in the meantime the new version of Rufus 4.5 will be released (like v4.4 It will only work on Win10/11). Meanwhile, yesterday the developer of Rufus informed me by e-mail that he has finally located the [url=https://github.com/pbatard/rufus/issues/2468][b]Bug[/b][/url] that I had reported to him on the AROS One Images with Rufus v4, referred to by him as "benign error, Read error: [0x0000001B] " and that it will be fixed in the next version.

Thanks. There are no more changes planned for U1 update. Unless some problems are found, the archive above will be the official release.

deadwood, actually I had already tested part of these updates, anyway everything seems to be fine ! In the Build you are going to release will there be more new update ?

Ok, corrected.

@deadwood link don't work ?

I do intend to synchronize patches from Apollo repository, but this is not on priority list right now - at least not for this year. There is a considerable effort in doing this and I want to set aside time to structurally move these changes.

Hello Deadwood, I just looked at Apolloos at github and there was a extensive commit https://github.com/ApolloTeam-dev/ApolloOS/pull/109 it is about screens, something heavily affects software on 68k because on Aros it can happen that a game or app asks for a PAL screen and gets RTG and then crashes. Perhaps it would be possible to update your branch too?

And we have a tie this month! To resolve that I did a flip of the coin the and winner is #125 - so this bug will be fixed in May. As for #140 it will then automatically be selected as June's bug.

Thanks Deadwood. I though it might be something like that :) I will try now.

many thanks deadwoodfor fix release

For D520 you need to add 'noacpi' to grub command line in order to boot.

I tried this build and AROS ABIv0 20211128-1. None of them work. Boots from CD then stops with some APIC failture. This is with DELL D520 laptop. The latest build from Deadwood that work fine is AROS ABIv0 20201110-2

Ok Thanks deadwood, I will test and report any problems, as soon as you release the stable version I will build the new AROS One 2.5 !

Hi All, I prepared an update package for the 20220318-1 release. It contains all the changes since the release was made. Please test it and if all works ok, it will be officially released in a couple of days: [b][url]https://axrt.org/development/AROS-20220318-1-U1-any-i386.zip[/url][/b] [code] AROS ABIv0 20220318-1-U1 changes: Functionalities: Simplify adding tethering in Prefs/Network (#115) (deadwood) Speed up boot using ahci.device (deadwood) Delete files with DEL key in Wanderer (#116) (deadwood) Updates: Use standard C library function names in SDK (deadwood) Functional fixes: camd.library, camdusbmidi.class (hitchhikr) ram-handler (bugs: #134) (deadwood) ahci.device (bugs: #135, unnecessary 60MB memory allocation) (deadwood) Wanderer (bugs: 105, offline volumes showing with "ghost" icons) (Kalamatee) rtl8139.device (bugs: no support for wrapped buffer) (stegerg) Stability fixes: crt.library (bugs: calling atexit in CTOR set crashes program) (deadwood) 64-bit/68k/ARM support: [/code]

Thanks to all who voted already and a reminder that today is a the last day to vote.

Done some tests confirming what said to jPV, the problem "output.txt" empty, as I had suspected is the fault of LHA native AROS version. I tried running the command c:lha *>ram:output.txt on "AROS 68k" with two LHA versions, one Native and one AmigaOS LHA (Native AROS) -> Generate output.txt "Empty" LHA (Native Amiga v22) -> Generates output.txt "output Corrected " Done other test on AROS x86 with [url=http://archives.aros-exec.org/?function=showfile&file=utility/archive/lha_4u4a-i386-aros.lha][b]This[/b][/url] version of LHA, output.txt is saved correctly !

Yes the problem of the "output.txt" file generated "Empty" exists on AROS x86/68k, but I think that of hangs from LHA which does not work well on AROS, in fact on AROS One I don't use LHA anymore, instead I use "XadUnfile" which works better and supports miolti other formats. Redirection with other Commands works fine and the file "output.txt" is generated correctly On AROS as reported [url=http://www.aros.org/documentation/users/shell/introduction.php][b]HERE[/b][/url] the Redirection should work fine: Example: dir >ram:a -> correctly generates the output file ! Also the command c:lha >ram:output.txt *>>ram:output.txt, works fine on AROS, but it generates an empty file !