AROS ABI-v1 68k AMiGA Version

[AMIGASYSTEM]

AROS Hunk: Distribution "Nightly Builds" Amiga 68k based AROS ABI-v1 which includes software developed by the University of California available in HDF and ISO-CD that can be used on a real Amiga or in Emulation on WinUAE.
From the Download link you can download the HardFile, the ISO-CD, the ROM and the Floppy image (ADF) "Emergency-Boot".


AROS Hunk (1-6-2019): Download


This disk (image) contains AROS for the amiga-m68k architecture.

To boot, you can:

1. copy the content of this image or archive to a bootable partition, best case with the file system installed to the RDB (Rigid Disk Block) of your media, and attach it to your Amiga via an autoconfig mass storage controller (internal IDE ports or most SCSI/IDE expansions will do)

2. image the 'Emergency-Boot.adf' file to a floppy, or copy the contents of the 'Emergency-Boot' directory to an empty OFS formatted floppy, and run 'C:Install DF0:'

Whether you boot with the AROS Emergency-Boot floppy, or directly from your boot partition, it will start the AROSBootstrap program, which will softkick the AROS relocatable ROM image (aros.hunk.gz) into the RAM.

The Emergency-Boot should boot on any Amiga hardware with KickStart 1.3 or later, and at least 2M of KICK RAM, and
a total of 5M of RAM to run Wanderer.

If you have MAPROM style hardware, or want to burn an EEPROM, you can use the aros-rom.bin and aros-ext.bin
files. Both 512K images must be present in the Amiga address space as follows:

0xE00000 aros-ext.bin (512K)
0xF80000 aros-rom.bin (512K)

None of the programs on this disk are expected to operate under any version of AmigaOS at this time, except for AROSBootstrap.

Enjoy this technology preview!

[Twiggy]

Looks groovy. What's the minium requirements to run it?

[AMIGASYSTEM]

On WinUAE you can start AROS 68k at full speed with an A4000/040/60 JIT 256 RAM, you can use the Amikit or AfA-OS setting, you just have to add the two most recent Aros KickStarts included in the package.


On the real Amiga I think we need a 060 RTG with adequate RAM.

[turrican3]

could you explain how to set the empty hdf to install aros ??

ps: if only they could have continue the 68k series like intel did with the x86 ... The amiga and commodore could perhaps still alive today.

[hUMUNGUs]

A detailed "install / setup" would be awesome.
I´d like to install it on a Vampire. Will it run ?

[AMIGASYSTEM]

Originally Posted by turrican3

could you explain how to set the empty hdf to

Because empty hdf ?

hdf that downloads is already ready and use it on WinUAE is of a unique simplicity, follow my video attached.

Use HardFile "aros-amiga-m68k-boot.hdf" on WinUAE:

Video Tutorial

[turrican3]

thanks for the tuto.

[SvladJelly]

When this is recompiled for Vampire 68080 it'll be amazing.

[kamelito]

It looks great too bad it is so demanding compared to AmigaOS.
Is Exec in C? It should be 100% hand optimized ASM.

[hth313]

Originally Posted by kamelito

It looks great too bad it is so demanding compared to AmigaOS.

I believe there are two problems here, the more stylish Workbench replacements and the more generic graphics code that probably need some additional tuning.

AROS is open source, so anyone who feel inclined can help.

I try AROS on my A3000 and just got Scalos (another WB replacement) running. But also Scalos, which is quicker than Wanderer, has troubles and worse, consumes way too much memory.

Unless you have a more powerful machine, the alternatives seems to be Workbook (which is very simplistic and written for another use-case than being a real Workbench) or using some other launcher mechanism altogether. I consider either of these approaches and is mostly looking towards the latter as it actually may fit my needs better.

[hth313]

Originally Posted by kamelito

Is Exec in C? It should be 100% hand optimized ASM.

Yes, it is in C, but I would not make such claims before I examined it myself. C compilers have come a long way in the last 30 years. It was also originally written for a 7MHz 68000, and a 14Mhz 68020 is probably the baseline today.

I would guess that work on the graphics system would be more important.

Besides, it is just an exec. They are really only magical in the Amiga world, i.e. seen as totally impossible to recreate, given this magic ExecNG and its importance (ownership). It is just some f*ne assembly module, with lots of well defined API points, it should basically write itself from its API.

[savior]

Friday, June 14, 2019

Ahh how time flies ...

Well its been a long 3 years since my last post, with a few absences due to hardware issues amongst other things. I'm still not in a position to work on the things I would like, but due to a few people pestering me when I had decided to stop working on AROS, i've actually still been working away behind the scene (mostly to address issues wawa was encountering, such as missing atomic support to compile certain c++ code on m68k and arm).

One of the main things I have been spending a lot of effort on during this time is reworking the AROS build system so that components get exactly the flags they should for a given toolchain set (e.g. host, kernel and target), because in the past it has been very hit and miss on which ones the components end up using resulting in subtle differences in how the code is compiled in different environments.

After a good 3 or 4 years of hacking away at this I now feel like there is starting to be a light at the end of the tunnel, and feel confident that the components are now using the flags they should be (bar some minor fixes still needed in some specific components mmakefile's).

Another part of this was splitting up the flags passed to the compilers/assemblers so that they are in the correct variables rather than being all crammed into the CFLAGS, making it difficult to work with. Going forward it should be easier to manipulate the used flags so that e.g only the ISA components get replaced to compile for a different flavor of processor on a given platform, and this is currently used to make sure we get all the correct flags needed for m68k builds targeting 68000/020 etc cpus or x86 32bit and 64bit code generation.

Correcting this has allowed the darwin builds to be re-enabled (although due to their lack of maintenance, they probably still need fixes in the code base to get working..)

In combination with these fixes and changes (there is also better c++ handling in the templates, amongst other things), I've also updated the AROS toolchains through to the current experimental version 9.1.0 - which is being used to build the pc-x86_64-smp target. So far the toolchain has been successfully tested with all the AROS targets, bar PPC - although the ARM support is needing a bit of adjustment, which i'm currently talking with michal to get done.

Well, if you thought that might be enough to keep me busy - ive also been working on other things!

The m68k target has received some love to try and improve its performance and behavior a little, and address some problems using it on vampire - though this work is still ongoing. The uae generic gfx card code has been reworked into p96gfx.hidd and handles other devices better now, has fixes to the sprite imagery handling, and should work with multiple p96 .card driver instances at the same time. There is also preliminary code in place to detect remapped rom images so that AROS does not try to use the physical memory they occupy (e.g when booting an a3000 using superkickstart).

ATA device has had its api adjusted slightly so that it uses generic definitions for the controller/bus/unit interfaces inherited from the storage subsystem classes. AHCI devices has also been adapted to expose the same api''s and classes so they now operate using the common storage subsystem, allowing them to be enumerated easily in sysexplorer etc.

Finally, this summary wouldn't be complete without mentioning that I have updated our MesaGL subsystem from the quite old v7 we have been using since its initial inception, to the current v19! Unfortunately (and after discussion with other devs) it meant that for the time being the nouveau driver had to be disabled since it needs considerable work to be able to compile with the newer gallium code base, but if someone decides to do the work before Michal or myself can get round to it - we will finally be able to use modern 3d graphics technologies in AROS!. Im really quite excited about this, and cant wait to see the first OpenGL 4.5 code running native on AROS - and maybe even Vulkan down the line...

kalamatee Dev

[Ledfoot]

Interesting! Savior, great work! I can't imagine what a headache the compile flags stuff must have been!

Also very happy to see that some work is being done to make it work well on the Vampire. Really hoping to make it at least one of my OS builds on the V4 Stand alone when that comes out, but would also love to try it on my V2.2 on the A500 I have now...