@pavlor

Quote:

pavlor wrote: @cdimauro Quote: because all the things that I cited can be internally and transparently handled by the o.s., freeing memory. Things like RAM and RAD disk? Surprising progress.

In fact, that's not progress. I never stated this. It's just surviving into a too much restricted world.

What's not clear to you about this:

"64 bit processors existed from a LOOOONG time: just use one of them instead of emulating an 8-bit processor."

?
Quote:

Quote: AROS is already available a real 64-bit platform. Nobody is using it, guess why...

That's trolling, pavlor, because it's something that you can only dream, so you spread FUD against it. This well know fable perfectly applies.

Despite your pure lies, there are several users AND developers which already use 64-bit AROS. That's the future, and we are well aware of it. Take a look at AROS-exec.
Quote:

Quote: MorphOS will take the same direction. In 2050, day after Hyperion introduces SMP.

The MorphOS team did a GREAT work totally starting from scratch, writing the source code from zero, and actually I think they offer to best user experience.

On the other hand, Hyperion inherited the full Amiga o.s. 3.1 sources (which were tested by millions of people in over 20 years), rewrote a part, not even completed the port (still some pieces are 68K), and continuously patching it, showing absolutely no clue about a real, radical change. The only vision for the future is: patch to survive.

So, I think that there are very good chances that when MorphOS will run on x64, OS4 is still swimming in the pool of patches that Hyperion created, with the ridiculous 2GB limit pending too. Enjoy...

@fishy_fis

Quote:

There are no "officially supported" machines

Exactly. There are no "officially supported machines" with AROS, which makes the entire comparison rather difficult because you have an OS with a specified fixed number of continously tested and confirmed-to-work systems on one side and then another OS with the potential to run on many more systems in theory but very little confirmed information about successes or failures from testers in practice.

Quote:

There's about 2 dozen systems between ASUS eeepc and AspireOnes alone. Literally hundreds of systems with a p35/ich7/8/9/10 combo chipset (very well supported). (...) This is a few hundred options already, without even looking or scratching the surface.

Without better documentation and consistent testing, It is a matter of "tested to work on this hardware" vs. "expected to work on this hardware".

Also, when you refer to laptops specifically, end users tend to have higher expectations regarding software support as well. Chain-Q summarized it earler. Battery meters, proper touchpad support, etc.

Quote:

I must agree though that the information regarding hardware support is a bit all over the place. I might try to find time to help with tidying it up a bit myself actually. Given my experience with AROS and the volume of hardware I come across (my own and otherwise) I'm probably a reasonable choice for such an endeavour.

Any improvements would be welcome.

@cdimauro

Quote:

In fact, that's not progress.

At least here we agree.

Quote:

: just use one of them instead of emulating an 8-bit processor."

Isn´t it exactly that, what Hyperion did in FE?

Quote:

That's trolling, pavlor, because it's something that you can only dream, so you spread FUD against it.

I can feel your anger...

These builds are based ond sources of the new ABI. They are not compatible with existing AROS distributions or with the AROS software available from The AROS Archives or Aminet. (About ABIv1 builds)

This exactly the same problem other Amiga-like OSs face: COMPATIBILITY

Quote:

The MorphOS team did a GREAT work totally starting from scratch

True.

Quote:

and continuously patching it, showing absolutely no clue about a real, radical change. The only vision for the future is: patch to survive.

Call me conservative, but, I always prefered evolution instead of revolution.

Quote:

Enjoy...

Thanks!

@terminills

Quote:

I use the 64 bit branch :P

Well, sorry then...

@pavlor

I would also like to know why noone is using Aros X64?

Please share your deep inside knowledge of Aros

@OlafS25

Quote:

I would also like to know why noone is using Aros X64?

See above.

@pavlor

yes it is easier to stay on 32bit than to change to 64bit because you cannot simply recompile for it but sources have to be changed but you have to start somewhere. Or do you want to stay forever in the 90s?

@OlafS25

Quote:

Or do you want to stay forever in the 90s?

Quite funny question from someone behind great AROS 68k distribution.

@pavlor

Quite ironic to drag an AW 'MorphOS on x86' thread OT in the direction of 68K and AROS.

Entertaining if you're into that sort of thing I suppose.

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

@pavlor

OT

that I like 68k does not mean I am blind against the rest of the world

there is another reason why I even as 68k user also support the other hardware platforms.... Aros is source-compatible meaning you can develop software on one platform and compile it for the others and it works there too, so you develop for X86 and then it can also compiled and run on ARM or 68k. 64bit is of course different but there is a chance to get more developer with it and this is a chance to get more software on 68k either. So being for one does not mean being against the others.

Last edited by OlafS25 on 23-May-2015 at 11:20 AM.

@Boot_WB

Quote:

Entertaining if you're into that sort of thing I suppose.

If you really read my above posts, you will understand my main concern was compatibility with current software. That is problem for 64bit AROS and will be also for "x86" MorphOS.

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: [quote]: just use one of them instead of emulating an 8-bit processor." Isn´t it exactly that, what Hyperion did in FE?

I don't think so. Even a 32-bit processor can access more than 4GB of physical memory. For example, Intel introduced the famous PAE with the PentiumPro (on 1995), which let to access up to 64GB of memory. PowerPCs has a similar mechanism, called OEA.

So, what Hyperion most probably did is using such processor feature to map portions of >2GB physical memory to some (logical) memory pages of the first 2GB address space, using the allocated "handle" which tracks that mapping.

This also means that there's absolutely no "64-bit support". It was only a marketing to illude OS4 users that "we give some 64-bit support".

Quote:

Quote: That's trolling, pavlor, because it's something that you can only dream, so you spread FUD against it. I can feel your anger...

Not anger, but a disgusted by such clear lies.
Quote:

These builds are based ond sources of the new ABI. They are not compatible with existing AROS distributions or with the AROS software available from The AROS Archives or Aminet. (About ABIv1 builds) This exactly the same problem other Amiga-like OSs face: COMPATIBILITY

It shows that, again, you don't know what you are talking about. I report the AROS goals, which are well known even before that the project was started:

"Is binary compatible on Amiga and source compatible on any other hardware;"

What does it means? It's quite simple: if you generate a binary for a specific hardware (architecture, to be more precise), you cannot expect that it works to another architecture (supported by AROS).

AROS supports several architectures: x86, x86-64, 68K, PowerPC, and now even ARM.

What happens with the ARM port (just to make a different example)? Am I allowed to take any binary which you already find around (see your text) and run on such AROS port? The answer is clearly NO. Because you need a compiled stuff specific for the ARM port.

So, to support ANY AROS architecture, the existing AROS software has to be compiled FOR EVERY architecture.

That was, and IS, clear for AROS, since the foundation.

It means that the AROS software has to be specifically compiled for x86-64. Some is already available, but of course the great major is not.

What's the problem with that? Binary compatibility was never a problem/issue with AROS, unless for the 68K port.
Quote:

Quote: and continuously patching it, showing absolutely no clue about a real, radical change. The only vision for the future is: patch to survive. Call me conservative, but, I always prefered evolution instead of revolution.

I don't call "evolution" using a patched o.s. of 30 years ago. I call it necro-computing...

@pavlor

Quote:

pavlor wrote: @Boot_WB Quote: Entertaining if you're into that sort of thing I suppose. If you really read my above posts, you will understand my main concern was compatibility with current software. That is problem for 64bit AROS and will be also for "x86" MorphOS.

It's not a problem for AROS and the same will happen for the x64 port of MorphOS.

Software will be recompiled and make fully use of the new architecture, instead of using an horrible bank-switching technique for gaining some more memory.

BTW, to support such anti-Amiga hack you have to SPECIFICALLY WRITE software, and developers has to think about what part and how to change their code to have some advantage. It's not a simple effort. And it anyway requires a recompilation of the software.

So, to recap.

To support the OS4's banks-switching you need to:
- analyze your code and find all parts that has to be changed;
- change them;
- compile the new version -> generate NEW BINARIES;
- make a lot of tests to make sure that the above changes work correctly.

To support >2GB memory on AROS and MorphOS x64 you need to:
- compile the new version -> generate NEW BINARIES;
- make some tests because if the code WAS (read: past form) NOT written correctly it might manifest some bug due to the different pointers size.

So, your concern about "lost compatibility" doesn't make sense at all, since OS4 has MUCH MORE sever issues with handling memory >2GB.

@cdimauro

Quote:

For example, Intel introduced the famous PAE with the PentiumPro (on 1995), which let to access up to 64GB of memory. This also means that there's absolutely no "64-bit support". It was only a marketing to illude OS4 users that "we give some 64-bit support".

PAE is classical example how 32 bit OS can access memory above 4 GB. I see nothing wrong with similar approach.

Quote:

Not anger, but a disgusted by such clear lies.

Such strong words... from you, this is an honor.

Quote:

What's the problem with that? Binary compatibility was never a problem/issue with AROS, unless for the 68K port.

I fear your understanding is quite limited here. Lack of binary compatibility with most of current AROS applications is primary reason limiting grow of AROS 64bit user base.

Quote:

Software will be recompiled and make fully use of the new architecture

Well, this way you get MPlayer, Odyssey and few other applications still actively developed. What about majority of other MorphOS (or even 68k) software?

Quote:

So, your concern about "lost compatibility" doesn't make sense at all, since OS4 has MUCH MORE sever issues with handling memory >2GB.

As MorphOS has no 4+ GB support yet and AROS 64 bit is not compatible with most software, I find your concern for solution introduced in FE amusing.

Today, both AmigaOS and MorphOS support up to 1.5 GB RAM for all applications (in 32 bit AROS it is cca 3.5 GB). In AmigaOS, new applications can use RAM above 4 GB limit. It is bonus, not issue.

Quote:

I call it necro-computing...

Necro-computing... sounds good!

@pavlor

The MorphOS devs will drop compatibility and use UAE when they make a ISA change (I read that from one of the MorphOS devs). Similar to what is the case on Aros. You cannot get modern features and binary compatibility to 68k at the same time.

Regarding Aros on X64 I personal cannot make any comments about how easy it is to port to X64. It works between X86, ARM and (at least to a certain degree) 68k. There is a Aros X64 version of Antiryad so it is definitely possible.

Last edited by OlafS25 on 23-May-2015 at 01:49 PM.

@OlafS25

Quote:

The MorphOS devs will drop compatibility and use UAE when they make a ISA change

That would be sensible approach, but not much satisfying. Price for progress.

Quote:

You cannot get modern features and binary compatibility to 68k at the same time.

Why not create new "A-Box" for old applications working in parallel with new 64bit applications? Eg. 64 bit Windows is able to run most 32 bit software (including really old titles), why not try similar solution for NG MorphOS (or AmigaOS, or AROS)?

@cdimauro

Quote:

To support >2GB memory on AROS and MorphOS x64 you need to:

Actually to support more than 2Gig under AROS you need to:

- Buy more than 2 gig RAM
- Plug more than 2 gig RAM into computer



Seriously though, even 32bit AROS has had support for 4Gig for as long as I remember. This 4gig includes VRAM, etc. though (like "normal" 32bit addressing).

Last edited by fishy_fis on 23-May-2015 at 02:41 PM.

Quote:

I don't call "evolution" using a patched o.s. of 30 years ago. I call it necro-computing...

Isn't patching what AROS is doing ? AROS was born by reimplementing AmigaOS 3.1 API. And "modern" features are being added from existing source code by adding #ifdef.. That's not really what I call a clean break.. See:http://repo.or.cz/w/AROS.git/blobdiff/1ad6428ad2698d10a6df7fa855352e09410712e5..5861eee512dd010463148343cb9f250257dc7555:/rom/exec/exec_util.c

Right now, no Amiga style OS has been doing a clean and modern break from this 30 years old legacy (at least no move that is public). Not OS4, not AROS, not MorphOS. Not having compatibility doesn't mean it's a clean break.

WinXP wasn't born by patching a DOS kernel. MacOSX wasn't created by adding #ifdef MacOS_SMP. A modern AmigaOS won't appear the same way...

Now, the subject was MorphOS going x86. I don't see what AROS has to do with it. It is already running on x86. Fine. But then what ?

_________________
http://www.warpdesign.fr/

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: For example, Intel introduced the famous PAE with the PentiumPro (on 1995), which let to access up to 64GB of memory. This also means that there's absolutely no "64-bit support". It was only a marketing to illude OS4 users that "we give some 64-bit support". PAE is classical example how 32 bit OS can access memory above 4 GB. I see nothing wrong with similar approach.

That's because you are not a coder and it's clear that you cannot understand all problems that such trick brings.

In fact, you completely overcome this:

"- analyze your code and find all parts that has to be changed;
- change them;
- make a lot of tests to make sure that the above changes work correctly."

which clearly shows that you, again, don't know what we are talking about.
Quote:

Quote: Not anger, but a disgusted by such clear lies. Such strong words... from you, this is an honor.

Strong words? Well, you've written pure lies. So, yes, it's an honor to have shown that you're a lier. But from your statements I think you'll like it, right? Some lies are good prices to pay for defending at any cost your OS4 faith...
Quote:

Quote: What's the problem with that? Binary compatibility was never a problem/issue with AROS, unless for the 68K port. I fear your understanding is quite limited here. Lack of binary compatibility with most of current AROS applications is primary reason limiting grow of AROS 64bit user base.

They will be compiled. I don't see the problem, since this is and was the situation well before that the x86-64 port was made, with other architectures.

Currently x86-x64 is rare, so that's why there are few programs recompiled for it, but it will change (again: take a look at AROS-Exec). AROS users and developers are perfectly aware of it, we discussed it, and the directly is pretty clear.
Quote:

Quote: Software will be recompiled and make fully use of the new architecture Well, this way you get MPlayer, Odyssey and few other applications still actively developed. What about majority of other MorphOS (or even 68k) software?

68K apps already run using UAE with good tools like Janus/Amibridge. It'll be the same with MorphOS.

For the normal, native applications, they will be recompiled, as I already stated. There's no interest and it's absolutely time and resource wast trying to find a solution to run the old PowerPC applications. That's for MorphOS, because I already shown you one of the fundamental AROS's goal, which is found on source-level compatibility.

New/native applications are usually still maintained by developers, so they are not "lost", and what's normally expected is that they will recompile them for the new platform.

I think that the MorphOS team already made such evaluations, a knows that it'll happen.
Quote:

Quote: So, your concern about "lost compatibility" doesn't make sense at all, since OS4 has MUCH MORE sever issues with handling memory >2GB. As MorphOS has no 4+ GB support yet and AROS 64 bit is not compatible with most software, I find your concern for solution introduced in FE amusing.

Well, you continue to do not understand what's the real picture.

First, how do you know that AROS/x64 is not compatible with most software? Have you tried yourself to compile all existing AROS applications for it, and saw that they are failing or the binaries are not working? Because, again, the problem is not that AROS/x64 is incompatible with the existing apps, but they were NOT YET compiled for it.

Second, the solution introduced by OS4 is already incompatible, BY DEFINITION, with all existing software, because IT REQUIRES A LOT OF SOURCE-CODE CHANGES to make it work.

Sorry for the capitals, but I don't how to explain it in another way. It seems that you don't understand or, much worse, you do NOT want to understand the ENORMOUS differences between a recompilation to get new binaries and a (lot of) source change(s) to support NEW APIs to enable the infamous bank-switching.

If you aren't a coder, it can explains a lot of things and it justifies your writing. If you are a code, well, ... no comment.
Quote:

Today, both AmigaOS and MorphOS support up to 1.5 GB RAM for all applications (in 32 bit AROS it is cca 3.5 GB). In AmigaOS, new applications can use RAM above 4 GB limit. It is bonus, not issue.

See above: new applications WITH SOURCE-CODE CHANGES will use more ram. A simple recompilation will NOT work, whereas usually* it WILL with AROS/x64 and on MorphOS x64*.

Again, I don't know how to explain it in another way.

*usually = if the code is well written and do not make wrong assumption or have bad coding practices. But that doesn't strictly apply to our discussion: it's a general thing.


@pavlor

Quote:

pavlor wrote: @OlafS25 Quote: The MorphOS devs will drop compatibility and use UAE when they make a ISA change That would be sensible approach, but not much satisfying. Price for progress.

Progress = new, modern architecture, with anachronistic limits removed and old 68K software encapsulated to sandboxes to greatly limit their impact on the native/host o.s..

Unless you like the idea that a 68K app can hang your whole system. Ah, yes: it's progress!
Quote:

Quote: You cannot get modern features and binary compatibility to 68k at the same time. Why not create new "A-Box" for old applications working in parallel with new 64bit applications? Eg. 64 bit Windows is able to run most 32 bit software (including really old titles), why not try similar solution for NG MorphOS (or AmigaOS, or AROS)?

I already discussed it on another thread some time ago. It was due to a bad o.s. design. The Amiga o.s. publicly exposed its structures instead of using "opaque" structures to exchange data with applications.

That's the reason why compatibility breaks when:
- switching from 32 to 64-bit;
- enabling memory protection;
- enabling resource tracking;
- enabling SMP;
- changing endianess.

The Amiga o.s. was quickly written, as we well know, but that lead to a catastrophic design. And we're still paying it after 30 (THIRTY!) years.

Now take a look at other o.ses which introduced all that stuff, and see the common pattern: they do NOT public internal data. They provide opaque structure and ad hoc APIs to get or set "sensible" information.

That's why Windows can still execute 16-bit (not in 64-bit mode, but that's ONLY because in this mode it's the processor, not the o.s., which prevents 16-bit code execution). That's why Windows 9x routed all Win32 API to it's internal Win16 subsystem, whereas Windows NT made the opposite: the opaque APIs are so well defined that you can make such (apparently) weird things.

I hope that it's clear now.

P.S. Sorry, not time to correct mistakes.

@cdimauro

Quote:

which clearly shows that you, again, don't know what we are talking about.

Quote:

you've written pure lies. So, yes, it's an honor to have shown that you're a lier. But from your statements I think you'll like it, right? Some lies are good prices to pay for defending at any cost your OS4 faith...

Again, thanks for you kind words.

Quote:

Have you tried yourself to compile all existing AROS applications for it,

Good joke!

On the other hand... I would be revered as saint by AROS community for such deed.

Quote:

whereas usually* it WILL with AROS/x64 and on MorphOS x64*.

This is exactly, where diffrence of our opinions is most visible:
You expect most of current software will be recompiled for new OS.
I think this will be case of only small fraction of applications, maintaining compatibility and addiding new features step by step (patching as you call it :- ) is only viable way.

Quote:

That's the reason why compatibility breaks when:

Sure, sure. However, new "A-box" could be separated from new applications with only some sensible links (clipboard, same look, same integration in desktop). Entire PowerPC version of "classic" MorphOS could run in such sandbox. As this thread is about distant future such dreaming about features is permissible...