If...we were to discuss a real upgrade to MorphOS
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11762 from 2003/5/22
    From: Germany
    > It cannot be lifted (safely). I tried that years ago and it just broke too many things.

    Pity. Thanks for trying anyway.
  • »25.02.13 - 11:31
    Profile
  • Butterfly
    Butterfly
    Georg
    Posts: 91 from 2004/4/7
    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).
  • »26.02.13 - 08:04
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    stephen_robinson
    Posts: 745 from 2007/4/22
    Ram: drive using the > 1.5 to GiB area?

    Is that possible?
  • »26.02.13 - 20:48
    Profile
  • Paladin of the Pegasos
    Paladin of the Pegasos
    pampers
    Posts: 1061 from 2009/2/26
    From: Tczew, Poland
    I'm just curious - why would you need so much ram disk space? :)
    MorphOS 3.x
  • »26.02.13 - 21:09
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    osco
    Posts: 680 from 2009/10/21
    From: Boston, USA
    Working with video gobbles it up :-D
    Mac Mini 1.5GHz, 1G, 250G Drive, Apple Cinema Display, MorphOS 3.1 registered, MacOS 10 PowerBook (5,8) 1.67Hz, 2G, 80G Drive,........Waiting
    PowerBook (5,8) 1.67Hz, 2G, 40G MorphOS 3.1 unregisterd
  • »26.02.13 - 21:38
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4976 from 2009/1/28
    From: Delaware, USA
    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).
    "Never attribute to malice what can more readily explained by incompetence"
  • »26.02.13 - 23:16
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    stephen_robinson
    Posts: 745 from 2007/4/22
    pampers,
    Quote:

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


    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? :-P
  • »27.02.13 - 19:57
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4976 from 2009/1/28
    From: Delaware, USA
    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »27.02.13 - 20:51
    Profile
  • MorphOS Developer
    geit
    Posts: 996 from 2004/9/23
    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
  • »27.02.13 - 20:58
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4976 from 2009/1/28
    From: Delaware, USA
    geit,
    Quote:

    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




    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.02.13 - 04:31
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    deka
    Posts: 131 from 2013/2/12
    From: Hungary, Kecsk...
    @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.
  • »28.02.13 - 07:31
    Profile
  • MorphOS Developer
    geit
    Posts: 996 from 2004/9/23
    deka,
    Quote:

    Could you tell me, which app require more, than 1.5GB?


    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
  • »28.02.13 - 10:12
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4976 from 2009/1/28
    From: Delaware, USA
    @ Geit

    Sinner
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.02.13 - 11:04
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Crumb
    Posts: 730 from 2003/2/24
    From: aGaS & CUAZ Al...
    @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.
  • »28.02.13 - 11:12
    Profile Visit Website
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4976 from 2009/1/28
    From: Delaware, USA
    @ 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?
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.02.13 - 11:43
    Profile
  • MorphOS Developer
    geit
    Posts: 996 from 2004/9/23
    Crumb,
    Quote:

    what do you think about enabling the use of >1.5GB as some kind of ramdisk?


    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 ]
  • »28.02.13 - 12:36
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    deka
    Posts: 131 from 2013/2/12
    From: Hungary, Kecsk...
    @geit:
    Quote:

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

    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)
  • »28.02.13 - 13:12
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Zylesea
    Posts: 2039 from 2003/6/4
    geit,
    Quote:

    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.


    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.
    --
    http://www.via-altera.de

    Whenever you're sad just remember the world is 4.543 billion years old and you somehow managed to exist at the same time as David Bowie.
    ...and Matthias , my friend - RIP
  • »28.02.13 - 13:12
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11762 from 2003/5/22
    From: Germany
    > 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.
  • »28.02.13 - 13:19
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11762 from 2003/5/22
    From: Germany
    > 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 ;-)
  • »28.02.13 - 13:44
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11762 from 2003/5/22
    From: Germany
    > 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).
  • »28.02.13 - 14:21
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11762 from 2003/5/22
    From: Germany
    >> 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.
  • »28.02.13 - 14:45
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    deka
    Posts: 131 from 2013/2/12
    From: Hungary, Kecsk...
    I agreed with the quited line only... ;-)
  • »28.02.13 - 15:52
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4976 from 2009/1/28
    From: Delaware, USA
    Andreas_Wolf,
    Quote:

    Outside ABox, ABox compatibility doesn't matter ;-)


    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.02.13 - 19:07
    Profile