Hi

Have been looking through old systems today. If only Panasonic showed some interest in commodore. We could of had are OS4 PPC years ago.

https://en.wikipedia.org/wiki/Panasonic_M2

_________________
A1200 ACA1232 128MB Indivison MkIICr
Elbox empty Power Tower
RPi3 Emulating C64 ZX Atari PS BBC
Wii with Amiga emulation
Vampire v4 SA

@g01df1sh

He didn't, he went to work at The 3DO Company with Trip Hawkins founder of Electronic Arts. Their business model was to design the console but not manufacture it themselves, instead their partners would and they would also licence the design to other major consumer electronics companies with Electronic Arts being a supplier of software and and a royalty going to 3DO for each title sold.

What may have been if somebody competent had gained control of the Commodore assets instead of Escom we can only dream about. There's no guarantee they would have made a move to PPC though, if the timing was right they could have made the jump to x86.

@IanP

so what are the remaining original Amiga developers up to today? Any working for ATi/Nvidia ?

_________________
A1200 ACA1232 128MB Indivison MkIICr
Elbox empty Power Tower
RPi3 Emulating C64 ZX Atari PS BBC
Wii with Amiga emulation
Vampire v4 SA

@IanP

I only see a point for this with x64 where x86 finally caught up to the 68K register count. It still had the mnemonic mess with them split all over the alaphabet depending on word size but at least there are 16 base registers. Why I bring this up is that they would have needed an emulator. And I don't see the point of emulating registers in global variables in memory. Sure x86 is faster than 68K, but only because 68K gave up and a back then only slightly faster. A proper CPU emulator stores emulated registers in the host CPU. I've gone right off topic now.

@g01df1sh
from the early days of Amiga

Bob 'Kodiak' Burns, Software Engineer at ShoreTel
Glen Keller, Engineer at Fovean.
Dale Luck, Senior Software Engineer at Roku.
RJ Mical, Director of Games at Google.
Ron Nicholson founded HotPaw Productions.
Carl Sassenrath founded Rebol Technologies.

Apologies to those I missed out.

@IanP

The point is, when OS4 launched, x86 had no clear advantage over PPC whatsoever. It's all very easy in retrospect, but PPC it is now, and PPC it'll stay (probably).

@IanP

Quote:

IanP wrote: @g01df1sh from the early days of Amiga Bob 'Kodiak' Burns, Software Engineer at ShoreTel Glen Keller, Engineer at Fovean. Dale Luck, Senior Software Engineer at Roku. RJ Mical, Director of Games at Google. Ron Nicholson founded HotPaw Productions. Carl Sassenrath founded Rebol Technologies. Apologies to those I missed out.

"Didn't they do well?"

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@IanP

IIRC Carl also said he was working at Roku.
Kamelito

@WolfpackN64

Quote:

The point is, when OS4 launched, x86 had no clear advantage over PPC whatsoever.

That's both backwards and not accurate.

The x86 was never even considered to be an option.

Despite a litany of technical excuses, the commitment to PPC has always been about what it wasn't.

@ne_one Yes x86 had the small advantage of 90%+ of all computers sold and hence a huge experienced software and hardware developer community, where as PowerPC was a relatively new architecture that few people new and beyond the Apple software specialists that were tied to that customer base nobody was interested in. How many CHRP machines were sold? What ever happened to the likes of the A/box and PIOS1?

@IanP

It's safe to say that the community didn't help matters either because there was always a rabid anti-Intel sentiment that still prevails for some today.

Either way, Apple ultimately proved that while the CPU of a platform is extremely important for its viability, it's immaterial as far as users are concerned.

Does anyone honestly care what processor is in their Mac, iPad or iPhone?

It's also worth remembering that he worked at Sony too and you can see him credited on the end titles of various games (f.e. Heavenly Sword, Ratchet & Clank and so on)

_________________
Proud Amigan since 1987
Owner of various Commodore and a SAM440ep\OS4.1FE
See them on http://retro.furinkan.org/

@ne_one

It's either going to be Intel or Arm. When there is no choice you can't care anymore and are left with being careless.

Either way it's going to be a little endian CPU. The world has gone backwards.

The worlds fastest endian.

@Hypex

Quote:

It's either going to be Intel or Arm... Either way it's going to be a little endian CPU.

A real "NG" version of the OS should be CPU agnostic and endianness should be irrelevant.

I'm not suggesting that it would be easy, but it's eminently doable if you ditch 30 years of baggage.

That means forget porting.

We already have tons of options for emulation. The developer of Petunia has even come out recently to say that JIT support would be viable on other CPUs.

@ne_one

Quote:

A real "NG" version of the OS should be CPU agnostic and endianness should be irrelevant.

That's true it should be. However I recall even on PPC the old Amiga structures were problematic because they have byte size fields around pointers and PPC likes all those pointers to be in 32-bit alignment.

I don't know if x86 had a performance penalty on non-aligned word access.

In any case, I would have expected compilers to have features now where you don't need to get so technical and so you can work in a WYSIWYG way. But this isn't always the case. How the data is encoded shouldn't matter to the programmer. But I've read code where it looks for ID words and instead of looking for what it exactly needs, it is looking for a reversed version. That's confusing!

On the Amiga there used to be MAKEID macros that made an ID from four letters. Now if they used this type of macro to put the letters into number form it would be fine as it would be encoded the right way regardless of CPU and the programmer doesn't need to think about it. But they don't always do that. All code I've seen uses a reverse version.

Most of the time this only matters when importing data from a file in binary format. Amiga importers of BMP would have needed to reverse bytes around. Same for an OctaMED replayer on the PC.

GCC does have an endian switch but I didn't see it do anything when I tested it. However, being able to specify endian of variables or objects would help. Most bi-endian code I've seen has converting macros. It has a LE read macro. Or converts data after reading it which can look messy. So code can be agnostic but also messy when it needs to deal with external data.