Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: ElPolloDiabl on August 21, 2013, 05:17:03 PM
-
Buy Amiga OS and open source it. By using Kickstarter you might attract more of the casual users.
I'm not doing a poll on this because I don't know how much they would sell it for.
What do you think?
Are there any possible legal problems?
-
Are there any possible legal problems?
LOL!
:lol: :lol: :lol:
:roflmao:
-
Who do you buy it from? Who actually owns the IP and can sell it? What if they don't want to sell? Some tough questions, there! ;)
-
instead of coming up with this stupid idea yet again use, test and contribute to aros on platform of your choice. be it on amiga (68k). help to make it faster and more stable. btw. even a simple smp implementation is underway just now.
-
If I was going to place bets on IP I would say Hyperion Entertainment and Amiga INC.
-
I changed my mind right after I posted. AROS is good enough.
Still if anyone would prefer this option, let us know.
-
I changed my mind right after I posted. AROS is good enough.
Still if anyone would prefer this option, let us know.
Why not a kickstarter to fund some full time developers for Aros? ;P
-
Buy Amiga OS and open source it. By using Kickstarter you might attract more of the casual users.
I'm not doing a poll on this because I don't know how much they would sell it for.
What do you think?
Are there any possible legal problems?
But you "don't believe in open source".
http://www.amiga.org/forums/showpost.php?p=745700&postcount=35
-
But you "don't believe in open source".
http://www.amiga.org/forums/showpost.php?p=745700&postcount=35
open source can be used in closed source forks usually. the only thing is to find some reason to make the people buy those when they can have it basically for free. so open source is the bottom line. aros might even become a resource for a new closed source paid for amiga os implementation if anyone ever bothered.
-
open source can be used in closed source forks usually. the only thing is to find some reason to make the people buy those. so open source is the bottom line. aros might even become a resource for a new closed source paid for amiga os implementation if anyone ever bothered.
I do believe there's a fair bit of in MorphOS already.
-
I do believe there's a fair bit of in MorphOS already.
Click here...
http://morphos-team.net/downloads
...and scroll down to "Source Code Releases" to get access to open source components in MorphOS.
:)
-
instead of coming up with this stupid idea yet again use, test and contribute to aros on platform of your choice. be it on amiga (68k). help to make it faster and more stable. btw. even a simple smp implementation is underway just now.
Not to be an egghead or anything, but when you say 'SMP' do you actually mean 'Symmetric MultiProcessing' or do you mean 'some way to utilise multiple cores'. ;)
-
Why not a kickstarter to fund some full time developers for Aros? ;P
How much in total would they need to have it fully working on Rasberry Pi?
btw. I could only spare $300
-
Not to be an egghead or anything, but when you say 'SMP' do you actually mean 'Symmetric MultiProcessing' or do you mean 'some way to utilise multiple cores'. ;)
https://gitorious.org/aros/aros/graph/silly-smp
-
How much in total would they need to have it fully working on Rasberry Pi?
btw. I could only spare $300
Throw some money at Nick Andrews (aka Kalamatee), he got the Raspberry Pi native version of AROS working... Now we need a working USB driver for it :-/
-
Not to be an egghead or anything, but when you say 'SMP' do you actually mean 'Symmetric MultiProcessing' or do you mean 'some way to utilise multiple cores'. ;)
https://gitorious.org/aros/aros/graph/silly-smp
Soon people will learn why open source is a very cool thing, won't they Nik? ;)
-
Soon people will learn why open source is a very cool thing, won't they Nik? ;)
I have no idea what you're talking about Matt. None whatsoever. ;)
-
https://gitorious.org/aros/aros/graph/silly-smp
Lies!!!
-
Lies!!!
Of course, it's not possible at all remember? ;)
-
Of course, it's not possible at all remember? ;)
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.
-
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.
Why don't you ask the author?
-
Noone ever said that it was impossible to write an SMP-OS with an API similar to AmigaOS running recompiled (and patched) SW.
You do realise that this description could easily be applied to MorphOS, especially when running native application software, right?
So, dual G5 support in the works?
-
https://gitorious.org/aros/aros/graph/silly-smp
Now that's just silly. Silly to expect me to fully understand what I'm seeing anyway. ;)
Obviously a commit log for changes to AROS for SMP support (topped by one for 68K architecture, which even my addled brain finds curious given the lack of multicore 68K Amiga systems). I just don't appreciate how far along the road they are to implementing it.
-
Who do you buy it from? Who actually owns the IP and can sell it? What if they don't want to sell? Some tough questions, there! ;)
As I understand it, Commodore once again owns the Amiga (trademark, logo, lock stock and barrel)...except for McEwen's Amiga Games (or whatever that company he started is called).
So, unless I misread something, things are essentially right back where they started prior to ESCOM splitting the two up (remember when Commodore went to Tulip computers? And Amiga went to Gateway?)
Full circle. Commodore, parent company of Amiga.
On a sidenote: I think it has finally had enough "IP washing" (to where any legal beefs could have arisen at any moment, through all the changes of hands--and whomever didn't speak up...missed out, legally).
-
You do realise that this description could easily be applied to MorphOS, especially when running native application software, right?
MorphOS still runs 68k alongside that PPC code, and AFAIK their are no changes to the API for PPC code to cater SMP. So in the end all old code would either have to be recompiled/patched or moved into a "legacy box" (which was the orginal plan some 13 years ago).
So, dual G5 support in the works?
None that I know off.
-
MorphOS still runs 68k alongside that PPC code
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.
-
As I understand it, Commodore once again owns the Amiga (trademark, logo, lock stock and barrel)...except for McEwen's Amiga Games (or whatever that company he started is called).
Wrong.
-
OH TEH DRAMAS!!!!! :flame::rofl:
-
Noone ever said that it was impossible to write an SMP-OS with an API similar to AmigaOS running recompiled (and patched) SW.
You do realise that this description could easily be applied to MorphOS, especially when running native application software, right?
The text you marked as bold in your quote, is rather what is required in order to go from where MorphOS is today, to a future with more "modern" features. Today, the Amiga legacy and backwards compatibility prevents this, but as Kronos said, an Amiga-like OS with similar (but not identical) API could of course be made at the expense of the legacy Amiga environment. Then things like 64-bit, SMP, true memory protection, the maximum memory barrier, etc could be dealt with. Applications made for the legacy Amiga environment that Morphos presents today would of course have to be adapted accordingly and recompiled (or run in a box like UAE or whatever). So this is a possible future path, not the present situation for MorphOS. Today, MorphOS doesn't present an API similar to Amiga, it presents *the* Amiga API, *the* Amiga environment that Amiga legacy apps requires to function, and the "modern features" like SMP can't exist here without breaking Amiga. CPU's (68k or PPC) isn't the point, the rules of the legacy environment is.
-
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.
-
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.
-
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.
-
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 :)
-
Thanks for the news. Congrats.
-
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:
-
Complete waste of a thread. Amiga os will never be open source unfortunately.
-
@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.
-
@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
-
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. (http://en.wikipedia.org/wiki/Commodore_USA#cite_note-3)
-
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.
-
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.
-
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... :)
-
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. (http://en.wikipedia.org/wiki/Commodore_USA#cite_note-3)
Barry Altman who owned C=USA died Dec 2012 and the family ceased operation of C=USA.
-
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. (http://en.wikipedia.org/wiki/Commodore_USA#cite_note-3)
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
-
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.
-
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.
Yes, that's the mechanism I'm currently experimenting with.
Forbid() is now 'stop all other CPUs but this one, and don't let task switch happen'
Disable() is now 'stop all other CPUs but this one, don't let task switches happen, AND stall any interrupts until Enable()'
Terribly bad for performance, but once we have a baseline for SMP, improvements can be made.
One idea I have is to make a variant of 'struct SignalSemaphore', and could be initialized to have semantics more like the Linux kernel's "spinlock()" and "spinlock_irqsafe()" class of functions.
That should allow us (AROS) to use that type of semaphore to protect datastructures instead of Disable()/Enable() and Forbid()/Permit() without the high cost of those global locks.
(Normal 'struct SignalSemaphore' won't help to protect things like the Exec Task lists, since it needs task switching (Wait() & Signal()) to do its magic).
-
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!
This is serious issue considering backwards compatibility. It is relevant only when running 68k binaries but using SysBase->ThisTask was always valid.
When writing new software or recompiling one (you are probably going to change ThisTask name to something else, right?) it is of course no issue.
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.
I fear issue would be performance when handling SysBase access with MMU. You have to alter Sysbase->ThisTask but other fields like DeviceList must be exactly same on each CPU. Is it possible without slowing down the system too much?
Another question is how are you handling interrupts? To my understanding handling interrupt will not halt other cores. It makes sense but is not compatible to the original implementation. It can break some software and possibly more than some drivers.
-
Yes, that's the mechanism I'm currently experimenting with.
Forbid() is now 'stop all other CPUs but this one, and don't let task switch happen'
Disable() is now 'stop all other CPUs but this one, don't let task switches happen, AND stall any interrupts until Enable()'
Do you restart the other CPU if Wait() is called in a Forbid() and then stop it again when the task that called Forbid() is rescheduled?
-
I fear issue would be performance when handling SysBase access with MMU. You have to alter Sysbase->ThisTask but other fields like DeviceList must be exactly same on each CPU. Is it possible without slowing down the system too much?
DeviceList (and all other lists, including TaskWait and TaskReady) are still on the global SysBase - so no worries on those.
Another question is how are you handling interrupts? To my understanding handling interrupt will not halt other cores. It makes sense but is not compatible to the original implementation. It can break some software and possibly more than some drivers.
In the current SMP experiment, Disable() causes the following to occur:
* An implicit Forbid() occurs, and the Disable()ing CPU waits for all other cores' tasks to finish their Quantum, and wait for the Forbid() to release.
* hardware IRQs are not longer delivered to CPU0 (which is the only core that can get hardware interrupts in this mode)
Enable() does the opposite:
* An implicit Permit() occurs, enabling tasks to start running
* hardware IRQs are re-enabled to CPU0.
-
Do you restart the other CPU if Wait() is called in a Forbid() and then stop it again when the task that called Forbid() is rescheduled?
Yes, that is the intent.
-
Moderator: Sorry! I think this thread is RAPIDLY drifting off-topic?
Can break this into a new thread?
-
* An implicit Forbid() occurs, and the Disable()ing CPU waits for all other cores' tasks to finish their Quantum, and wait for the Forbid() to release.
Is that how your forbid works? That the other cpu is only stopped when it's quantum expires? That would probably be a mistake, the first cpu might be trying to send a message to port that is on the other cpu (which currently requires a forbid to make sure the port doesn't disappear before you send the message).
* hardware IRQs are not longer delivered to CPU0 (which is the only core that can get hardware interrupts in this mode)
How is the second cpu task switching if it has no hardware interrupts? Is it controlled by the timer on cpu0?
-
AROS SMP technical discussion continued at:
http://www.amiga.org/forums/showthread.php?p=745839