New multi-core kernel for AmigaOS 4 shown at Pianeta Amiga!

@eliyahu

Yeah, I tested it on my Sam460 (used for demo on big screen), I launched the MESA demo Chaos Theory with a Bluetooth speaker.

It was crackling on heavy scenes but Andrea knows about it.

Pictures of the event : https://amiga-ng.org/resources/PhotosTripleA/?dir=Pianeta2026

That's a miracle!
A first step about a next fully open sourced AmigaOS based on PowerPC platform to grant max compatibility.
..And new drivers and new hardware!!
And also full compatibility with Linux PCC.. what's else?

Thanks to everyone involved!

@afxgroup

CONGRATULATIONS ON YOUR PROGRESS WITH THE KERNEL!!

I was wondering if you could tell us a bit about how it works.

Are all the cores accessible to any OS4 legal app or are the
added cores only used for specific apps & purposes?

From what little we've seen of the AEon blackbox, it seems like
that has been a big hang up with ExecSG (as little as I know).

How is memory handled? OS4 can address 2GB and has it's
addition of ExtMem - how does that work with all the cores?

Similar questions exist for the graphics drivers you're working
on. Any information on the plans to support hardware video
decoding, etc.?

Of course we all have so many questions!

Keep up the great work!!

Thanks!!

PJS

A wonderful development! It would be great if the new kernel were already compatible upon the release of Tyche.
But well, I'm dreaming... (:

@balaton

Quote:

Same author, different jit compiler.

The EUAE jit compiler was written from ground up, he had to take into account of virtual address space, while Petunia lives in same address space as AmigaOS4.1. the EUAE one has uses JIT blocks, that can optimized away, in special conditions, Petunia JIT does not.. If I’m not mistaken.

the Petunia JIT has its own kernel module, not compiled into exec library, it can be that it can work, or not, but no 68K software was written for SMP, the same goes for OS4 software, but then again, I assume OS4 code is lot more clean C code, then OS3 code with a lot mort assembly code, and room for short cuts.

At moment musashi is working at same speed of petunia (EUAE seems to have the same speed since a game is loaded in the same exact time).
With this kernel you can choose which emaulation resource you want to use so you can exchange musashi with another one without any problem. But at moment speed is the last of the tasks I'm working on. First there is the stability. And in any case 68k code is always working on core 0 since software is using SysBase->ThisTask that can't work with SMP

@afxgroup

about Tabour

Quote:

https://www.exec.pl/article.jsp?nid=18 ... iew_with_Trevor_Dickinson

I assume trampoline is missing in the AROS kernel.

@eliyahu

Wow, a multi-core ExecSG compatible kernel. I didn't see that coming.

Really nice job @afxgroup.

New RadeonRX drivers are a surprise too.

I'm enjoying watching the progress happening over the last few months...

@samo79

I don't consider Warp3D Nova to be a failure. Both it and the 2D drivers I wrote helped get us this far. I'm very impressed that @kas1e managed to get full mesa3d working via reverse engineering the *_RM.resource to access the GPU.

Hans

@Hans
More of it Mesa still use your drivers today, because driver from Acube is not yet ready, and that all need to be checked/rechecked if it will offer better speed/functionality.

For now the real missing thing i wish your driver have it 100% guarantee of GART based allocation in return, as for now it sometime depend on fragmentation probably or something else, can return pure VRAM , and so the same run of the same app may give different fps in some places. But dunno if that possible to do at all on os4.

While I am impressed with this kernel, I red a statement from someone involved in Hyperion and they can´t use this kernel for an official release because of legal issues.

This is a little showstopper for me. I hoped that an alternative kernel will solve the "drama" behind the scenes about the current kernel and regarding ports. But it didn´t.