> It cannot be lifted (safely). I tried that years ago and it just broke too many things.

Pity. Thanks for trying anyway.

What about trying harder? It does not need to be a black or white thing. (either making mem above 0x80000000 available to everything or nothing at all).

For example what about allowing all the executable code sections of ELF files (libs, exes) to be at address 0x80000000 and above (excluding maybe 0xFFFF???? as that could theoretically brake library function tables which are assumed to be offsets instead of pointers if first word in table == 0xFFFF).

Ram: drive using the > 1.5 to GiB area?

Is that possible?

I'm just curious - why would you need so much ram disk space? :)

Working with video gobbles it up

Yeah, honestly its not that much space.
Could be useful.

Another thing would be code that makes use of the second processor (in systems that have two).

pampers,
Quote:

The Lulz?

That, and the fact the memory is just wasted otherwise.

Alough thinking about it, Peg 2 max 2gb (and that's a bit dodgy, stick to 1gb), macMini 1GB, Powerbooks 2GB, dual 1.42 max 2GB, until the Powermac G5 comes out there's not much that supports >2gb anyway.

Unless YOU know different?

Yeah, but when we get support for the faster G5s, then we will have up to 8GB.
That leaves us with 6.5 GB to play around with.

I makes no sense to waste time to create workarounds for the 2GB memory limit primarily caused by backward compatibly, which makes no sense to most of us.

It would make more sense to eliminate backward compatibly, fix remaining issues and add new features to improve the system.

Geit

geit,
Quote:


Ah man, don't let Fraggle (or any of the other Amiga fanatics)catch you mouthing that heresy.
I don't see why we couldn't have both, especially with the new PPCs that implement hypervisors.
Total backward compatibility and components that break compatibility running on the same system?
Doesn't seem so strange to me as I run Windows7 under OSX.

geit,
Quote:

I don't think it's completely that way either... many of us are here because of the backward compatibility.

@Geit:
Could you tell me, which app require more, than 1.5GB?
I can't remember, have I used more than 600MB or not, but I don't think so.

On my x86PC and Linux, I was also happy with 1GB RAM, and Linux has much more bigger apps.

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.