MorphOS ahead of AROS?

[bloodline]

ARM is bi-endian meaning it can be switched. NO i'm not making a joke...

IIRC most modern ARM cores only support Little Endian mode now, it wasn't a very used feature and I'm sure it is easier to interface with devices in little endian due to the ubiquity of x86.

[bbond007]

IIRC most modern ARM cores only support Little Endian mode now, it wasn't a very used feature and I'm sure it is easier to interface with devices in little endian due to the ubiquity of x86.

even in the data? maybe just code or address...

[XDelusion]

Here's a question, could some sort of FPGA based USB 3 or PCI expansion board be created to substitute for the lack of the classic chip set on future MorphOS hardware (in theory).

If possible, AROS and OS 4 could benefit from this as well.

[Iggy]

And while I too can see a day when we might need an ISA change, right now MorphOS is doing fine using the current PPC hardware supported.
Yeah, I'd like to have G5 support, but a 1.5GHz G4 performs pretty good. (and its really cheap).

I''m about to move from my 1.53GHz accelerated Quicksilver to a newer MDD (which I'll also overclock), I've replaced my R200 video card with an R300 (which should soon have 3D support), and my other cards will move right over  (USB2.0, SBLive).
So, for a fraction of the cost, I've got a system that performs better then a SAM (almost as fast as an X1000).

[XDelusion]

Nice nice nice!!!
What's your bus speed?

[smerf]

Nice nice nice!!!
What's your bus speed?

Hi,

My bus speed is a little bit slower than an 18 wheel truck traveling on the interstates, this is usually around 70 mph.

smerf

[XDelusion]

Hi,

My bus speed is a little bit slower than an 18 wheel truck traveling on the interstates, this is usually around 70 mph.

smerf

VW?

[Iggy]

Nice nice nice!!!
What's your bus speed?

Currently 133MHz, but as of next Monday 167MHz.
I'm also sitting on a couple of R400 based cards that have been modified to work in a G4 Mac.

[takemehomegrandma]

IIRC most modern ARM cores only support Little Endian mode now, it wasn't a very used feature and I'm sure it is easier to interface with devices in little endian due to the ubiquity of x86.

even in the data? maybe just code or address...

It's true that ARM is "bi-endian", at least in some "higher/application" level sense (and so are some PPC chips AFAIK), even modern ARM cores:
http://en.wikipedia.org/wiki/Comparison_of_CPU_architectures

However, this has been debated many times over at morphzone.org (nestled into those very long threads that literary goes on for years, where it's impossible to find it now, at least I have trouble, but I found this!), and the ARM was developed as little endian from the beginning, and it seems it still operates like this *internally*:
 
"ARM doesn't support Big Endian in anything but a bullet-point feature sense. The same is true of PowerPC processors which supposedly support Little Endian operation. The basic promise made in supporting these features is that it reorders bus transactions so they fit the right data format - memory is laid out in Big Endian, but when you load it into a register, it is flipped automatically and in the register on your Little Endian processor, you have Little Endian data. On PowerPC, you can fudge this manually without changing modes at all if you know the data format ahead of time (stwbrx, lwbrx). I'm not sure what the equivalent is on ARM.. maybe it doesn't have it, maybe it does. Instruction opcodes are still Little Endian in ARM whatever mode it's in. Internal registers and devices are all Little Endian. All that changes is how it routes data from memory into the cache and then the register. It is a limited subset. The SOLE reason for these features is because both ARM and PowerPC targets can and do run as device targets (e.g. on a PCI bus with another host processor doing the control) and they need to be able to interoperate with those buses. It does not magically turn your system into a Other Endian chip.
...

However absolutely NONE of this is relevant to MorphOS. MorphOS is for all practicality endian-independent - the only reason it gets thorny is trying to mimic PowerPC and/or m68k operation. So, the solution is.. drop those things in the trash where they belong. MorphOS has plenty of developer support and a huge amount of open-source software out there that can simply be recompiled. AROS is proof positive of this - it runs on x86 AND PowerPC, and it certainly does not run the PPC in little endian mode."
http://www.morphzone.org/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6268&start=54

All in all, I think this might cause troubles when trying to run old/existing 68k binaries ("translated" of course) in "the MorphOS way", yes?

(These things makes me dizzy, and I won't even pretend to understand them... :lol:)

[psxphill]

combining datatypes (or other components) is certainly not possible. Only if you could use 68k multiview from Aros X86 as preference (instead of the X86 version). But I do not know if that is possble.

Yoi don't think it could auto generating a PPC proxy datatype that communicates with the 68k datatype running in UAE? I thought the API was simple and well defined enough for that. You'd need a unified set of paths, but that again should be possible without having to configure it.

[warpdesign]

So, the solution is.. drop those things in the trash where they belong. MorphOS has plenty of developer support and a huge amount of open-source software out there that can simply be recompiled.

Well said. I don't get why we are even talking about custom chips, endianess,... All these belong to the past!

[spookyx]

Just my 2 cents......  I like winuae better than ether of these  

[Jupp3]

I didnt mean it too seriously Wondering how Mesa and Gallium3D in AROS would compare with TinyGL/Goa in MorphOS.

As I see it, TinyGL might be faster (at least in some cases) but Gallium3D is way more complete.

Don't have any experience with Gallium3D, but if I had to mention 2 major things that Gallium3D has (and TinyGL doesn't), they would be:
1)VBO (Vertex Buffer Object) support.
Instead of sending mesh data over (relatively slow) memory bus each time drawn, the data is uploaded to gfx ram (whenever it's initialized / changed) and drawn from there. According to my tests, that can even achieve 5x speedup. Basically it "adds a few functions around what you have with vertex arrays", so it's (relatively) easy to #ifdef for tinygl compatibility.
Should be relatively easy to implement in TinyGL too, at least compared to:

2)Shaders.
With shaders the coder can have (almost) total control what happens with vertices when given to OpenGL, and how the pixels will get their final color. Includes a C/C++-like language that's compiled when the program is ran (so the same binary will work on different gfx cards). This is totally different way to code for OpenGL, when compared to fixed function pipeline (which TinyGL uses)

OpenGL ES2 doesn't have any fixed function pipeline (Which ES1 was based on), and the entire fixed function pipeline was also deprecated in OpenGL 3.0 (and removed from 3.1, current version being 4.2).

While the fixed function pipeline will likely never be removed from "desktop implementations", more and more code will be written using shaders instead, as that's the "current" way of doing things.

In addition, TinyGL is also missing several "minor" features, such as color index mode and stipple support (both of which are almost totally useless, and also deprecated) - occassionally you might find some OpenGL game that uses some exotic functionality that TinyGL is missing, or just isn't working as expected.

[Tripitaka]

Just my 2 cents......  I like winuae better than ether of these  

That's your choice. It's good to have choice and it's great that your happy with UAE. Maybe you'll get tempted by a Natami when it's ready and make the move over to hardware. Maybe the Natami super AGA will one day also be available within UAE. Either way, your not going past OS3.9 with it. MOS on the other hand can run a lot of the same software as OS4. I would like to see MOS for SAM, classic PPC, A1 and X1000 myself, but that's another story.

[OlafS3]

There are also Amikit (updated) and AmigaSys with countless addons and software.

[Digiman]

Indeed it is. Far less crashes, a much better method at backwards compatability, MUI just works, USB works (including writing to NTFS), the GUI (Ambient) is AMAZING!!!

I think the only thing AROS has that is fully worth mention is the 3DCard Support, but even most of the drivers have bugs and the screen flakes out.

But hey, AROS is free, if you are interested, download it, install it, and submit bug reports.

Aros runs on all x86 CPUs from Pentium 3 to i7 PCs but MOS will not run on a G5 Mac so if we compare progress of Aros Intel i7 vs Powermac G5 Mos config clearly the truth is Mos is still on a tiny scale compared to Aros's ambitious PC  configurations supported. When MOS is running on every Mac desktop and laptop from G3 to G5 and Intel x86 Macs let me know :roflmao:

For me the issue is the PPC requirement, Commodore never made a PPC Amiga, Native OS for PPC or even A4000 upgrade card so Mos + UAE running on smelly old 90s Macs from a dumpster is no more "Amiga" than Aros + WinUAE running on a brand new dodgy brand of PC.

Mos is a hobby OS which costs more than Win7 and needs the inferior [to WinUAE] UAE emulator to run 90% of Amiga software.

Each to their own, but OS4/Mos are a waste of money IMO (just like Clownto's Amiga [shaft you] Forever is)