deka,
Quote:

Well, OWB eats slowly all memory, but this takes hours before you need to quit and restart. But you are right. I am using the RAM disk massivly and never had any issues.

The main problem is that any future expansion of MorphOS needs to break compatiblity anyway. Multi CPU usage, memory protection, resource tracking, virtual memory, more than 2GB of memory, 64 bit CPUs, different CPU (ARM, x86, ...), dropping all those workarounds and unnneeded functions which only exist due backward compatibly. Each of those points will more or less break compatibly.

The best solution would be to implement all of those points during that process and break compatility just once.

By breaking compatiblity I mean PPC and 68K. Most software is available in source or the developers are still around and maintaining their software, so PPC is no big deal. 68K is no big deal, too as you can use UAE, which is able to hide the emulation quite well. In the result we get an even quicker and clean (code wise) OS, with all modern features, which still feels exactly like the MorphOS we are using now. I think this should be the next future goal as we´ll reach the end of the flag pole by supoprting the G5.

Wasting time in keeping existing stuff alive is a waste of time. This will just cause more bloated workarounds for e.g. memory expansion without any real progress. The hardware base is there and a current MorphOS and a e.g. NG MorphOS could even be installed on the same hardware. Just the used Software is not compatible to each other in such case.

Geit

@ Geit

Sinner

@geit

what do you think about enabling the use of >1.5GB as some kind of ramdisk? It wouldn't be a hack and could be quite useful for G5 machines. having 512MB extra on powerbook would be useful too. In order to simplify development and to avoid problems with real ramdisk it could appear as "Extra Ram" or something like that so it could be disabled entirely easily.

@ Crumb

I am not sure that this is the only thing that could be done to utilize the extra resources on newer machines.
ASMP could be used to make use of the added core.
If any process that would break compatibility was run outside Abox would compatibility matter?

Crumb,
Quote:

It is not just "enabling". Bigfoot stated somewhere (cannot remember where) that adding more (AFAIR a total of around 200MB would be possible) memory to the system memory on e.g. PowerBook would cause a lot of work and is not worth the result.

On G5, where you can have 8GB this would be a better result, but with mostly no use. I could imagine that adding the upper 2GB of the 4GB memory is possible, but I don´t think it is so easy for the upper 4GB.

I have no clue about the modes and internals of PPC cpus, but I know that a 2 or 4GB RAM disk is not useful for just showing the amount in the title screen and point on it.

I placed a tool named "Fakemem" in Aminet last century. It has the same effect without any effect and additional work. :D

Talking about this is not useful at all.

Same about the use of the second CPU. Of course one could create some library to support the additional core as e.g. coprocessor, but what for? What if two applications want to use it? It gets very quick very over complicated without any use.

Also there is currently no software using it. Wouldn´t it be more useful to get real multi core support, where the system maintains applications and cpus to get max out of the given hardware, instead of having a core waiting for an application asking for it?

Wasting time with writing crappy hack solutions is not what anyone should want. Such crap always fires back some day. In this case once the system will support real multi core, some hack must be provide to make the old core hack using software at least source compatible again. So you start a clean fresh OS with some crappy hack. Not very funny.

I know that from a users perspective all these "use as RAM disk" and "use as coprocessor" sound nice and easy, but they aren´t in any way. They are just shiny fake solutions, which lead into huge problems.

It is better invest the limited developer time into something useful.

Geit


[ Edited by geit 28.02.2013 - 14:52 ]

@geit:
Quote:
I agree...
We need more quality software (as were stated somewhere, this will be the next step after G5 support) instead of unused/hardly implementable features, like SMP, some plus memory, architecture change, etc.

The lots of MOS users want the AOS compatibility.
I'm not sooo much, but I feel day to day more often, that I should try some. (I'm a relative new MOS user. I started with 3.0)

geit,
Quote:

Not sure wether the effort exceeds the benefit. A library similar to the power up approach should do the trick. Krashan wrote quite something about it a while ago. Could be an in between solution until te big break finally is done. I assume it'll take some time till we see first x64 version once work on the actual transition has started.

> 68K is no big deal, too as you can use UAE, which is able to hide
> the emulation quite well.

...when running games, yes. For applications not so well.

> If any process that would break compatibility was run outside Abox
> would compatibility matter?

There's no 'if' to that. It's a fact that any process that would break compatibility with ABox API would have to be run outside ABox. There's no way around that. And whether ABox API compatibility does or doesn't matter to someone is a highly subjective matter. But to answer your question eventually: Inside ABox, ABox compatibility matters. Outside ABox, ABox compatibility doesn't matter ;-)

> Of course one could create some library to support the additional core as
> e.g. coprocessor, but what for? What if two applications want to use it? It
> gets very quick very over complicated without any use.

Some rough ideas on implementation and usage from a colleague of yours:

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=8831&forum=11&start=8
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=7405&forum=3&start=1

> Also there is currently no software using it.

No wonder when Quark currently prevents using it (according to Krashan).

>> It is better invest the limited developer time into something useful.

> I agree... [...] more quality software [...] will be the next step after G5 support [...] instead
> of unused/hardly implementable features, like SMP, [...], architecture change, etc.

I'm not so sure you really agree with him given that those two points are among the things he said he would like to see tackled after G5 support is done ;-)

> The lots of MOS users want the AOS compatibilitys

He says it "makes no sense to most of us", so it seems there is no general understanding of what most MorphOS users want or don't want.

I agreed with the quited line only...

Andreas_Wolf,
Quote:

Thanks Andreas.
Obviously Ambient would need some work to display the results of both processes, but it does not sound as hard as a full VM application.
As you have pointed out before, if we pursue an ASMP approach, compatibility issues don't exist.

> Obviously Ambient would need some work to display the results of both processes

You mean Ambient running in one MorphOS system displaying the window of a process running in another MorphOS system with both MorphOS systems running side by side on the same hardware (through hardware hypervisor, Quark boxing or whatever)?

The later.
There shouldn't be any limitations inherent in Ambient.

I just don't see what Ambient would have to do with it ???

Updating TaskManager and CPU-Monitor-screenbar to display 2nd CPU useage might be usefull, but apart from that ?

2nd CPU-tasks will need some way to allocate memory from ABox-side and some methods to send/receive messages.

Those tasks wouldn't have any access to other system-resources like GFX-HW or the filesystem. Atleast not in an initial AMP-enabled MorphOS.

>Those tasks wouldn't have any access to other system-resources like GFX-HW or the filesystem. Atleast not in an initial AMP-enabled MorphOS.

What do you mean you don't see what Ambient would have to do with it?

Obviously, you realize the problems displaying output from code running on another cpu.
Your own post kind of points to that.

@Jim

Do you even know what Ambient is ???

Hint : It's neither a gfx-driver nor a GUI-toolkit.

Actually it is "just" a filemanager/program-launcher sitting far ontop of these 2....

The initial AMP system would be just as limited as PowerUP was back then, read AMP task would have no direct access to ABox-functions (except for those specially added for comminication).

Once that is working, one might consider rewriting CGX and other drivers for "QBox" and have ABox-apps access it through some virtual drivers (or the other way round, but IMO a 100% "QBox"-MorphOS should be the endgame).

On top of that one might port MUI (which would run alongside ABox-MUI) and eventually Ambient (which than wouldn't have any need for direct ABox-access).

As Kronos already mentioned. Ambient is just an Application like DirOpus or Filer.

You don´t need to launch Ambient at all to run MorphOS. You could just launch any other filer application or simply end boot process in shell.

I did that for example when placing my Efika inside my arcade system to autorun Fortis without any visible desktop launch..

Geit

More then slighty rude Kronos.

Of course I know what Ambient is.

Its a graphics shell.

And each of your posts has stated pretty much what I alread said.

That it may need to be modified.

And I don't see the point in running two versions of Ambient.

If we assume that users are always going to have Abox running.

But I really like your vision for this better.

>IMO a 100% "QBox"-MorphOS should be the endgame

A Qbox based system with no need for Abox, or where Abox accesses Qbox for some sevices?
Yeah, I like that idea much better.

/me cuddles Jim (hope thats better )

Ambient does not need to be updated, running an ABox-Ambient in an otherwise completly QBox-MorphOS is absolutly possible.

There is nothing in Ambient that would make sense to be updated in a PowerUP-kind AMP setup.

There is nothing to be updated in Ambient with a QBox that has access to (or controll over) GFX or the filesystem.

Once all these steps have been completed (aka "in the year 2525") it might make sense to recompile Ambient for QBox which will surely need some changes on the way.

So yes Ambient is 100% irrelevant for the current discussion about implementing AMP as a basis for a future QBox.

Kronos, I cede the point to you.
Well stated.

> "in the year 2525"

No that is funny.
Then again, its only 12 years.
I hope to still be using MorphOS then.

BTW - I prefer gruff to cuddles (especially if I need to be taken to school).

The only GUI I ever had access to source and influence on porting was Steve Adams Gwindows package (which my company ported to our OS-9 68K systems). Relatively crude in comparison to AOS' interface let alone Ambient.

Jim,
Quote:

Don't skip over those math lessons this time !!

Opps!
2525!
Chicago, right?
Damned American education system.

No, I do not expect to be here five hundred and twelve years from now.
I'm not sure I even want to know what things would be like by then.
At its current rate of acceleration, evolution will have turned us into something we would not recognize.

No Zager&Evans:
http://www.youtube.com/watch?v=FKSCQ94bJUI

But I prefer the Laibaich version:

http://www.youtube.com/watch?v=JpRjFSsteLc