Could Ambient be ported to AROS 68K?
Or does it require MUI4 9after all we do have MUI3)?

In theory, you could port it to Linux, MacOS or Windows. The question is whether the required effort would be worth it compared to a complete rewrite, for instance.

If Ambient could be easily ported to AROS on any processor architecture, it probably would have been done by now. Afterall, the source code has been available for eight an a half years now...

Thanks Andre,
I'm just exploring a board design and it would have been nice to have a familiar interface.

Since I'm not talking Windows, Linux, or OSX, do you think it would be easier to port it under a 3.1 compliant API with MUI support?

Quote:

Obviously.

Would it be easy enough to be happen quickly? Please see my previous post. Ambient has been open source for eight and a half years and nobody has ported it to AROS so far. Clearly, this would not be a trivial endeavour or it would have happened by now.

Quote:

Thanks.
Scalos is available, but i still think I will look into this further.

BTW - Has anyone noticed that most of the links to download MUI 3.8 are broken?

I could not even get the latest ambient source and had to settle for one revision older.

> most of the links to download MUI 3.8 are broken

Aminet has it since 1997 so everybody should be able to find it:

http://aminet.net/package/util/libs/mui38usr

Good point Andreas,
After all, virtually everything else Amiga related is there.

Porting Ambient to AROS or elsewhere:

- most of the new stuff relies heavily on MorphOS exclusive features, so starting with an older source snapshot might not be that bad.

- build that snapshot on MorphOS with "legacy" enabled, this will disable even more problematic stuff ("legacy" was supposed to build MorphOS1.4 compatible)

- that build will most likely fail due stuff added without caring bout "legacy" or no "legacy".

- fix those issues.

- install 68k crosscompiler with MUI3.8 includes (or even Zune includes) and try again

- you now have a AOS3.x MUI3.8 68k Ambient-build and 50% of the hair you had when you started

Quote:

Oh, its far worse than that.
I can not obtain source code for MUI, so porting AROS68K to a platform and using either Scalos or Ambient is basically impossible.
While I'm sure they might release it for AROS68K, I'm opting out of this entirely.

The project I had in mind is now only going to use an Coldfire (or other processor) as a background co-processor (no real user access).

Now I know why you guys keep MUI development in house.

If the author had ever really wanted MUI to become universal, he should have let us have the source.

> I can not obtain source code for MUI, so porting AROS68K to a platform
> and using [...] Scalos [...] is basically impossible.

Scalos has been ported to AROS (ABI v1) a while ago, so MUI source code is obviously not needed for this:

http://sourceforge.net/projects/scalos/files/41.8-rc1/

> I'm sure they might release it for AROS68K

They already did:

http://www.youtube.com/watch?v=2uXY4d08EYU
http://www.youtube.com/watch?v=Dn5C8G3aDXU
http://www.aros-platform.de/Scalos.png
http://www.aros-platform.de/Scalos_Delete.png
http://www.aros-platform.de/Scalos_Prefs.png

Including the source?
Since that is my main interest.

> Including the source?

Clicking my first link shows a file called scalos.src.zip for download which I think has a great chance of containing the source code.

It is not just lack of MUI 4 for AOS but also lack of many new APIs Ambient is using there. New Intuition, graphics, DOS and Exec features are used everywhere so you have to write alternative code path in many places. Emulating new MUI4 features in MUI 3.8 is actually quite easy if you know MUI well enough but if you dont have prior MUI experience it is hopeless.

Andreas_Wolf,
Quote:
Wow! I am so happy tha t I do not have to cope with this ancient stuff anymore! It is years ago but feels and looks centuries passed by.

EDIT: ouch! Forum software f...s up the link when there is no additional space before closing tag.

Yeah, ugly isn't it Connor?

If I was using more powerful processor I could consider something Linux derived.
But I'd rather avoid that and stick to something lean with a quick response time.

As I'm only sourcing the parts right now, so I've got time to figure this out.

Either the 16/32 processor I use to master the system will also provide a graphic interface or it will just be used to provide services that the additional 8 bit CPUs (and support chips designed for them) would do much slower rate.

For example, why accept the limited transfer rate of a 68B44 DMA controller when a modern CPU could make the same transfers at several times the older part's rate?