This thread is going to be used for management of work, synchronization and communication regarding the upcoming 64-bit AROS release.

Basic information:

Target for the release is set for September 2026, with October as buffer in case of unforseen major issues. The work that will be happening right now will mostly be focusing on polishing, stabilizing and bugfixing. I will be keeping a prioritized backlog of topics to be addressed. Priority will mostly depends on how wide the impact is. New items will be added to backlog as discovered and reported. Items already on the backlog may switch order if assesment changes. I will be working the backlog from top to bottom. If anyone wants to help out, please just announce in this thread letting me know which topic you want to handle. If you make it - great, if not - no harm done.

At some point in time I will freeze further changes. Items that didn't make it, will have to be done as part of bigger updates after the release. Then I will need some time to do final packaging and final testing on different hardware configurations. Then comes the official release and we have a big party as migration to 64-bit is completed!

How you can help:

a) Install the ISO on your systems and start using it as if it were your main, stable system. Network, 3D, audio, USB, disk, etc. Report issues that you find. Be sure to check if an issues you report is a new issue or already existing one in release 20250418 with U3 update. When reporting issue please describe your hardware configuration. Don't be affraid of repeating that description each time you report an issue - I can't remember who uses which hardware.
b) If you still have 32-bit software that doesn't have 64-bit alternative and EmuV0 is not supporting it correctly, report this as well. Possibly there will still be some space for improvements.
c) If you can take up and fix some of the issues on the list or bug tracker - please do so. You can take up any you like - order doesn't matter here. AI agents should be quite capable of helping you fix some of the simpler topics.

Notes:
- Bug tracker (https://github.com/deadwood2/AROS/issues) has already been reviewed and bugs from it were selected. If a bug from tracker is not in the list below, I didn't select it - no need to report such bug again during testing.

Backlog:
- VGA booting is not working (regression) (#243)
- Mouse is jerky in USB3
- HDAudio doesn't work on GA-H81M-S2V
- AHCI is not stable in QEMU
- ASUS/NVIDIA - does not load with more than 2 usb devices
- SDK - global object destructors (#164)
- USB3 - gamepad doesn't work in VirtualBox
- SDK - SDL2 libraries not included
- USB gamepad not visible after restart (#141)
- ASUS - ps/2 + usb mouse + pad, adding second pad blocks mouse
- EmuV0 - implement network support
- SDK - problem with string.h (#246)
- SDK - compilation with c89 (#222)
- VBOX/AHCI - crash when copying large file in MCAmiga and starting FT2
- debug=memory not working (#242)
- NListtree crash in Prefs/Zune (#217)
- Editor crash (#212)
- VBox - Audio applications crash when inserting pendriver (#117)
- VMWARE - 32bit mouse pointer issue (#84)
- NVIDIA - driver misses VSYNC option
- EmuV0 - implement clipboard support
- battery.hidd - validate that it's working as expected on laptops
- VMWARE/USB - connecting QuickShoot II slows down system

First development build:

[url]https://axrt.org/development/aros-202609-D01-pc-x86_64-iso.zip[/url]

Note:
- I will publish development build for contrib release at a later date.

Changelog since 20250418-U3:

[code]
Functionalities:
Implemented reporting on fan/battery/power supply state (Kalamatee)
Added TaskTrace command for debugging (Kalamatee)
Implemented SSE/AVX mixer routines in AHI (Kalamatee)
Intial implementation of CPU frequency governor (Kalamatee)
Fixed race condition in many network drivers (Neil)
Implemented USB3 support in Poseidong (Kalamatee)
Updated NVidia driver to support up to GTX980 cards (deadwood)

Updates:
AROS build system (Kalamatee)
Kernel (Kalamatee, terminills, deadwood)
expat.library v6.0 (Kalamatee)
tiff.datatype v50.5 (Kalamatee)
tiff.library v50.3 (Kalamatee)
acpica.library 20251212 (Kalamatee, deadwood)
ahci.device v1.2 (Kalamatee)
muimaster.library v19.80 (Kalamatee)
asl.library v50.11 (Kalamatee)

64-bit support:

Functional fixes:
Prefs/Trident: fix display of icons in lists (Kalamatee)
Wanderer: add selected file name to status bar (Ivan Gualandri)
Wanderer: (bugs: #158, #227) (jalaguero)
broadcom4400.device (bugs: not working on Acer Aspire 5630) (Neil)
serial.device (bugs: not possible to echo "text" >SER1:) (deadwood)
mesa3dgl.library (bugs: glitches when resizing window) (Deremon)

Stability fixes:
i8042.hidd (bugs: Ctrl-Alt-Del reset not working) (Neil)
amigaguide.datatype (bugs: #228) (deadwood)
Monitors/IntelGMA (bugs: random startup behavior) (deadwood)
text.datatype (bugs: crash when dragging mouse outside window) (retrofaza)

68k support:
dos.library (bugs: #234) (deadwood)

[/code]

I’ll try to integrate this build into AROS One as soon as possible. I’d like to ask whether there are plans to fix MPlayer and the Janus editor for 64-bit systems – these are two very important applications that users rely on a great deal!

Wow, that is an ambitious list!

Just to confirm - given USB 3 is still experiental how much 'nitpicking' do you wish for around this (e.g. USB 3 not working at all on my HP i5 EliteBook)?

Also how much nitpicking for Emuv0 (e.g. popup menus give a crash in Hollywood)? Also in the last ew months there has been some discussion re. serial devices; is it possible to emulate 32 bit calls to serial usb devices (as used by Hollywood)? The latter is real wish-list and I do appreciate there are far higer priority things to be looked at.

Many thanks,
Nigel.

@AMIGASYSTEM

I don't plan to work on the editor - hopefully someone else will pick this up.

For MPlayer if this is a case of it crashing on some files, the please provide those file and it will be added to the backlog. If this is a case of MPlayer having an old engine and not supporting certain formats, this is something that might be addressed by me, but only after the release is done with more general ffmpeg changes. Also sources of MPlayer are available for anyone willing to give it a go before I have time to look at it.

@ntromans

USB3 should not be considered experimental anymore - it should be considered stable on "hardware that it detectes". It works on all my testing hardware (~10 machines, all but one Intel chipsets). Now I'm sure there can be issues preventing it from working for example on AMD chipsets. If enough people report their hardware not working completly with USB3 and there is some pattern to this (like a similar chipset) I might buy such hardware and debug this. It's simply the case that there must be enough impacted users.

EmuV0 popup menu -> will be added to backlog, please provide simple program that triggers this

EmuV0 serial.device emulation -> will be added to backlog, but at low priority

@deadwood
Regarding MPlayer, you should have received the reports; I'm attaching two links where I described the issues with artifacts and crashes involving certain audio formats,

https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1411&rowstart=40&highlight=mplayer&pid=8293#post_8293

https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1293&rowstart=160&highlight=mplayer&pid=6421#post_6421

As for the Editor, there's a bug that pops up when you perform a certain action, along with other annoying issues when searching for something and highlighting strings. I tried using AI to improve it by adding Open, Save, Copy, and Paste buttons, but I wasn't able to do it.

I also experience system crashes when I copy from a shell and paste into an editor; this happens when I'm using GCC and want to capture error strings. But this doesn't always happen it usually occurs on the first copy-and-paste; if it doesn't happen the first time, it won't happen again.

@AMIGASYSTEM

The forum posts you posted don't contains links to actuall audio files I can download to reproduce issue on my end. I need these files - if I can't reproduce the issue, I can't invastigate them.

I’ve attached a small archive containing various multimedia files that can be played in Guru using MPlayer. It includes audio and video files; in the videos, Guru may appear when the video ends:

https://drive.google.com/file/d/1f-FKUrbHAdUASUe1PfgrwLKc163F9fo7/view?usp=sharing

Another issue that I believe is important is the deletion of folders in Wanderer; in some cases, you have to repeat the deletion several times because not everything is removed, especially if there are subfolders and icons – this does not happen with Dopus4. This might lead users to think that the Delete command does not work in Wanderer

Why use Jano Editor when there are better alternatives? For example, in my distribution I included egVim, which is made specifically and is meant to be a simpler editor compared to Vim.

There are tasks that require simplicity and speed, and JanoEditor is the best choice. Also, on AROS One, JanoEditor is the tool I use to view all the text on icons; this makes it easy to copy or edit the text, which is useful for various startup scripts, etc.

On Wanderer delete issue:

- does this happen on one particular filesystem - for example FAT on USB devices or happens on different filesystem
- do you have windows for any of the subdirectories you tried to delete opened in Wanderer or did you have it opened in prior deleting the top level directory?

I've fixed a few issues with the Editor. Please test it on your end to see if these issues have been resolved for you as well and if any new ones have appeared If everything looks good, I'll push the changes to the repository.

Fixed: Crash after Select All + Backspace + mouse click (issue #212)
Fixed: The mouse wheel allowed scrolling beyond the content
Fixed: Cursor invisible after Select All + Backspace
Fixed: Scroll bar didn’t update after deletion
Fixed: The mouse wheel deselected the selection

@AMIGASYSTEM

I tested files you provided. I was opening them directory in MPlayer, not through the included icons. Some of those icons have too small stack which will lead to a crash. That has to be fixed on the icons itsefl and on the def_Icon. I noted down the crash on ac3 and aiff and added this to backlog.

AmiBridge.webm - player 3 times, NO CRASH, ICON HAS TOO SMALL STACK SET
2021 Apache.ac3 - CRASH
Carenvi.flc - played 5 times, NO CRASH
Cyruship.fli - played 5 times, NO CRASH, ICON HAS TOO SMALL STACK SET
Janus-Games.mkv - played 3 times, NO CRASH, ICON HAS TOO SMALL STACK SET
Shampoo.aiff - CRASH
UnARC.mp4 - player 3 times, NO CRASH, ICON HAS TOO SMALL STACK SET

FYI, updated backlog:

- VGA booting is not working (regression) (#243)
- Mouse is jerky in USB3
- HDAudio doesn't work on GA-H81M-S2V
- AHCI is not stable in QEMU
- ASUS/NVIDIA - does not load with more than 2 usb devices
- SDK - global object destructors (#164)
- USB3 - gamepad doesn't work in VirtualBox
- EmuV0 - crash with popup menus (TODO: provide test application)
- SDK - SDL2 libraries not included
- ASUS - ps/2 + usb mouse + pad, adding second pad blocks mouse
- USB gamepad not visible after restart (#141)
- EmuV0 - implement network support
- SDK - problem with string.h (#246)
- SDK - compilation with c89 (#222)
- VBOX/AHCI - crash when copying large file in MCAmiga and starting FT2
- MPlayer - invastigate crash with Apache.ac3 and Shampoo.aiff
- debug=memory not working (#242)
- NListtree crash in Prefs/Zune (#217)
- Editor crash (#212)
- VBox - Audio applications crash when inserting pendriver (#117)
- VMWARE - 32bit mouse pointer issue (#84)
- NVIDIA - driver misses VSYNC option
- battery.hidd - validate that it's working as expected on laptops
- EmuV0 - implement clipboard support
- EmuV0 - implement serial.device support
- VMWARE/USB - connecting QuickShoot II slows down system

@deadwood
As for the videos, it was my mistake to use the files from AROS One 32-bit, where the high stack wasn't necessary.
My memory actually played tricks on me—on AROS One 64-bit, those videos do have the correct stack.

[quote name=deadwood post=12978]@deadwood - @ntromans

USB3 should not be considered experimental anymore - it should be considered stable on "hardware that it detectes". It works on all my testing hardware (~10 machines, all but one Intel chipsets). Now I'm sure there can be issues preventing it from working for example on AMD chipsets. If enough people report their hardware not working completly with USB3 and there is some pattern to this (like a similar chipset) I might buy such hardware and debug this. It's simply the case that there must be enough impacted users.

EmuV0 popup menu -> will be added to backlog, please provide simple program that triggers this

EmuV0 serial.device emulation -> will be added to backlog, but at low priority[/quote]

Many thanks. One more thing with respect to Emuv0 I thought of today - handling screens, if possible.

Cheers,
Nigel.

What do you mean with handling screen? There is alrady code in EmuV0 that allows you to open window on a custom screen if it is passed via WA_CustomScreen or WA_PubScreen arguments to OpenWindowTags. I think your whiteboard software uses that?

[quote name=deadwood post=13005]@deadwood - What do you mean with handling screen? There is alrady code in EmuV0 that allows you to open window on a custom screen if it is passed via WA_CustomScreen or WA_PubScreen arguments to OpenWindowTags. I think your whiteboard software uses that?[/quote]

It's more querying screens - in Hoolywood getpubscreens() only ever returns 'Workbench' even when several screen are open and getfrontscreen() also returns just 'Workbench' even if it is not the frontmost.

Cheers,
Nigel.

P.S. I also just tried using a Hollywood script which loads a plugin from tools/emuv0/libs/hollywood and got an unhandled library function (dos.library LVO: 148). This could affect qite a few Hollywood programs as it's the standard place for shared plugins.

getpubscreen() -> added but with low priority

plugins - weird, plugins work for sure, many of the Hollywood programs that were used for testing were using plugins (like MUI UI pluging for example). That LV0 148 is StartNotify - this is for filesystem notification support - I don't really know why this would be used in connection with loading plugins.

PS. I assume you made a shortcut - code (32-bit) should be written to load plugins from LIBS:Hollywood and EmuV0 actually makes sure that this is translated to the correct directory on 64-bit host.

[quote name=deadwood post=13008]@deadwood - getpubscreen() -> added but with low priority

plugins - weird, plugins work for sure, many of the Hollywood programs that were used for testing were using plugins (like MUI UI pluging for example). That LV0 148 is StartNotify - this is for filesystem notification support - I don't really know why this would be used in connection with loading plugins.

PS. I assume you made a shortcut - code (32-bit) should be written to load plugins from LIBS:Hollywood and EmuV0 actually makes sure that this is translated to the correct directory on 64-bit host.[/quote]

Yes, the assign is set. I see the same that most plugins seem to behave fine; the offending one here is glgalore (I was interested to see with the new 3D drivers if it was possible to run a 3D Hollywood program).

Another bug that's been hanging around for a while:

Run Editor on its own screen (note the bug is not seem if Editor is run on Wnderer).

Run a Hollywood program that gnerates an error (although not all errors tigger the bug, it seems to be more with graphical functions)

Acknowlege the error requester - an Emuv0 error is popped up (see below) and the machine freezes:

Unhandled code path
Function: screenremapNV20
Code path: No match
Value: 0
Value 0x0

One more, but I don't know how you'll feel about this one - the Hollywood MOAI plugin can crash the machine to a black screen. I have two versions of SimpleWhiteboard, a MUI one for AROS and a MOAI one for Widows but which I do test this on AROS. Both have identical code aside for the calls to MUI or MOAI methods. When opening a new drawing window, everything is fine for MUI but as mentioned there's a crash to black screen for MOAI. I guess this one very much depends on how many Hollywood applications there are fro AROS that use MOAI rather than MUI.

Cheers
Nigel.