64-bit AROS 20230430-1 Is Available

[AMIGASYSTEM]

A new version of 64-bit AROS is now available. It contains changes and improvements implemented in first quarter 2023.

You can find the full change log below. Enjoy!

The release can be downloaded from:
https://github.com/deadw00d/AROS/rel...v11_20230430-1
https://axrt.org/downloads-aros

Also, for the first time, an alpha version of native AROS for 64-bit PCs is available.

You can run it on a virtual machine or real hardware (support and stability varies; list of known issues below).

It can be downloaded from: https://axrt.org/development/aros-pc-x86_64-alpha-6.zip

Change log
Quote:

AROS ABIv11 20230430-1 changes:

Functionalities:
Implemented network driver for certain nVidia chipsets (Neil)
Synchronize Zune configuration across all builds (deadwood)
Restore build and functioning on pc-x86_64 AROS (deadwood)
Make native kernel more reselient in case of early error (deadwood, Kalamatee)
Added broadcom4400.device network driver (Neil)
Synchronize on use of ISO-8859-2 for Polish across all builds (deadwood)
First working version of nvme.device is available (Kalamatee)
Implemented FORMAT64 and SEEK64 commands in ahci.device (Kalamatee)
Stabilized handling of WARM reset, implemented missing shutdown handlers (Kalamatee)
Requesters add scroll bars if too much text is shown (Kalamatee)

64-bit support:
Correct size of fpos_t and ino_t C library types (deadwood)

68k support:

ARM support:
muimaster.library (bugs: MUI_Request not compiling) (deadwood)
Restore build of armhf AROS (deadwood)

Updates:
AROS build system (Kalamatee)
libz 1.2.13 (Kalamatee)
libpng 1.6.39 / png.library v53.2 (Kalamatee)
freetype 2.13.0 / freetype2.library v6.6 (Kalamatee)
libudis86 (Kalamatee)

Functional fixes:
Correctly handle __stdiowin when also using C library (deadwood)
gl.library (bugs: race condition during initialization) (deadwood)
hostgl.library (make it work with newer 64-bit hosts) (deadwood)
exec.library (bugs: wrong disassembly due to wrong start address) (deadwood)
ata.device (bugs: media insert/eject detection not working) (deadwood)
muimaster.library (bugs: MUIA_String_Acknowledge not readable) (deadwood)
png.datatype (bugs: 1-bit APLHA pngs not supported) (deadwood)
fat-handler (bugs: partition check too strict) (deadwood)
InstallAROS (bugs: not working with > 2GB RAM) (deadwood)
dos.library (bugs: SFS not working with > 4GB RAM) (deadwood)
C:Install-Grub2 (bugs: not working with > 4GB RAM) (deadwood)
GCC (bugs: sometimes generates non-loadable executables) (deadwood)
Kernel (bugs: wrong configuration of IRQ pins in IO-APIC, TaskReady list damaged) (deadwood)
Area.mui (bugs: events sent when not expected to) (deadwood)
pciusb.device (bugs: EeePC USB boot not working) (Neil)
Register.mui (bugs: tab text cannot be formatted) (deadwood)
String.mui, Area.mui, Cycle.mui (bugs: setting same value is causing notification) (deadwood)
pciusb.device (bugs: too long boot delay on AspireOne ZG5) (Neil)
ntfs-handler (bugs: accessing non existent entries) (Kalamatee)
DiskInfo (recognize more filesystems) (Kalamatee)
pciusb.device (workaround for MosChip MCS9990, detect addtional ports) (Kalamatee)
Kernel (bugs: SSE registers not preserved during interrupt) (Kalamatee)
timer.device (bugs: can issues interrupt after warm reboot) (Kalamatee)
C:Decoration (bugs: wrong rendering of paletted pngs) (Kalamatee)
i8042.hidd (bugs: regression in mouse detection) (deadwood)
crt.library (bugs: wrong time returned by clock_gettime) (deadwood)

Stability fixes:
graphics.library (bugs: boot driver not unregistered correctly) (deadwood)
MultiView (bugs: crash in About window when using amigaguide.datatype) (deadwood)
exec.library (bugs: crash when showing disassembly in alert requester) (deadwood)
Prefs/ScreenMode (bugs: crash on certain drivers) (deadwood)
acpica.library (deadwood)

Native version known issues:
- USB mouse/keyboard is only detected is connected during boot
- delay ~10 seconds when booting SATA disk
- nvme.device/SFS error in VirtualBox when installing
- possible NVME crash on some hardware, add 'NVME=disable' to grub command line as a workaround
- if you experience issues booting, try adding 'noacpi' or 'noioapic' to grub command line

[AMIGASYSTEM]

In preoparation also a 64Bit AROS One version, soon it will also be available for download !

[AES DANA]

I've been following the development, but I have some questions.

What's the difference between ABI V1, and ABI V11? I know that ABI V0 is for 32-bit AROS. I think those other two are both 64-bit, but I don't know much else.

It looks like a huge majority of software for AROS in the archives is in 32-bit format for ABI V0. If the move is going to be towards 64-bit AROS, what is the process by which all of this software is converted? I suspect 64-bit AROS will be much more attractive when there is more software to use with it.

I have a lot more questions but I guess I'll limit it to just these two for now.

[saimon69]

I did suggest some kind of sandbox wrapper to use the 32 bit v0 app in the 64-bit v1 but has been considered repetition of effort

[Kalamatee]

Originally Posted by AES DANA

I've been following the development, but I have some questions.

What's the difference between ABI V1, and ABI V11? I know that ABI V0 is for 32-bit AROS. I think those other two are both 64-bit, but I don't know much else.

To clear up some confusion (some I suspect on purpose) - ABI v0, was AROS from pre-2005 period - when it had no clear defined "ABI", and had many binary incompatibilities with AmigaOS. Because of this, the people involved in developing AROS agreed to work on ABI v1 - to give AROS some kind of stability "ABI" wise, and to fix up the binary incompatibilities. That's it. Nothing more, nothing less. There where some distro's started around the time when ABI v1 work began, and because of that it was agreed to allow some fixes to be backported, but unfortunately this has gone out of hand to the extent that "ABI v0" is being used to refer to code that is practically the same as ABI v1.

ABI v1 is the "official" branch of AROS developed on the git repository. Anything else is a fork.

It looks like a huge majority of software for AROS in the archives is in 32-bit format for ABI V0. If the move is going to be towards 64-bit AROS, what is the process by which all of this software is converted? I suspect 64-bit AROS will be much more attractive when there is more software to use with it.

I have a lot more questions but I guess I'll limit it to just these two for now.

[Kalamatee]

p.s the clue was in the name - ABI v0 - it has no ABI.

No other "ABI"'s are/were planned, or necessary.

[deadwood]

Originally Posted by Kalamatee

To clear up some confusion (some I suspect on purpose) - ABI v0, was AROS from pre-2005 period - when it had no clear defined "ABI", and had many binary incompatibilities with AmigaOS. Because of this, the people involved in developing AROS agreed to work on ABI v1 - to give AROS some kind of stability "ABI" wise, and to fix up the binary incompatibilities. That's it. Nothing more, nothing less. There where some distro's started around the time when ABI v1 work began, and because of that it was agreed to allow some fixes to be backported, but unfortunately this has gone out of hand to the extent that "ABI v0" is being used to refer to code that is practically the same as ABI v1.

ABI v1 is the "official" branch of AROS developed on the git repository. Anything else is a fork.

That's correct and to build on Kalamatee's answer further: From technical perspective both ABIv0 and ABIv11 are forks of official repository. While they are are forks, they share and continue exchanging code with official repository.

From user perspective, ABIv0 can be associated with 32-bit native pc and linux/windows hosted AROS that can run 32-bit applications currently available on Aminet/AROS Archives. ABIv11 can be understood as a 64-bit AROS that can run "new" 64-bit applications that need to be compiled from existing open sources.

Both of these forks have common goals:
a) backwards compatibility - software compiled today can be run tomorrow
b) stability - they go through a release process with user testing and bug fixes

These goals have of course implications. For a), not all code changes happening in official repository can be integrated with the fork. This means that binaries compiled for official with not work on fork and vice versa. For b) this means that latests improvements from official repository (that are available as nightly builds the next day) are only available on these forks weeks or months later.

[deadwood]

Originally Posted by saimon69

I did suggest some kind of sandbox wrapper to use the 32 bit v0 app in the 64-bit v1 but has been considered repetition of effort

Actually some sort of emulator/wrapper is somethink I was thinking as well. Time will tell if it's feasible.

[pixie]

Originally Posted by deadwood

Actually some sort of emulator/wrapper is somethink I was thinking as well. Time will tell if it's feasible.

Can we get a 68k wrapper/emulator free of charge, to piggyback all the Amiga software?

[deadwood]

There already is one - JanusUAE. I know it's integrated with Icaros Desktop so you don't see it working in background. I don't know if you can get more integrated than that.

[AES DANA]

Great, thanks for the info. That clears things up quite a bit.

[saimon69]

Originally Posted by deadwood

Actually some sort of emulator/wrapper is somethink I was thinking as well. Time will tell if it's feasible.

What are the technical difficulties of something like this? For me that am not a C programmer it would look like a 32-bit to 64-bit API/ABI call translator used to launch executables and avoid crashes, is more complex than that?

[deadwood]

Originally Posted by saimon69

What are the technical difficulties of something like this?

I don't know at this point in time.