Hi @Bohun ,
Atm I didnt tested the actual version on real hardware.

In theory it is two files to be used in the same emu68 style of boot:
Kernel = Emu68.img
Initramfs aros.elf

I am travelling atm (spending some time with my dad), but from the actual repo you should be able to run on a qemu enviroment using the run.sh script (as far as i can remember it should setup emu68 and aros from the source, patch, build and launch the qemu)

Its not booting at the actual state. It dies on startup-sequence (as i reseted the repo it didnt protected the amiga 24bits space, as it used to)

Give me 2 weeks só i can release a new build. (Atm the releases should work, but it’s from the legacy approach of an emulated machine+kick.rom)

The new approach uses a customized aros build (port) instead of a regular rom build.

Regards,

Hi @Bohun ,
I started thinking in the same way: aarch64 native with an emu68 subsystem, but now im thinking different.

Instead of thinking of emu68 as an emulation layer i am thinking of it as a virtual ISA.

But for sure, all the arch64 development will be used as basis for the bellatrix (all the hw support, for example)

But The idea is no longer treat 68k as an emulation layer, but the pi been as a full 68k machine (with it underline hardware, instead of an emulated machine).

Nothless, it doesnt conflict if someone would need a different behavior.

Regards,

Your solution is great if you want maximum compatibility with the classic Amiga. It's also more practical in this transition period, when there's practically no application software for ARM, and I assume that classic programs that don't access specialized Amiga chips will work. Theoretically, programs compiled in Hollywood for the 68k should also work. I can't wait for a stable version, but family is paramount (greetings to your dad)
On the other hand, when ARM application software begins to develop, which I strongly hope for, the native version of the system will start to gain importance. However, the RPi 3 isn't so fast that emulation wouldn't be a noticeable disadvantage for more demanding programs. Probably the best solution would be some kind of SD card switch or perhaps a software boot selector, as it would be nice to have two options without having to juggle cards.

Hi @Bohun ,
The first phase is : emu68 patches + aros port.
That would gave a chipsetless 68k

The second phase is the chipset emulation.

That is all bellatrix is about.

The raspberry pi 3 is the hardware that i own, but the same approach could be on rpi > 4 or even on a radxa orion o6.

Its another approaches from other targets. What is the desired behavior of each setup is an user choice.

68k (and emu68) has limitations, aros has limitations.

This initiative Will decouple emu68 from legacy world (hardware and software), impossible to say how it will evolve, but it is for me a valid path to try.

Regards,

Hi,
The first release of it reincarnation (new architecture design) is up.

It (at least) boots 🙃 and have some usb support, but it’s just the initial base.

If someone feels curious enough;

https://github.co...v0.1.0-rc1

Regards,

AROS May have competition soon?

https://github.com/stevereaver/uaos

Looks like it also implements M68K emulation

I dont know if competition would be the right term, but there are tons of initiatives over the net, what could arise is that things can get better assembled, i mean, reusing other projects.

Sure that i cant talk by others, but when i started rigel it was for have a portable chipset emulation library, so others could use it without the need of redoing it again.

I am not talking about this specific project, but as orverall scenario of things that are maturing.

I am very well served with the bellatrix initiative (it is exactly what i want), but each user has it owns expectations.

Regards,

That is why I said "May" and not "is", but you can't deny that it is trying to reinvent the "AROS" wheel which is Amiga for Intel/AMD chipsets (at least based on the original idea).

At runtime the kernel loads them into Ring-3 tasks and enters user mode via iretq. They communicate with the kernel through the INT 0x80 syscall ABI:
Bah. That's pretty slow. I don't get why people don't use the much faster SYS* instructions.

MMU sandbox — 4-level paging, 2 MB huge pages
That's also slower: he could have used 1GB pages to reduce to the minimum the TLBs usage.

Anyway, good to see another "AmigaOS revival".

Hi @cdimauro ,

I dont know how it will be latter, but atm i am very happy with the bellatrix (emu68) experience. It is exactly what i would like.

Dont have any benchmark, and no fancy stuff, but it seems to be an ok speed.

Regards,

Ps: i am very very happy. Its not yet how i would like it but it is allready exactly what i would like 🙃