Kickstarter for buying and open source Amiga OS

[wawrzon]

Well lets see:
- would this be 100% source-code compatible to anything written for AmigaOS3.x ?

- would this run stable while executing legacy code on a (non-existant) dual 680x0 setup ?

Noone ever said that it was impossible to write an SMP-OS with an API similar to AmigaOS running recompiled (and patched) SW.

we will see. this is a research operating system for a reason. stay assured that backwards compatibility subject has been discussed in depth, as customary on aros, to the point of taking hypothetic fpga 68k multicore systems into account. as far as i have seen aros x64 hosted already runs in smp, native x64 being implemented. this project was outlined and discussed just few days ago and subsequently been worked on by the person who made the proposal (jason) now joined by others.

[itix]

Does it really, though? Possibly a bit philosophical, but it loads 68K object code, but in the end and whether running interpretively or JIT, it's not 68K opcodes that are actually being physically executed. Eventually, it's a PPC native task doing the work.

It is indeed impossible to have SMP on that ecosystem. It is not enough to modify just system API but the software must be modified, too, where needed.

[Ezrec]

we will see. this is a research operating system for a reason.

Exactly. 'Silly-SMP' is a project to determine "What are the minimal changes needed to AROS to support 'full' SMP? Is it even possible?"

I had a bit of insight (misguided, and missing a lot of details, but I think pointing in the right direction) and I decided that, instead of just talking about possible design ideas, that "the code will prove out".

As of now, I can get a simulated dual-CPU system up on AROS hosted on Linux x86_64 (25% of the time - the other 75% of the time it crashes on boot).

Is it ready for prime time? No.
Is it ready for inclusion in AROS ABIv1? No.
Is it even ready for testers? No.

This is Research with a capital 'R'.

But that '25% of the time' _does_ show that a full SMP system on AROS is possible.

Lots of debugging, testing, more experimentation, etc etc. is needed.

But it is possible.

So far, the only 'user visible' changes are that some fields in
SysBase are NULL or zero, that previously had values:

* ThisTask is NULL (this is now per-CPU)
  - You should have been using FindTask(NULL)  anyway!
* Elapsed/IdleCount/DispCount is 0 (this is now per-CPU)
  - We (AROS) need to make an API to retrieve this per-CPU
* AttnResched/SysFlags changed
  - But you shouldn't have been using this anyway!

Strict priority scheduling is (currently) not strict at all, and I and Michal Schulz are experimenting with what that breaks in application-land, and if we really need to fix it.

The 'm68k changes' you see in the repository are for making sure unicore m68k still works - not for adding m68k multicore support.

But if someone *did* make a SMP m68k processor, there are MMU tricks that can be used to 'magically fix' the altered SysBase fields for pre-existing m68k programs - so compatibility is with AmigaOS 3.x is still possible.

For you Morphos/AmigsOS developers - if you would like to bounce ideas off of me with respect to adding SMP to your operating system of choice, feel free to contact me, or just silently watch my 'silly-smp' branch on gitorious.org

AROS (in my humble option) is here for the betterment of all AmigaOS-alike operating systems. We blaze the trail to the unexplored lands.

[Gulliver]

we will see. this is a research operating system for a reason. stay assured that backwards compatibility subject has been discussed in depth, as customary on aros, to the point of taking hypothetic fpga 68k multicore systems into account. as far as i have seen aros x64 hosted already runs in smp, native x64 being implemented. this project was outlined and discussed just few days ago and subsequently been worked on by the person who made the proposal (jason) now joined by others.

Congrats to the Aros devs for being the first in Amigaland to implement this important feature.
So despite some rough edges that still need to be polished in Aros, it seems in this aspect all other NG-Amiga systems will have to catch up

[ElPolloDiabl]

Thanks for the news. Congrats.

[nicholas]

For you Morphos/AmigsOS developers - if you would like to bounce ideas off of me with respect to adding SMP to your operating system of choice, feel free to contact me, or just silently watch my 'silly-smp' branch on gitorious.org

AROS (in my humble option) is here for the betterment of all AmigaOS-alike operating systems. We blaze the trail to the unexplored lands.

+1 :pint:

[magnetic]

Complete waste of a thread. Amiga os will never be open source unfortunately.

[wawrzon]

@magnetic:
at least this thread was good for an off topic to make people aware of some grand ongoing developments. whats left for me to say? jason, michal, krzysztof, staf, nick and other aros devs ftw! others, please join them in discussion and effort for common good, as requested. it can only benefit us all.

[Terminills]

@magnetic:
at least this thread was good for an off topic to make people aware of some grand ongoing developments. whats left for me to say? jason, michal, krzysztof, staf, nick and other aros devs ftw! others, please join them in discussion and effort for common good, as requested. it can only benefit us all.

+1...   It was bound to become public eventually and now this should make this sunday's Q & A on #team*amiga a bit more interesting.

The Asha Develder Memorial Internet Relay Chat is still going, and another
one is coming up next Sunday, August 25, 2013.

Chat will be starting at 3pm EDT (2000 UTC). We changed the start time in
order to include more people from Europe, as the original start time was in
the middle of the night for them. But we're still keeping it going through
until 11pm EDT (0400 UTC), with stragglers until whenever.

"SPECIAL GUEST: Joining us at 5pm EDT will be Jason McMullan who is
an AROS Team Developer, specializing in AROS m68k and AmigaOS 3.1
compatibility. Jason will try his best to answer all of your questions
about AROS, AROS m68k, and future AROS projects."

During Jason McMullan's visit, the channel will be moderated. Please feed your questions to the designated channel @operator or +moderator. Before and after the visit, it will be an unmoderated/voiced channel.

Standard Ashachat rules apply: No religion or politics until after things
wind down at 11pm EDT. And other IRC etiquette rules apply, as well, such
as no flooding.

http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29201&forum=2&start=220&viewmode=flat&order=0#715363

[guest3110]

Wrong.

Correction:
Commodore USA licensed the Commodore brand from Commodore Licensing BV on August 25, 2010 and the Amiga brand from Amiga, Inc. on  August 31, 2010.

[CritAnime]

Correction:
Commodore USA licensed the Commodore brand from Commodore Licensing BV on August 25, 2010 and the Amiga brand from Amiga, Inc. on August 31, 2010.

But for the CUSA facebook gang they beleive in the "they owened everything outright" concpet.

[psxphill]

But that '25% of the time' _does_ show that a full SMP system on AROS is possible.
 
Lots of debugging, testing, more experimentation, etc etc. is needed.
 
But it is possible.

Your biggest problem is going to be library reentrancy / atomic data update issues.
 
Some of the solutions, like being in a Forbid/Permit or Disable/Enable are likely to break. If you want those to continue working then Forbid will need to stop being a "don't let a task switch happen" to "stop all other cpu's and don't let a task switch happen", which is going to have a much higher cost.
 
Forbid/Permit was always a bad idea, but it's the bad idea we're stuck with that everyone uses.
 
Cache coherency might also be a problem, although that probably depends on the architecture. So you might find what you're doing works for X86 but you have to go back to the drawing board for ARM/PPC.
 
But you're right, unless you do something then nothing will happen.

[itix]

Your biggest problem is going to be library reentrancy / atomic data update issues.

On the other hand OpenLibrary() is relatively expensive call anyway so having to stop all cores when executing init/cleanup vectors  is not necessarily that costly.

Intuition has more critical Forbid/Permit sections (i.e. layer hooks) that can get quite costly. Or at least I guess so...

[dammy]

Correction:
Commodore USA licensed the Commodore brand from Commodore Licensing BV on August 25, 2010 and the Amiga brand from Amiga, Inc. on  August 31, 2010.

Barry Altman who owned C=USA died Dec 2012 and the family ceased operation of C=USA.

[number6]

Correction:
Commodore USA licensed the Commodore brand from Commodore Licensing BV on August 25, 2010 and the Amiga brand from Amiga, Inc. on  August 31, 2010.

That was renegotiated later:

On Dec 22, 2011 Commodore USA, LLC and Amiga Inc. signed a new contract granting us EXCLUSIVE WORLDWIDE rights to ALL format computers branded with the Amiga trademark IP. These registered trademarked logos include the BOING Ball, TIC/Check mark, letter A and the word AMIGA logos. Form factors include, but are not limited to Desktop, HTPC, Tower AIO/ Keyboard etc. This contract will run through Dec 31, 2018, with optional renewals. Additionally we have been granted the right to enforce the Amiga trademark IP, in instances where we feel the trademark property has been either used in an unauthorized manner or in a form not allowed under current international and US law. We look forward to releasing our initial Commodore Amiga branded computers beginning by the end of the first quarter 2012.

#6

[_ThEcRoW]

Since the majority of aros users, use it in x86 computers that have plentiful of power, why is a problem running an uae version that deals with the legacy software and give the rest of the os, the modern approach it need to implement smp?. Just a tought.