Open Amiga is an effort to create a standard for the Amiga that developers and users alike can use in their quest for the perfect Amiga platform.This standard is intended to minimize the programming effort needed to port between the 3 current Amiga platforms, Amiga OS 4, AROS and MorphOS. And at the same time give You as the user greater flexibility in desiding what system suits You the most.
Here is the minimum specification proposed for the Open Amiga standard:
Kernel:
AmigaOS 3.1 compatible
2D Graphics:
CGX v4 compatible
3D Graphics:
OpenGL 1.2 compatible
Audio:
AHI 5.5
Networking:
BSDSocket compatible
Media Layer:
SDL 1.2
GUI Tool Kit:
MUI 3.8 compatible
Executable File Format:
ELF
In other Amiga-community news, the TTEngine 6.4 (a Freetype2 port library) has been ported tor MorphOS. Also, DCE uploaded a picture of the upcoming Pegasos 1GHZ G4 CPU module. Note that Genesi didn’t made a decision yet which CPU will be used (1GHz, 1.2GHz or 1.3GHz).
Please, don’t be shy!
Also, please can nobody post this to slashdot yet, as I want to sort out our new host and move everything across before I post it there. To be slashdotted would be quite embarrassing! 🙂
An exercise in futility if you ever saw one…
Good idea, but plagued by the lack of standards. How about the GUI? Directory structure? API standards? Standards for API extensions?
This looks more like a joke really. Get developers from all three OS projects to sit down and discuss these standards. Get them to agree on something.
>How about the GUI? Directory structure? API standards?
>Standards for API extensions?
Have you actually looked at the site, and read what we are trying to do?
Directory structure?!?!?!? You obviously don’t use AmigaOS or a compatible OS!
Eugenia or MikeB
Can you mod down the trolls above? Thanks.
Message from your favourite troll again!
…effort to create a standard for the Amiga that developers and users alike can use in their quest for the perfect Amiga platform…
What good are standards if they are either too broad, outdated or nobody follows them? Your current approach seems to be “make me an OS that has this, this and that”. Alright, good. Now, have you consulted with the actual developers of each project? Have they agreed to take part in this?
Futile effort at most.
You could show that you are really interested by adding some proper design and more content perhaps? You want OpenGL 1.2? Sure, give us links to the specification. You want BSD sockets? Drop an URL to the specs. That thing there is a wishlist, nothing more.
And no, I’ve never used Amiga
Alright, here’s one:
All this group is doing is formalizing the interexchangable standards that already exist between the various AmigaOS sucessors out there, and coming up with a formalization of this, so far, informal setup. All of these things *already* work with each OS, but there’s no guarantee things will stay that way. So this group is attempting to formalize it before things seperate too much between the efforts. I say it’s a great idea, one whose time has come.
AmigaOs moved alot from 68k 3.1.
68k 3.5 to 68k 3.9 to soon PPC 4.0.
All 68k SW will have to run in 68k emulation mode on AmigaOs4
Reaction is the free default GUI of amigaOs, not the 3rd party MUI witch the user will have to pay & register to get a key before you can use its features.
AmigaOs4 2D gfx is based on P96
CGX-V4 is a 3rd party 2D gfx package that you will have to pay for & there is no Guaranty that it will be compatable with AmigaOs4 2D gfx.
AmigaOs4 is looking to move to OpenGL 2.0.
Basicly it like asking ppl to write MacOs7.5 software for MacOs-X
Thanks for the vote of confidence Nate! 🙂
It’s a nice idea, but I would like to go beyond the functionality provided by the AOS 3.1 API from 1993. I prefer new software to take full advantage of AmigaOS4.
But if developers want to continue to support the AmigaOS3.1 API then that’s fine with me, but I hope these developers will create AmigaOS4 specific and optimized versions as well.
“”Alright, here’s one:
All this group is doing is formalizing the interexchangable standards that already exist between the various AmigaOS sucessors out there, and coming up with a formalization of this, so far, informal setup. All of these things *already* work with each OS, but there’s no guarantee things will stay that way. So this group is attempting to formalize it before things seperate too much between the efforts. I say it’s a great idea, one whose time has come.””
sucessors ? what are you on about for someting to be a sucessor it would need the former to discontiue its role.
That is not the case AmigaOs is still owned & being developed that is Aos4.
Even if development was no more seeing as amigaOs of what can be bought ATM is at 3.9 i would not call useing the other amigalike oses stuck at 3.1 sucessors, that would be a huge leap backward.
Choughing up a breeze of “troll breath” isn’t going to stop this standard from being specified. I think its a cool idea, to rally the troops and get some order on the future developments.
Ok, it looks like a few people here have missed the point.
All the standard API’s have an opensource compatible alternative. This are all available via the AROS project.
The CGX API was chosen becuase the other major gfx system on the Amiga Platform (P96) uses the CGX API…
MUI has the opensource, and fully compatible alternative called ZUNE.
The point of Openamiga is simply to let developers know the basic specification that is common to all the AmigaOSoids.
To be honest most developers already follow this specification, for the very reasons we are suggesting it. But now we can give this collection of API’s a name and developers can work to it if they wish their software to run on across all platforms with little or no modification.
I would hope also that we can use this spec to introduce standard ways of interfacing with new features that will become available, due to increasingly powerfull hardware and/or modern Operating system technology.
This should also allow a common, ie unbiased, forum for the OS teams to share ideas…
This standard should allow for more developers, more software and ultimately, more users.
It also allow choice…
Due to all the new systems and operating systems already being quite advanced in development i dont think it would be viable for them to start parts all over again os4 would be another 3 years if they tried.I is a nice idea though.
No, nothing new needs to be added or changed, this is just a consolidation of what already exists but at the moment it is a bit of a mess… 🙂
we are simply giving a name to what most developers do anyway!! 🙂
Uh, what are you smoking Mr “I’m too scared to post my name.”
MUI is included as part of MorphOS, and an MUI clone is included for AROS. Also, AOS4 includes MUI as well.
ReAction only exists for AOS4, so using it would eliminate the whole point of this exercise. Unless of course AInc is giving away licenses to it, along with source code, for the MOS and AROS team. (of course ReAction doesn’t do the same job as MUI, so you’d still need MUI)
“It’s a nice idea, but I would like to go beyond the functionality provided by the AOS 3.1 API from 1993. I prefer new software to take full advantage of AmigaOS4.”
There is always a conflict between standards and new features. The Web is an obvious example – do you code a Web page to the standards, or do you code it to take advantage of all Microsoft’s “enhancements”? (Do you really need a JS command to eject the CD drawer?)
Defining a standard means that developers have a document they can refer to, to make sure their work will be widely usable. If a developer wants to code for a subset of the available computers, because there is some special feature only they offer, he is always free to do so.
A standard is a guide, not a law.
As an example of a program that works on all Amigas and clones, there is Pagestream (a DTP program).
I think this is an excellent initiative, and much needed.
> The Web is an obvious example
Only most of the web does not conform to standards originating from 1993 anymore.
I do like this initiative though, but when I look at all the much needed new features various AmigaOS4.x will include it would IMO be sad to see if not many software titles take full advantage of these.
I hope that developers take full advantage of any new features as soon as possible. For example memory protection is high on my list I would like to see supported by new AmigaOS4.x applications and taken full advantage of as soon as it’s fully implemented.
IMO the problem is that if MorphOS and AROS do not go beyond its current AmigaOS3.1 kernel functionality this could eventually hinder more advanced developments, if these specs would truly become a standard for developers. Hopefully also MOS using the ABOX and AROS will go beyond the original Exec functionality and implemented ExecSG equivalent features.
Let’s just say that IMO this standard would have been very good many years ago, but now when finally lots of new stuff is being introduced it’s late and IMO underspecced for the near future.
ok, The choice for AOS 3.1 as the first cohice was because all the three systems support it at the moment!!
Openamiga is an idea to let developers know the common specification that is available across the OSs…
Yes, if one system gets MP (I would like point out the uselesness of MP at the moment), then the other system can implement a compatible system, and the Base specification will be raised… understand?
There is nothing stopping developers from supporting new features avaiable only on one OS, but at least now they can let their programs fall back to the Openamiga standard if the new features are not avaiable (on different AmigaOSoids)
now they know what they are capable of (damn this reads like syrup
)
ok, any questions?
Question to OpenAmiga: there isn’t much information on the site yet. What form do you see the documentation appearing in? As a series of categorised articles/tips/guidelines? Some kind of feedback forum with each would be useful.
Also, perhaps you could have symbols for each OS/version to indicate what OS the article/code/etc is aimed at. That way, you’re not aiming at the lowest common denominator all the time, and as the OSes progress, you don’t have remove or rewrite anything, just change the symbols next to it.
Assuming that programmers are going to write code that only works with OS4, then decide to port it, perhaps some guidelines on what to do with specific bits of code when it comes to porting it would be a good idea..
Just a few ideas. Good luck.
> (I would like point out the uselesness of MP at the
> moment)
Because there are currently no applications designed for this feature. That’s only reason why you could currently state that this very important and essential feature would be useless. But IMO when this feature is implemented new applications should immediately start utilizing the provided benefits, as else this feature would always remain “useless”.
Currently AROS isn’t on par yet with AmigaOS 3.1 and MOS lacks in certain areas as well. AmigaOS4 will include everything available in AmigaOS 3.9 and includes *many* new IMO necessary and essential features and technologies.
When looking at the feature list I wonder why CyberGraphX is a suggested standard though, while Picasso96 has been the standard for many years already?
Since when was Picasso96 any standard? People usually run whatever came with their graphics card, and P96 is a CGX clone, so stating CGX compatibility will include P96 as well.
“When looking at the feature list I wonder why CyberGraphX is a suggested standard though, while Picasso96 has been the standard for many years already?”
I run CGFX on my A4000, and always regard it as the standard. P96 seems to be a clone of CGFX, and slightly less reliable.
Unfortunately both are 3rd party solutions. There is no RTG code built into AmigaOS.
The same applies to AHI, but it is Open Source and free.
P96 is included with the latest versions of AmigaOS and that’s why I see it as a standard. P96 works well for me. I guess P96 works better with some cards and others with CGX.
P96 and CGX are similar retargetable graphics software sharing much functionality, but still I wouldn’t call them clones of eachother. I wouldn’t call them clones of EGS or other similar software neither.
Doing this is pretty much normal in the software industry – think Java, J2EE, POSIX, DVB etc.
The standard doesn’t have to be good, it just has to work.
It means a developer can write to the standard and it’ll work across everything that propely supports it (at least in theory).
There should be a reference implementation though as otherwise it could lead to a whole heap of problems *cough* WAP *cough*.
Is implementation X right or Implementation Y right? In this case the reference implementation defines the behaviour.
This could be 3.1 for now + the additions but AROS in the future as it matures.
Ultimately the other solutions (and maybe also AROS) will offer additional non-standard features but that is only to be expected – just as MorphOS has additions beyond the functionality in 3.9.
P96 includes CyberGFX compatability, allowing CyberGFX apps to run under P96. That is why it is called a clone: it cloned the CyberGFX API’s in order to ensure compatability.
Still I wouldn’t call P96 a CGX clone. P96 is based on the Graffity RTG and thus despite some compatibility(CyberGraphX emulation) and similarities between P96 and CGX, I would not call P96 a clone.
Why do you have to turn this into a “my xxx is better than your xxx” Mike?
Haven’t you asked yourself why most of the major Amiga news sites and a few non-Amiga tech sites have been officially notified of the news of OpenAmiga, but amigaworld.net hasn’t?
Just calm down for crying out loud.
WE AS A COMMUNITY ARE DEVELOPING OUR OWN STANDARDS TO CODE TO.
Can you code? Why are you so against this initiative?
Not onecoder yet has voiced a bad opinion of this, the only criticism we have had from coders has been CONSTRUCTIVE.
>I hope that developers take full advantage of any new features as soon as possible.
>For example memory protection is high on my list I would like to see supported by
>new AmigaOS4.x applications and taken full advantage of as soon as it’s fully
>implemented.
Read OS4 feature list again, please. It has no memory protection (no, protecting code
pages and unavailable memory is not memory protection… and it was already possible using AmigaOS3).
Memory protection will never happen in an AmigaOS. Unless it’s not AmigaOS compatible…:)
@ Nicolas
ExecSG was designed to allow optional memory protection for the future. But turning on MP would then break most of the currently available software and thus should only become the default when enough new applications have are available.
Mike, you don’t seem to understand what we are trying to achieve here. Read ann.lu and amga.org for a better description than you’ll see on here.
If you till don’t get it then fine. No problem. It won’t affect you anyway.
> Why do you have to turn this into a “my xxx is better
> than your xxx” Mike?
What are you talking about mdma, I was just stating my opinion and in addition I asked a simple question with regard to CGX.
Personally I would like to see future Amiga applications taking full advantage of AmigaOS4.x (Ami3D, AmigaInput, AmiDock, etc) and not just software for which I could have owned the now over a decade old OS3.1 for as well.
> Haven’t you asked yourself why most of the major Amiga
> news sites and a few non-Amiga tech sites have been
> officially notified of the news of OpenAmiga, but
> amigaworld.net hasn’t?
No that’s your business.
> Just calm down for crying out loud.
I am calm.
> WE AS A COMMUNITY ARE DEVELOPING OUR OWN STANDARDS TO
> CODE TO.
Please calm down.
Who is “we” here? Do you think you speak for the entire Amiga-related developer community?
Look, I applaud collective efforts to create proper standards, but IMO with regard to those mentioned specs you are many years to late. (Currently these specs are for which most developers already code for, but will change when AmigaOS4 arrives, thus late) I see this only viable for the very short term until AmigaOS4 is released and with regard to MorphOS for a longer period of time until they finally move to a QBOX environment.
Manybe some 3rd party developers will take *your* chosen standards as an advise, but nobody can dictate anything on developers to make sure they do not take full advantage of a newly offered products if they offer new and more advanced features. (Luckily)
You are over-reacting to my constructive criticism and second thoughts. Please behave, you have the freedom to follow any direction you want and so does anyone else.
“I see this only viable for the very short term until AmigaOS4 is released and with regard to MorphOS for a longer until they finally move to a QBOX.”
It will be useful for as long as there is Amithlon, AmigaOS 4, AROS, and MorphOS out there being used. Which is for the forseeable future.
If by coding to this standard, a programmer can hope to sell 100 copies, while using special features will limit his sales to 20 copies, this approach may make all the difference between the program getting written or not.
Most of the major advances in AOS 4 will benefit all programs and need no special coding.
> If by coding to this standard, a programmer can hope to
> sell 100 copies, while using special features will limit
> his sales to 20 copies, this approach may make all the
> difference between the program getting written or not.
I can only speak for myself, but if I am given the choice between buying an AmigaOS3.1 application or an equivalent application but utilizing all the advantages offered by my platform, I will chose the latter.
Sorry, just my honest opinion and freedom to do so.
>ExecSG was designed to allow optional memory protection for the
>future. But turning on MP would then break most of the currently
>available software and thus should only become the default when
>enough new applications have are available.
No, sorry… That’s story was build years ago by people without any
AmigaOS knowledge
Activating any memory protection inside an AmigaOS would break
everything: all applications and even the operating system itself.
It’s simply not possible and will never ever happen.
“I can only speak for myself, but if I am given the choice between buying an AmigaOS3.1 application or an equivalent application but utilizing all the advantages offered by my platform, I will chose the latter.”
Ok, lets see.
Company A writes Software Title 1 to OA specs and it comes on CD compiled for all 3 OS’s. It sells 300 copies.
Company B writes Software Title 2 to AOS4 specs. It sells 100 copies.
Company C writes Software Title 3 to MOS specs. It sells 100 copies.
Simple mathematics shows that Company A makes more money.
Who stays in business longest?
It’s capitalism at it’s most simple.
As a developer, if I can sell my software to a three times bigger market by adhering to guidelines, then I will do.
None of us is in this for a laugh. We want our software to reach as many people as possible.
> Simple mathematics shows that Company A makes more
> money.
And how do you know for sure that your *guessing* analysis and mathematics actually translate into reallife results?
Maybe company B or C sells alot more units because they offer something unique to that platform as they utilize the platform’s latest features and technologies.
> As a developer, if I can sell my software to a three
> times bigger market by adhering to guidelines, then I
> will do.
Assuming of course that all three markets will be equal in size, there is no overlapping userbase and there isn’t rival software available which does take full advantage of any specific features/technologies available to any of those mentioned platforms, etc…
A question how much software has been sold for AROS these last couple of years?
> None of us is in this for a laugh. We want our software
> to reach as many people as possible.
1) Develop for Windows.
2) Or if you are a freeware developer, develop for Linux and make sure your efforts are covered at Slashdot and Freshmeat.
Mike, there is no getting thtough to you. You seem to see this as a bad thing. Even Hans-Jorg Frieden said he likes the idea. Every coder i’ve spoken to likes the idea, the CEO of a large games software house likes the idea. My inbox is overflowing with postive feedback and ideas.
You seem to be the only one Mike.
It’s all well and god arguing for the sake of arguing on web forums, but we are actually getting of our arses and developing something for the community to use if they wish. And it’s available for free don’t forget.
Time+ServerSpace+Bandwidth = $$$
RE: Develop for Windows.
I do, for 8 hours a day 5 days a week. ;-P
> Even Hans-Jorg Frieden said he likes the idea.
That’s the first thing I said within this thread.
IMO you should take my second thoughts and criticism to your advantage, see it as food for thought, most certainly instead of believing that I’m your enemy.
>> Even Hans-Jorg Frieden said he likes the idea.
>That’s the first thing I said within this thread.
Where? I just re-read the entire thread?
anyway, it’s all academic really.
Let me put it another way.
Company C has written fantastic piece of software that is MorphOS only, no AmigaOS4 equivalent is available or if one exists it’s not as good. You personally really would love to see this software on AOS4 as you really need it urgently. Wouldn’t you rather the company wrote it to OpenAmiga specs and provided MOS specific functionality using external libraries (In the true Amiga way), so that they could simply re-compile it for AOS4 and include it on the same CD? You get the app you want, and only miss the MOS specific extensions. They may even write AOS4 extensions for it using libraries, or a 3rd party may implement them, or you could write them yourself. That’s the beauty of our beloved OS! 🙂
People have made their OS and hardware choices already, nothing we can do about that, we at OpenAmiga are trying to unite us all together under one umbrella. If the UNIX world and it’s many variants and clones can live together in peace why can’t we?
“Haven’t you asked yourself why most of the major Amiga news sites and a few non-Amiga tech sites have been officially notified of the news of OpenAmiga, but amigaworld.net hasn’t?”
There is only one major Amiga News site … 😛
Kees Witteveen
Amiga.org
>There is only one major Amiga News site … 😛
😆
Very true Kees, very true!
Now where is that Carl Sassenrath interview? 🙂
> ExecSG was designed to allow optional memory protection for
> the future. But turning on MP would then break most of the
> currently available software and thus should only become the
> default when enough new applications have are available.
Which in other words means that any other approaches than the “sandbox” one are completely useless. Even if you managed to mix things up in one kernel, there’d be no advantage whatsopever in making a MP-enabled program run alongside a non MP-enabled one, because they couldn’t even talk to each other (no message passing, as it requires shared memory). So, mixing things up in one kernel is just a futile exercise with no read advantage, but a lot uglier than the cleaner sandbox approach, which also carries other “nice” features, like letting you run different OSs alongside each other almost “for free”.
>>>>>>>>>>>>
I can only speak for myself, but if I am given the choice between buying an AmigaOS3.1 application or an equivalent application but utilizing all the advantages offered by my platform, I will chose the latter.
Sorry, just my honest opinion and freedom to do so.
<<<<<<<<<<<<<
How can you both read and write, and still be unable to grasp even a simple concept. 🙂
several things have passed you by…
1. Any feature that will radicaly enhance your computer using experience avaialbe in AOS4/MOS/AROS will still be there… And if the OS teams have done their jobs properly, any program using at least the AOS3.1 API will take advantage of these feature… I agree that there maybe some features that would be nice to have, but for the sake of more software I’m happy to ignore these for the time being.
What I’m trying to say is, you won’t notice if a program is not using a new function that allows the programmer to implement an IFF to bmp conversion, for example.
2. What you seem to think are amasing features new to these Oses are actually just extensions to the 3.1 API, any system that uses the 3.1 will use these new features.
3. CGX, AHI provide the most importatnt updates to the AmigaOS API ever for several reasons: 1. they are widely used by most (if not all) apps that need to use Graphics cards, Sound cards. 2. They are avaiable across all th eAmigaOS solutions. 3. THere are opens source alternatives/versions available.
4. MUI was a tough choice, I certainly dont want to dictate what the user must use, but MUI meets the requirement: 1. It’s widely used, 2. It’s avaiable across all the AmigaOS solutions, 3. There is an open source alternative available.
You see that P96 API was not chose, not because P96 is a lesser system (it’s the one I use), but because it uses the CGX API, so supporting the CGX API mean the users can use either CGX or P96, it’s thieir choice. The main impetus behind the standard is to give the user choice, and give the user more power over the OS projects.
> There is only one major Amiga News site … 😛
> Kees Witteveen
> Amiga.org
Was that ever in question? 😀
>Was that ever in question? 😀
Only by the great unwashed! 😉
Mike Bouma Wrote:
ExecSG was designed to allow optional memory protection for the future. But turning on MP would then break most of the currently available software and thus should only become the default when enough new applications have are available.
————————–
You have failed to grasp that the only thing you have going is this huge library of old titles, and by this architecture it will be the anchor that drags you under.