> 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.

Quote:

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 ]

Quote:

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 ]

>>> 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.

> a 200KHz FPGA 68000 may not out perform an overclocked 68060.

Yes, it certainly won't by far ;-)

amigadave wrote:

Quote:

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:

gunnar von boehn and natami team has long history of false announcements
about natami.

amigadave wrote:
Quote:

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.

Quote:

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.

> 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/

Quote:

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.

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?

Quote:

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.

> 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.

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.

Quote:

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

Quote:

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

Quote:

Legacy applications will have to run in a box.

> 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.

Quote:

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.

> 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.

Quote:

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.

Quote:

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.

Quote:

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 ]

Quote:

Can't quite agree that UAE is a box, but I see your point.

>> 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.