@Trixie

If I had the urge to show others how big my willy is, I wouldn't be making a fool of myself

_________________
Amiga A1200, 3.1 ROMs, Blizzard 1230 MKIV 64MB & FPU, 4GB DoM SSD, Workbench 3.1

@Hyperion-Director

"@Rose

Really? Prior to September 30, 2009 that would have been a valid statement.

Having said that, there is also the question of resources both human and financial.

AmigaOS is a 32 bit big Endian oriented operating system, be it 68K or PPC.

Moving to x86, ARM or even RISC-V would be no small feat as these are little endian. It can be done of course - technically.

Unless we move to 64 bit and the whole issue becomes moot but again, this would require a massive investment."



Really? so the endianess?? the byte orientation is the main obstacle?

Is ARM Little endian though?
ARM (like most RISC) architectures is what the call biendian. Biendian means that is can run as bigendian or littleendian. The standard way of doing things in ARM is to come up in little endian the switch to bigendian if you want to, or set one of the control lines on the CPU to come up in bigendian mode.

Endianness conversion in ARM
https://stackoverflow.com/questions/4286671/endianness-conversion-in-arm


Is ARM big endian or little endian?
https://www.quora.com/Is-ARM-big-endian-or-little-endian?share=1

Current implementations of ARM6 or later have the ability to run in either Little or Big endian type modes.

Last edited by SHADES on 15-Apr-2021 at 01:06 AM.
Last edited by SHADES on 15-Apr-2021 at 01:03 AM.

_________________
It's not the question that's the problem, it's the problem that's the question.

@A1200

@Hyperion-Director

Just a question:

since there was an agreement in January, what changed since then and what are the reasons to cancel that agreement?

Thank you

_________________
retired

@A1200

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@SHADES

Quote:

AmigaOS is a 32 bit big Endian oriented operating system, be it 68K or PPC.

Or any other 32 bit Big Endian cpu.

Quote:

Really? so the endianess?? the byte orientation is the main obstacle?

Yes. The byte orientation is the main obstacle.

Quote:

Is ARM Little endian though? ARM (like most RISC) architectures is what the call biendian. Biendian means that is can run as bigendian or littleendian. The standard way of doing things in ARM is to come up in little endian the switch to bigendian if you want to, or set one of the control lines on the CPU to come up in bigendian mode. Endianness conversion in ARM https://stackoverflow.com/questions/4286671/endianness-conversion-in-arm

The whole point of use 32 bit Big Endian cpu is to use old code in C made for Amiga without modification.
On ppc or any other 32 bit Big Endian cpu it is possible to use twenty or more year code in C , just recompile it, and it will work.
Thats why ppc Amiga feel like better Amiga than these made by Commodore.

@ppcamiga1

Quote:

The whole point of use 32 bit Big Endian cpu is to use old code in C made for Amiga without modification. On ppc or any other 32 bit Big Endian cpu it is possible to use twenty or more year code in C , just recompile it, and it will work. Thats why ppc Amiga feel like better Amiga than these made by Commodore.

Correct me if I'm wrong, but I thought the problem was not the C code (which is portable / recompilable) but the data (which has reversed bytes). Amiga programs often embed significant amounts of data into their programs instead of reading them from disk the way most modern OS's do. For instance, the RGB data in the images will be mixed up if you read raw data from one endian format to another.

Even that isn't a problem if you have a good JIT, as Apple showed when they moved from PPC to OS X.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@simplex

Well, when your running programs side by side some 32bit 680x0 programs, some PowerPC programs, the data has to be the same for PowerPC programs and 680x0 program, and it is, this is way this works. Its just program but its also mix and match of 680x0 libraries and PowerPC libraries.

Yes if you are not running 680x0 programs, you can forget about that problem, but then is lots of programs you must run in an emulator.

the thing you see is like code cast a (unsigned int *) into a (unsigned short *), you pick the upper 16bit, if its powerpc, if its intel it lower 16bit. And this the problem, when you are dealing with compiled programs, also you have union’s, this will also break.

typedef union
{
unsigned int data;
struct {
unsigned short high;
unsigned short low;
}
} smart_t;

has to be rewritten on Intel as:

typedef union
{
unsigned int data;
struct {
unsigned short low;
unsigned short high;
}
} smart_t;

in short C/C++ code is not cross platform language, its not like Javascript or Java, the CPU family is important.

Last edited by NutsAboutAmiga on 16-Apr-2021 at 12:48 AM.
Last edited by NutsAboutAmiga on 15-Apr-2021 at 10:54 PM.
Last edited by NutsAboutAmiga on 15-Apr-2021 at 10:49 PM.
Last edited by NutsAboutAmiga on 15-Apr-2021 at 10:49 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Just to throw a real world example into the mix in regards to endians etc

I recently worked for a company which had to convert a core programme it relied on from Sparc to X86. The software in question was written in C. This was just a few (very important) programmes, not a whole OS.

Sparc, like 68k is big endian, so ran into the same problems discussed here. This was not something that was done overnight. I believe it took 2-3 years for refactoring the code. They also had to write more software to convert all the data the applications(s) used as well.

So yeah, it is doable. It requires time and money. The quicker you want it to happen, the more $$ you have to throw at it.

My $0.02 is that the whole ownership debacle doesn't help things regardless of the direction that is taken. From the outside, it feels like there is no real innocent parties and everyone is fighting for a constantly shrinking pie.

@NutsAboutAmiga

Quote:

And this the problem, when you are dealing with compiled programs, also you have union’s, this will also break.

Oh, I deal with compiled languages, but typically avoid these sorts of optimizations precisely because they're bug-prone, non-portable, and hard to understand to boot. I understand where the code you write would arise, but it's a programming practice one ought to avoid. I'd submit that one reason for the Amiga's inability to shake the past is that so many of its users think that bit-banging is the be-all and end-all of programming. To wit, the Vampire crowd. (As far as I can tell.)

It reminds me of a recent "competition" where I saw the advocates of one language produce code that was faster than C/C++. They did this by implementing a different algorithm, which monkeyed with the machine representation of float, converting it to integer, masking with a magic number, then converting back. Sure, that'll work. It's also not a serious argument that the language is really faster than C/C++.

But, yes, I grudgingly admit that, OK, in this case the code would not be portable because the following code will work differently on big- and little-endian code:

smart_t dumb_practice;

dumb_practice.data = 10;
printf("%d %d\n", dumb_practice.low, dumb_practice.high);

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@thread

Re: Post 1172 - NOTICE of Intent to File Surreply Motion to Strike

Amiga Parties' Surreply Motion to Strike

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@SHADES

There is absolutely nothing novel or unique to ARM being "bi-endian" on 32 bit.

This was part of PowerPC specification way back in the early '90s.

However 32 bit x86 has always been little endian. Even silly "virtual CPU" like TAO's "Elate" (aka AmigaDE) were little endian and suffered a huge performance penalty when being run on a big endian CPU (which is rather idiotic on a virtual CPU if you ask me).

This also means that the firmware of many graphics cards require little endian.

Hyperion has spent many years porting x86 to big endian systems (AmigaOS, MacOS) and one of the hardest and most time consuming parts were often related to endianness.

Yes, you can switch a PowerPC to little endian with many ISA's. But this results in a lot of performance hits running 68K native programs. Many games we ported were hardwired to little endian and rooting out these hardcoded little endian issues was a massive undertaking.

@Hyperion-Director

There a good write up on aros how they kind of dealt with the issue
https://aros.sourceforge.io/el/documentation/developers/summaries/m68k-emulator.php

I personally just think emulation is the way to go now, maybe make the Os more aware that it being emulated and make it kind of like a virtual Os. Amikit on pi and Windows is great vision of this and what could be done.

look how good WinUAE has become, I still love how AmigaOS works and would love native port of it to other hardware and platform but we have to aware of the limited resource we got as a community, it’s amazing achievement of what has been done. But I’m more a future looking person where do we see Amiga in 10 years time? PPC I just don’t see a future for the platform long term. Where as if you type in any computer / console product you can think off and add the words Uae your find the Amiga emulator has been ported too it. I think it’s a massively under-utilised part of the Amiga market.

Hyperion the self should know this as soon as PPC support came to winuae I’m sure sales went up for the classic os4.

Just my 2cent

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

Well, I know someone who buys AmigaOS4.1 Classic every mount just to support Hyperion. So, I’m sure they had few sales.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@number6

Quote:

number6 wrote: @thread Re: Post 1172 - NOTICE of Intent to File Surreply Motion to Strike Amiga Parties' Surreply Motion to Strike #6

Hmmm, I find that document a bit disturbing, as it seems that the Amiga Parties (Cloanto/CA Acquisition) are worried about Ben Hermans reply, like the court can't see for itself the flaws of his illogical interpretation of some parts of the case. I hope I'm wrong, and they are just responding in this way as a matter of usual court practices, and nothing is going wrong with the case. Although I'm sure Ben has "weaseled" his way out of lots of bad behavior in the past, and is used to twisting the law in immoral ways, the evidence I've seen so far in this case seems so clearly against Hyperion, I can't imagine how any judge or jury could not see it the same way.

What's your take on this latest document submitted by the Amiga Parties, and what way do you think the case is leaning, in favor, or against Hyperion winning? If you don't want to share your opinion, that's okay. I don't blame anyone for not wanting to express their opinions on this ridiculous situation, I just wish it would finally go to trial and get settled, because I'm pretty sure that any jury or judge would see Hyperion as the party that has broken the 2009 agreement, and hopefully through it out and strip them of everything they stole when it was signed.

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @amigang Well, I know someone who buys AmigaOS4.1 Classic every mount just to support Hyperion. So, I’m sure they had few sales.

Maybe that "someone" should re-think their reasons for supporting Hyperion, and instead support only the developers directly who do the work, since Hyperion hasn't been paying them for ages.

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@amigadave

I would prefer to first...see a reply to the first portion of:

this

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

Hyperion-Director Quote:

@SHADES There is absolutely nothing novel or unique to ARM being "bi-endian" on 32 bit.

Correction. You said ARM was little endian and he corrected it to bi-endian.

Hyperion-Director Quote:

This was part of PowerPC specification way back in the early '90s.

Little endian support on PPC was optional and inconsistently supported. Some CPUs and boards did not support it, some CPUs only supported unaligned big endian memory accesses in hardware handicapping little endian mode, some embedded CPUs only supported little endian memory accesses on a per page basis using the MMU. Endian mode switching is difficult. PPC has load/store instructions which convert endianess. PPC support for little endian was poor.

ARMv7/AArch32 also has optional endian support but it is more consistent where implemented. It supports endian mode changes on the fly and it has instructions for converting endianess. This was overall good endian support. ARMv8/AArch64 deprecates easy endian mode switching on the fly and practically forces little endian mode as the default endianess. Instructions which convert endianess are encouraged instead of operating in big endian mode or on the fly endian mode changes which some cores may still support. Big endian mode support may become less and less common and may be removed at some point. This big endian support is less impressive and more on par with PPC.

Correct me if wrong michalsc.

Hyperion-Director Quote:

However 32 bit x86 has always been little endian. Even silly "virtual CPU" like TAO's "Elate" (aka AmigaDE) were little endian and suffered a huge performance penalty when being run on a big endian CPU (which is rather idiotic on a virtual CPU if you ask me).

Indeed. It would be nice for performance if a virtual CPU uses the native endianess but that has disadvantages as well.

Hyperion-Director Quote:

This also means that the firmware of many graphics cards require little endian.

Initialization time for gfx cards is generally not important for a desktop (it may be for embedded use). Accessing little endian gfx card registers and buses during use is more important although most 3D gfx data does not need to be handled often by the CPU cores. Static data written to registers can have the endianess converted in the source code by the way. I was surprised to see static numbers in little endian format converted to big endian at run time in the 68k Warp3D driver libraries like the Avenger libraries. Of course the 68k Warp3D libraries were an optimization disaster which included much more than poor endian handling.

Hyperion-Director Quote:

Hyperion has spent many years porting x86 to big endian systems (AmigaOS, MacOS) and one of the hardest and most time consuming parts were often related to endianness. Yes, you can switch a PowerPC to little endian with many ISA's. But this results in a lot of performance hits running 68K native programs. Many games we ported were hardwired to little endian and rooting out these hardcoded little endian issues was a massive undertaking.

Many programmers don't care about supporting big endian which is becoming more and more common as big endian disappears. Let's take a look at 32 or 64 bit natively (default and best support) big endian ISAs which are in use with hardware designs still available today.

68k & ColdFire - practically dead
PPC - practically dead
POWER - has better little endian support than big endian now
MIPS - transitioning to little endian RISC-V
SPARC - esoteric but has newer designs than PPC
AVR32 - Atmel switched to ARM and Linux support has been dropped
J-Core - Modern open hardware re-implementation of SuperH

Of these, the only ISA likely to be used in enough ASIC cores in quantity to compete with ARM pricing is J-Core. Hitachi created the SuperH ISA after they were licensed to produce the 68000 from Motorola and the ISA resembles the 68k. Hitachi licensed patents to ARM for the Thumb modes. The 68k, SuperH and then ARM Thumb were the ISAs each used in the best selling 32 bit embedded cores in the world.

2020 J-Core presentation on YouTube

I talked to Jeff Dionne pointing out some flawed data he used on code density which was one of the most important considerations for the SuperH choice. Instead of SuperH having slightly better code density than the 68k for some code he was using in a presentation, the 68k actually has ~29% better code density and uses ~37% fewer instructions for that code. Jeff is planning to use J-Cores in mass produced embedded IoT for the business he works for in Japan. J-Core is nice for small cores but I doubt the performance will scale up the way he want it to. An interesting thing about the video is how the 68k and Amiga solved so many of the problems he faces for a small footprint embedded system.

The whole topic is rather pointless though. Hyperion wins the court battle and doesn't have enough money to do anything on the dwindling number of big endian choices or Hyperion loses the court battle and it is difficult to imagine them staying in business. Small business is often about finding ethical business partners who can help each other but I'm afraid Hyperion has used up its good will and abused its reputation to the point of no return. What are you hoping to hold out for?

1. Hyperion wins the court battle
a) Hyperion can't afford to port AmigaOS to new hardware
b) without new affordable hardware AmigaOS revenues will dry up
c) game over
2. Hyperion loses the court battle
a) Hyperion loses all sources of AmigaOS related revenue
b) Hyperion owes more money than they can ever repay
c) game over
3. Hyperion sells everything AmigaOS related and/or settles
a) Hyperion may receive funds to survive and legal costs are reduced
b) Hyperion could then go back to porting games

Last edited by matthey on 18-Apr-2021 at 05:25 AM.
Last edited by matthey on 18-Apr-2021 at 05:21 AM.
Last edited by matthey on 18-Apr-2021 at 05:20 AM.

amigadave Quote:

What's your take on this latest document submitted by the Amiga Parties, and what way do you think the case is leaning, in favor, or against Hyperion winning? If you don't want to share your opinion, that's okay. I don't blame anyone for not wanting to express their opinions on this ridiculous situation, I just wish it would finally go to trial and get settled, because I'm pretty sure that any jury or judge would see Hyperion as the party that has broken the 2009 agreement, and hopefully through it out and strip them of everything they stole when it was signed.

We don't have much help from the latest document available. There are documents we can't see (sealed because of confidential business info?). One of the missing documents is likely Hyperion's defense of the ownership grab by registering Amiga marks. I am not so worried about the Amiga parties. They are trying to limit Hyperion's defense using some technicalities of their own (that evidence introduction phase of court case is over) and allegations without evidence are speculative (speculative objection). If the technicalities are not accepted by the judge, then there should be no harm done. It looks like Hyperion claims the United States Copyright Act of 1976 allows them to "challenge ownership" which may be true but that doesn't mean the 2009 settlement agreement allows it and they may have admitted they tried to claim ownership in arguing this. It also looks like Hyperion has tried to challenge the transfer of some Amiga marks from Amiga Inc. to Cloanto. The judge has already decided that some Amiga marks licensed in the settlement agreement were not transferred (Cloanto did not receive them as they had no standing to join the lawsuit so they are still at Amiga Inc.) as the settlement agreement doesn't allow it (without termination) and Amiga Inc. is in good standing and part of the lawsuit so I don't see that point either.

Last edited by matthey on 18-Apr-2021 at 06:22 AM.

@matthey

Quote:

Hyperion has used up its good will and abused its reputation to the point of no return. What are you hoping to hold out for?

Well if Hyperion wins then if cloanto/Amiga really want everything back together they would have to buy Hyperion out, so they could get a payday out of it.

Plus let’s not forget they are selling os3.1.4 at 30euros id would of expect they sold at the very least 400+copies? -tax’s and other thing they likely made 8,000euros at very least, most likely more I would guess.

Also if they know they own outright ownership of Amigaos then they could sign deals with companies to license out roms to maybe a mini Amiga consoles, (could be license to 10,000s if the success of the c64mini anything to go by.) they could make there own Amiga forever package, again just look at google play store at Amiga forever rom pack says 10K+ downloads, there a big market out there the Hyperion could go after with very little investment.

_________________
AmigaNG, YouTube, LeaveReality Studio