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 🙃

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".

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).

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,

AROS May have competition soon?

https://github.com/stevereaver/uaos

Looks like it also implements M68K emulation

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,

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,

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 ,
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,

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,

What can I say... Bravo!

@CoolCat5000

Could you please provide concise instructions for a layman on how to run bellatrix on a Raspberry PI 3?

Someone is already working on such a thing

It's amazing how things have progressed with the Raspberry Pi 3. Two implementations are being developed side by side: one native, the other with Emu68 (Bellatrix). I'm thinking it would be great to combine these two projects to allow applications compiled for 68k with Emu68 to run on the native ARM version. It would be a blast, combining a native system with the ability to draw from the rich 68k software library.

Hi @Bohun ,

I have Just reseted the repo so its now at the same state as i mentioned earlier. Its not booting as i thought, it stops on random parts at startup sequence (boot 4 at 6 runs, more or less)

Bellatrix objective is run aros under emu68, maybe with chipset emulation (not sure if it is even desirable to have the chipset)

Emu68 act as a virtual ISA on the plataform, so you have a 68k with the pi hardware.

Emu68 almost support this, need some small changes and aros need to be ported to it, as it is a chipsetless 68k target.

Regards,

Ps: I had started the reincarnation of it, as i mentioned, even the boot isnt stable yet, but maybe looking the source you could have a better understanding.

Ps2: no, it doesnt use Linux

https://github.co.../tree/main

I've been reading this thread but I don't fully understand what Bellatrix/Emu68 is. Is it an application that runs on Linux?

Hi, again,
The bad news is that bellatrix will need an overall redesign.

The good news is that i got aros running under emu68 with good results.

I now know how it is supposed to work, so i should change the approach toward that direction.

Infact, the ideal approach would be have an emu68 variant for aros and an aros variant for emu68, but that involves aros and emu68 dev teams.

There will need some amount of time and patience for me to assembly something to release, but i thought it worth to mention the positives results as it changes the perspective from “if” to “when”.

Regards,

AROS - https://github.co...-baremetal

EMU68 - https://github.co...st-irq-abi

The emu68 branch name is misleading, but the actual state of those branches should boot with each other.

Hi @cdimauro ,

Yes, we can play with the cores, but the real data, as the link i pasted shows, is that even 1 core can perform a full real time emulation.

That is the point, the baseline.

The real data would be to measure stuff, but even there i am lost. Probably it is just bad code or to much fine grained emulation, cant say yet.

Well, about the time, if there are others persons involved it May appear News, otherwise it will be stalled for a while. Anyway, the code is there. For me and for anyone interested in the subject.

Regards,

Great. The readme LGTM, however while reading it and thinking about this:
"i could use to try to optimize the chipset performance"
I suggest you to use the core #1 solely for the Blitter emulation, to completely offload all its work from the chipset core.
In this way you've the CPU and the Blitter, which are the most important elements for performance in the system, that can run 100% isolated and taking full advantage of the core. One core for the chipset emulation is good enough (I was thinking about moving the display logic on another core, but this never takes an entire core for processing the raw data and generating the final output).

P.S. I've very limited time, so I try to help when/if I can.

Hi @cdimauro , infact i got a great regression caused by my mistake (the fault handler stuff)

How the emulation should be driven and sync is not something that i really know.

But yes, there was some advances, like the z3 support that was missing.

Now i have all the pieces and bits that i would liked packaged togheter, even if its not working, or working with the regression status.

The regression fix will demand time and patience, its a testing flow with the real machine in the loop plus each variant and configuration matríce. But from what i had in mind the idea is now closed, só it is a kind of advance.

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

From aros perspective, that is the subject here, it sermos it is stoping at the low level library (i allready had that and fixed once, but regression).

I hope that now the readme is better:

https://github.co.../README.md

Even if the iso part is not fully correct.

I allready use the lide device for hdf and iso support (using the ODFilesystem), and used to work. Not under aros, but under ks20, for example, an it indeed boot a cu magazine iso. (Another regression)

I couldnt do any more teste, but in theory the v0.0.2-rc1 has USB, Bluetooth , rtg and sdcard features built in it.

I couldnt test it so o dono know exactly what is the state there.
(Unfortunelly cause of the regression se are not celebrating this release, a bitter taste)

I dont know when i can look into it again, thats why i released it anyway.

It damm show and broked, but it is what it is. The initial shape is placed and evolve will be time consuming, time that i dont have in the moment to give.

Kind regards, and thank you for the orientation, that design about how to drive and sync the emulation will be needed when we return to it.

In the source there is allready flags for sparsed deadlines and to toogle between timelines modes.

Also claude pointed me a version of uae that i could use to try to optimize the chipset performance

https://github.co.../teensyuae

I think that the poc is “done” but will need love and care and time …