How to gain more programmers from outside sources?
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    > The change to x86/x64/ARM will suffer from the same problems: Memory limits, freezings, etc.

    Memory limits for MorphOS on x64 with 8 GiB RAM and more? How so? And memory protection will reduce/prevent OS freezes.
  • »24.08.15 - 13:22
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    deka
    Posts: 131 from 2013/2/12
    From: Hungary, Kecsk...
    Quote:

    Andreas_Wolf wrote:
    > The change to x86/x64/ARM will suffer from the same problems: Memory limits, freezings, etc.

    Memory limits for MorphOS on x64 with 8 GiB RAM and more? How so? And memory protection will reduce/prevent OS freezes.


    It is declared that an ABox never will see more, than 1.5 GB because of legacy compatibility....

    Quark kernel handles the PPC-s memory protection features (as I know). If an application starts to write to memory to random addresses, the result will be a freeze shortly. If the Quark could prevent this app to write to other ABoxes, then it could only freeze its parent ABox.

    I don't know is this possible or not...

    [ Edited by deka 24.08.2015 - 13:34 ]
  • »24.08.15 - 13:30
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4955 from 2009/1/28
    From: Delaware, USA
    Quote:

    amigadave wrote:
    Quote:

    Britelite wrote:
    Quote:

    amigadave wrote:

    So you are claiming that the videos showing the 68k core for FPGA running at a speed equal to a 200MHz 68000 CPU are fakes?


    A 200MHz 68000 is not particularly fast ;)




    Depends on what you are comparing it to. Compared to a 7MHz 68000, the 200MHz+ 68k FPGA core with some 68020 instructions added is fairly impressive. What if they can get it to run at 400MHz to 500MHz, or faster?

    When compared to my 2.7GHz G5 PowerMac tower, it is still slow, but much less difference than the wide gap between 7MHz and 2.7GHz.

    But I still think that it is interesting to see what can be run using a fast FPGA with the 68k Apollo core. It may be that if/when the Apollo accelerator card(s) are released, original Amiga hardware might be able to run a decent web browser, as well as productivity software (if any is ported or written from scratch) and more demanding games that were not previously possible, even on an Amiga with a 68060. The Apollo team has stated that they also plan to provide improved graphic capabilities, but I don't know exactly what they have in mind, and I am sure it won't compete with modern video cards. This is going way off topic, and I really don't want to speculate on what might happen if/when the Apollo core is widely available, but IMO, it is interesting to me and a lot of existing Amiga users.


    Hi David,
    I'm not trying to incite anyone's ire or call anyone a liar.
    Some of the last' 060s were capable of running at 75 to 100MHz.
    The '40 and' 60 cores are vastly superior to the original 68000, running circles around them at similar clock speeds.
    So, a 200KHz FPGA 68000 may not out perform an overclocked 68060.
    However, if we are willing to spend more for larger, faster FPGA AND we aim at a more competent core that will change.

    And I am glad to see the Apollo team actually releasing their work to the public.
    It lends them credibility that other projects have lacked.


    [ Edited by Jim 24.08.2015 - 14:07 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »24.08.15 - 13:36
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    >>> The change to x86/x64/ARM will suffer from the same problems:
    >>> Memory limits, freezings, etc.

    >> Memory limits for MorphOS on x64 with 8 GiB RAM and more? How so?
    >> And memory protection will reduce/prevent OS freezes.

    > It is declared that an ABox never will see more, than 1.5 GB because
    > of legacy compatibility....

    Sorry, it was not clear for me that you were referring to ABox in the quoted sentence about MorphOS on "x86/x64/ARM". According to MorphOS team members, MorphOS "NG" will not be about compatibility boxes but about a new OS with modern features and interfaces.
  • »24.08.15 - 13:56
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    > a 200KHz FPGA 68000 may not out perform an overclocked 68060.

    Yes, it certainly won't by far ;-)
  • »24.08.15 - 14:00
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    ppcamiga1
    Posts: 210 from 2015/8/23
    amigadave wrote:

    Quote:


    So you are claiming that the videos showing the 68k core for FPGA running at a speed equal to a 200MHz 68000 CPU are fakes?



    In 2008 when natami team first promise that natami will be in production
    in summer 2008 gunnar von boehn also present nice videos.
    We have now 2015 and gunnar von boehn still has nothing to sell.

    Quote:


    I think it is very harsh to call anyone a liar,



    gunnar von boehn and natami team has long history of false announcements
    about natami.
  • »24.08.15 - 17:05
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    ppcamiga1
    Posts: 210 from 2015/8/23
    amigadave wrote:
    Quote:


    It may be that if/when the Apollo accelerator card(s) are released, original Amiga hardware might be able to run a decent web browser, as well as productivity software (if any is ported or written from scratch) and more demanding games that were not previously possible, even on an Amiga with a 68060.



    To run decent browser You have to have something as fast as slowest sam.
    Which means something 20 times faster than 50 MHz 68060.
    200 MHz 68000 is simply 100 times slower.
  • »24.08.15 - 17:12
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2789 from 2006/3/21
    From: Northern Calif...
    Quote:

    Jim wrote:
    Hi David,
    I'm not trying to incite anyone's ire or call anyone a liar.
    Some of the last' 060s were capable of running at 75 to 100MHz.
    The '40 and' 60 cores are vastly superior to the original 68000, running circles around them at similar clock speeds.
    So, a 200KHz FPGA 68000 may not out perform an overclocked 68060.
    However, if we are willing to spend more for larger, faster FPGA AND we aim at a more competent core that will change.

    And I am glad to see the Apollo team actually releasing their work to the public.
    It lends them credibility that other projects have lacked.



    Hi Jim,

    I have no vested interest in the Apollo team's work, but I am hoping that it will be successful and breath some new life into the "Classic" Amiga segment of our community. Supposedly, though I can't provide a link to a video test, or benchmark results, there have already been test results which have exceeded 400MHz and instructions from the 68020 have already been added, but not all of them. The only reason I mentioned the 200MHz number, is because that is what I have seen videos of so far.

    If the 68k core can continue to improve, to the point of including all, or even just most of the functions of the 68020, or possibly the 68030, and just a few speed related features found in the 68040 and/or 68060, plus be put into newer, bigger, and faster FPGA chips, perhaps we could see performance that is several times faster than even an over clocked 68060. That is what I believe Gunnar is aiming for, something that can perhaps run as fast as a 200MHz to 400MHz 68060, or faster, but only in some aspects, probably not all instructions, or features. I just hope he and the others don't get burned out, or run into an obstacle they can't figure out how to overcome, so that they actually get some accelerator cards produced and out to the public.

    I do understand that Gunnar might have a bad habit of being over optimistic, and for making statements before he is really ready to show the results.

    I'll just sit back and wait for something good to show up. If it never comes, I still have my Classic systems, my several MorphOS systems, and my X1000 for running AmigaOS4.x, which I have not much hope for ever being much more than it is right now, which is not very good, IMHO. The X1000 is great, but I just don't have much confidence in Hyperion, and I also have severe doubts about anyone turning AmigaOS4.x into something even as good as MorphOS is right now.
    MorphOS - The best Next Gen Amiga choice.
  • »25.08.15 - 06:06
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    > I can't provide a link to a video test, or benchmark results

    Most of it can be found there: http://www.apollo-core.com/bringup/
  • »25.08.15 - 07:43
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4955 from 2009/1/28
    From: Delaware, USA
    Quote:

    amigadave wrote:

    ...I do understand that Gunnar might have a bad habit of being over optimistic, and for making statements before he is really ready to show the results.

    I'll just sit back and wait for something good to show up. If it never comes, I still have my Classic systems, my several MorphOS systems, and my X1000 for running AmigaOS4.x, which I have not much hope for ever being much more than it is right now, which is not very good, IMHO. The X1000 is great, but I just don't have much confidence in Hyperion, and I also have severe doubts about anyone turning AmigaOS4.x into something even as good as MorphOS is right now.


    Well Gunnar wasn't only person responsible for the hype, although he can get a little "overly enthusiastic".
    And I don't doubt the videos content or the end goals of the project.

    And yes, a return to focus on the 68K is nice. It was my personal favorite in the early days.

    As to NG, well we've both placed our faith in people that provide more results and less talk. Besides I genuinely trust and like the people in this community.
    "Never attribute to malice what can more readily explained by incompetence"
  • »25.08.15 - 12:35
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    In_Correct
    Posts: 244 from 2012/10/14
    From: DFW, TX, USA
    Target Hardware should be a device that attracts developers. The Pi series attracts developers.

    Since MorphOS wants to port to X64, is there a X64 device that attracts developers?
    :-) I Support Quark Microkernel. :-D
  • »28.08.15 - 00:14
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2789 from 2006/3/21
    From: Northern Calif...
    Quote:

    In_Correct wrote:
    Target Hardware should be a device that attracts developers. The Pi series attracts developers.

    Since MorphOS wants to port to X64, is there a X64 device that attracts developers?


    I think it is obvious that all (or nearly all) developers are already using and coding on x64 hardware, even many of the ones that are also developing for ARM are probably doing it on high end x64 hardware and cross compiling.

    x64 is everywhere, so all the MorphOS Dev. Team needs to do is make wise choices when they decide what specific x64 components they wish to support.

    A-Eon has chosen an embedded PPC that is supposed to have at least 5 years of lifespan. I don't know if it is possible to find any x64 components and CPU that have more than a 1 or 2 year guaranteed lifespan, but hopefully the MorphOS Dev. Team will resolve that problem and find system components that will still be widely available long enough for them to complete the porting of MorphOS to them and still have systems using those components and CPU available for the MorphOS users to purchase.

    I don't see it as a huge problem anyway, as I have no problem buying hardware second hand, if it is no longer available brand new from any resellers by the time the MorphOS port is completed.

    With any luck, the MorphOS Dev. Team will be able to choose a family of CPU's and motherboard components that they can support and without too much difficulty make upgrades to newer versions, in the same time frame as the life cycle for new parts. In that way, we should be able to buy new hardware, or at the least, hardware that is only one generation behind the most current versions available. That will be much better than being over a decade behind current hardware, like we are now.

    I'm not sure if I will still be interested in MorphOS NG, once it has lost all legacy compatibility with the Amiga, but I probably will be, and having SMP and Memory Protection, as well as other modern support features, will make it interesting enough to check out regardless of any other considerations.
    MorphOS - The best Next Gen Amiga choice.
  • »28.08.15 - 07:23
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    > A-Eon has chosen an embedded PPC that is supposed to have at least 5 years of lifespan.

    It's 10 years from product launch for the QorIQ P5 chips. This means availability from Freescale is guaranteed until June 2020 for the P5020 and until May 2022 for the P5040.

    > I don't know if it is possible to find any x64 components and CPU that have more
    > than a 1 or 2 year guaranteed lifespan

    Yes, of course it is.
  • »28.08.15 - 07:50
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    deka
    Posts: 131 from 2013/2/12
    From: Hungary, Kecsk...
    I think, it would be a far bigger gain for MOS to have new features/tools/programs on PPC, than a platform change (even with higher speed). I just cannot see, which application needs more CPU/memory, where a G5 isn't sufficient. If nothing changes, the memory limit remains the current 1.5GB, even if you install it on the most powerful PC. Also a huge limit is the system's vulnerability. I think, these things should be first resolved, and then change if the limits are really approached.
    I afraid, we are far from this.
  • »28.08.15 - 08:27
    Profile
  • MorphOS Developer
    jacadcaps
    Posts: 2509 from 2003/3/5
    From: Canada
    Quote:

    deka wrote:
    If nothing changes, the memory limit remains the current 1.5GB, even if you install it on the most powerful PC.


    Nope. New arch -> no reason to keep the 1.5GB limit since old software isn't compatible anyway. No reason to stay 32bit either...
  • »28.08.15 - 09:00
    Profile Visit Website
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    deka
    Posts: 131 from 2013/2/12
    From: Hungary, Kecsk...
    Quote:

    jacadcaps wrote:
    Quote:

    deka wrote:
    If nothing changes, the memory limit remains the current 1.5GB, even if you install it on the most powerful PC.


    Nope. New arch -> no reason to keep the 1.5GB limit since old software isn't compatible anyway. No reason to stay 32bit either...


    You mean, if you do the platform change, MOS will drop ABox and loose the legacy compatibility?
  • »28.08.15 - 09:11
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    takemehomegrandma
    Posts: 2698 from 2003/2/24
    Quote:

    deka wrote:

    You mean, if you do the platform change, MOS will drop ABox and loose the legacy compatibility?


    Legacy applications will have to run in a box.
    MorphOS is Amiga done right! :-)
    MorphOS NG will be AROS done right! :-)
  • »28.08.15 - 09:59
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    > if you do the platform change, MOS will drop ABox and loose the legacy compatibility?

    That's what has been said for years by the MorphOS team, and also numerous times in this thread.
  • »28.08.15 - 10:10
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4955 from 2009/1/28
    From: Delaware, USA
    Quote:

    takemehomegrandma wrote:
    Quote:

    deka wrote:

    You mean, if you do the platform change, MOS will drop ABox and loose the legacy compatibility?


    Legacy applications will have to run in a box.


    The problem being that it appears we will not get that box after the move to X64.
    So, I'd side with Deka in enhancing our current system.

    32 bit gives us access to 4GB, not 1.5GB.
    The 1.5GB limit is a function of AOS' 31 bit addressing (and MorphOS actually uses 2GB, the higher memory is used by the OS).
    So even if 64bit and 32bit can't coexist (and I think its probable that they can), we have 2GBs of unused memory.
    Also, on some of our systems we have an extra processor and in future systems we may have up to three additional core (further, if we jumped to an e6500 cored cpu we could have up to eleven extra core or 23 additional threads).
    So some form of SMP that reserves one core/thread for legacy compatibility could be created.

    The question right now is will this be allowed.
    Not even will this be supported by the developers.
    Because if we had adequate documentation of our current OS (including info on kernel calls and all system modules and tools) we could consider doing it ourselves.
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.08.15 - 13:10
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    > 32 bit gives us access to 4GB, not 1.5GB. The 1.5GB limit is a function of AOS' 31 bit
    > addressing (and MorphOS actually uses 2GB, the higher memory is used by the OS).

    The address space between 1.5 and 2.0 GiB is used to map and access the memory of on-board and expansion hardware. That's why the OS can't use it as system RAM and it's also why 32-bit addressing would give us access to 3.0 to 3.5 GiB system RAM instead of the entire 4 GiB.
  • »28.08.15 - 13:53
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4955 from 2009/1/28
    From: Delaware, USA
    Quote:

    Andreas_Wolf wrote:
    > 32 bit gives us access to 4GB, not 1.5GB. The 1.5GB limit is a function of AOS' 31 bit
    > addressing (and MorphOS actually uses 2GB, the higher memory is used by the OS).

    The address space between 1.5 and 2.0 GiB is used to map and access the memory of on-board and expansion hardware. That's why the OS can't use it as system RAM and it's also why 32-bit addressing would give us access to 3.0 to 3.5 GiB system RAM instead of the entire 4 GiB.


    True, but I'm not even considering moving mapped I/O (which could be placed anywhere in the 32bit map).
    I'm just stating that on some systems we have 2GB of memory space, even under 32 bit access, that could be used by other processes.
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.08.15 - 16:22
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    takemehomegrandma
    Posts: 2698 from 2003/2/24
    Quote:

    Jim wrote:
    Quote:

    takemehomegrandma wrote:
    Quote:

    deka wrote:

    You mean, if you do the platform change, MOS will drop ABox and loose the legacy compatibility?


    Legacy applications will have to run in a box.


    The problem being that it appears we will not get that box after the move to X64.



    I said a box, not "A-box". It's pointless to discuss what that box will be, how it will be implemented, and what it will be called, based on speculations only.

    UAE is a "box" BTW, and IMHO the way AROS x86 handles legacy support would be quite sufficient in an operating system that has this changed focus from the current.
    MorphOS is Amiga done right! :-)
    MorphOS NG will be AROS done right! :-)
  • »28.08.15 - 16:41
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    boot_wb
    Posts: 874 from 2007/4/9
    From: Kingston upon ...
    Quote:

    Jim wrote:
    So, I'd side with Deka in enhancing our current system.

    [..]4GB, not 1.5GB [..] if 64bit and 32bit can't coexist (and I think its probable that they can) [..] extra processor [..] up to eleven extra core or 23 additional threads) [..] some form of SMP that reserves one core/thread for legacy compatibility could be created.

    The question right now is will this be allowed.
    Not even will this be supported by the developers.
    Because if we had adequate documentation of our current OS (including info on kernel calls and all system modules and tools) we could consider doing it ourselves.




    Isn't that why AROS was created - open source research OS open for everyone to hack/experiment/develop?

    [ Edited by boot_wb 28.08.2015 - 16:33 ]
    www.hullchimneyservices.co.uk

    UI: Powerbook 5,6 (1.67GHz, 128MB VRam): OS3.1, OSX 10.5.8
    HTPC: Mac Mini G4 (1,5GHz, 64MB VRam): OS3.1 (ZVNC)
    Audiophile: Efika 5200b (SB Audigy): OS3.1 (VNC + Virtual Monitor)

    Windows free since 2011!
  • »28.08.15 - 17:27
    Profile Visit Website
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4955 from 2009/1/28
    From: Delaware, USA
    Quote:

    takemehomegrandma wrote:
    Quote:

    Jim wrote:
    Quote:

    takemehomegrandma wrote:
    Quote:

    deka wrote:

    You mean, if you do the platform change, MOS will drop ABox and loose the legacy compatibility?


    Legacy applications will have to run in a box.


    The problem being that it appears we will not get that box after the move to X64.



    I said a box, not "A-box". It's pointless to discuss what that box will be, how it will be implemented, and what it will be called, based on speculations only.

    UAE is a "box" BTW, and IMHO the way AROS x86 handles legacy support would be quite sufficient in an operating system that has this changed focus from the current.


    Can't quite agree that UAE is a box, but I see your point.
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.08.15 - 17:27
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 11444 from 2003/5/22
    From: Germany
    >> The address space between 1.5 and 2.0 GiB is used to map and access the memory
    >> of on-board and expansion hardware. That's why the OS can't use it as system RAM
    >> and it's also why 32-bit addressing would give us access to 3.0 to 3.5 GiB
    >> system RAM instead of the entire 4 GiB.

    > True, but I'm not even considering moving mapped I/O (which could be placed anywhere
    > in the 32bit map).

    Huh? Where would you place the mapped I/O on a 32-bit system if not in the upper address space between 3.0/3.5 GiB and 4.0 GiB? I don't think there are options.
  • »28.08.15 - 17:38
    Profile