@cdimauro

Quote:

Amiga, as almost any system, was Intel inside since day zero.

Oh no!

Of course using Intel chips for anything but the main CPU was acceptable.

You likely have read my comments about Hombre and if it had survived to become the become the next Amiga, it's likely it would have had an Intel inside as the main CPU, since the Intel partnered with HP to produce the Itanium from the HP RISC core design.

Tech comparison: What is more successful, the Intel Itanium or the PowerPC? The Itanium managed to be produced until a just few years ago, though didn't exactly take off, and was mostly used in the server market. The PPC started as a server CPU, downscaled to the desktop with help from Motorola and Apple while making an appearance as an embedded CPU, then Apple abandoned it and it went back to servers again. The Itanium was an obvious risk, since it had no legacy x86 compatibility, so had no real chance of taking over the desktop PC market. OTOH, a few years back, IBM sold out and ran POWER in exclusive LE mode to ease x86 compatible software porting (PPC64IntEL).

Quote:

The Amiga / post-Amiga land can call them differently, but actually there's only one type of entity running on the Amiga o.s./-like, and this is a thread. Everything on the Amiga o.s./-like is just a thread, which shares ALL resources on the single address space which is available (AKA: the single process).

The problem is in the semantics. Be what is convention these days or what people learn. But the real problem comes out when attempting to port conventional code to AmigaOS that works one way when AmigaOS works in another.

Quote:

I don't see the problem: the mathieee libraries give back a non-shareable library base to be used specifically on that task, AFAIR.

I wasn't aware of that or had since forgotten. It's not a real problem if you have read the documentation which should come down to a brief read of OpenLibrary() but I don't see it mentioned. However it's an AmigaOS standard. It could be called the exception that proves the rule. Because most libraries return the same base in memory. In any case the specific library documentation would mention it.

Where I see people commonly caught out is in bsdsocket.library. I tend to come across a forum post where they had opened the library in one Process and failed to use the functions in another Process. Now, I don't know if it's the code that may be ported over, or confusing what process means in an AmigaOS context but I am somewhat amused when people post about it. I can't say it's lazy, as I don't know all the details, but I wonder why people are opening a library in one process and accessing in another. Even in the Amiga shared memory model that looks sloppy. Amiga code needs to be clean or it may be fraught with bugs.

Quote:

If "real threading" is what's is found on the literature, then I fail to see how this is possible with OS4...

The only example I can think of is pthread API. Which IIRC did have some changes but it's a link lib so not in OS4 API. I don't know if modifies internal behaviour but OS4 doesn't offer conventional threads that modern code takes for granted.

Back on 68K I began an experiment to add threads to AmigaOS. It was based on my idea for a parent process with threads being code blocks with their own stack space. So, they would execute in sequential order, under the quantum. That was the idea. Threads would naturally operate with the same access to process memory, variables and same process ID. I did some experiments but it was slightly faulty. I continued the work on OS4 and it continued to be faulty. Such as making the shell exhibit weird behaviour like becoming non responsive. But I never really put enough time into it. Could make a funny prank.

@agami

Quote:

Pigeons don't blame other pigeons for having the cat set amongst them.

And cats don't usually spare the flock unless it flies away.

Last edited by Hypex on 01-Jan-2024 at 03:14 PM.

@BigD

Quote:

BigD wrote: @Kronos It's a shame that's your point of view. RiscOS got ported to RPi and had a new lease of life.

Did it really? AFAIK it got a similar short lived hype cycle as MorphOS getting ported to Mac, the ATARI FireBee and a few others of that kind.

Quote:

In my view AmigaOS could have made an even bigger splash.

With it being as fractured as it is and no commitment in any development of the OS for such setups I just don't see it.

Quote:

Anyway, 68k development HAS picked up. I don't see any big gesture project like the A600 GS making much difference though the AmiStore function might help developers. I honestly don't know what more you expect. In my experience the next generation find the Amiga interesting.

Weird ways to run OCS games != what could be considered a life line for any Amiga "user" community.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@BigD

Quote:

RiscOS got ported to RPi and had a new lease of life.

And I am really interested in the amount of traction it garnered so far! This might be indicative for a simmilar effort from 'Amiga'-side, which had a substantial marketshare outside of UK in comparison to RiscOS, whereas RiscOS was mostly popular in UK.

OldFart

_________________
More then three levels of indigestion and you're scroomed!

@OldFart

How do you measure "traction"?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Kronos

Both THEA500 Mini AND the A600 GS play AGA games and apps (with the AMiNIMiga soft mod in the case of the Mini). They both will attract new users. The current "community" is well catered for unless you're expecting an alternative to a modern x86-64 desktop in which case there's nothing to see here!

Last edited by BigD on 02-Jan-2024 at 11:36 AM.
Last edited by BigD on 02-Jan-2024 at 11:28 AM.
Last edited by BigD on 02-Jan-2024 at 11:25 AM.

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

@Karlos

People tend to blame Hyperion for OS4 being on PowerPC but the choice was really made by Phase 5 who produced the PPC accelerator cards. This was around 5 years after those cards were produced so still made sense. Apple were still using PPC so it made sense that way as well but also pointed out a problem that they depended on Apple for the CPU. They couldn't source PPC from Motorola like with the 68K and CPU sourcing problems for the AmigaOne and later for X1000 would prove that anyone wanting to use the PPC would become Apple's bitch.

About ten years later after "Amiga went PowerPC" the PowerPC was in trouble. It was ten years old on the Amiga, which was as old as 68K was on Amiga, when that needed replacing. Unfortunately, at that common 10 year margin, by the time OS4 had been established and released on the AmigaOne as well as actual Amiga, Apple would soon drop PowerPC as a CPU. This left server CPUs and embedded CPUs. None were really suited to OS4 as a desktop OS, but Apple was the head letter in the AIM alliance, so this left the PPC looking like a dog CPU at the behest of being Apple's bitch.

It's somewhat funny as, despite being an over simplification, the PPC is really just a huge logic device that runs machine code. Why is it such a big deal? I mean, why is there such a dependence in the modern world, on an expensive IC? At the physical level, a PPC is no different to an x64 or ARM, it's just a logic device that runs code. The first PPC had both x86 an PPC code under one bonnet. Apart from market demand, why can't they produce another IC with both x86 and PPC64 under one chip? I wonder if the answer lies in PPC and ARM code compression, though that's a complex way of addressing it. They manage to run code that is not truly native by unpacking it in real time. Perhaps the same idea could be used convert PPC code to x64 or ARM code on the fly? Though that's really a complicated way of solving it through hardware. And Transmeta faded into obscurity, though they had planned the same for PPC, which I din't see happening.

Perhaps the irony is, that if the AmigaDE idea had eventuated and been integrated in the OS4 core, then OS4 and apps themselves could have been coded in AmigaDE portable binaries. This likely would been the best move. That or to run OS4 as Java. Since, conveniently, Java bytecode was big endian.

It has to be said, of all the hyped announcements we put up with, the AmigaOne was actually produced and came out. It has that as a badge of honour. It became real. As per an earlier post I too was grieved when the AmigaOne A1200 board was dropped. They burnt the bridge. Another mistake of announcing Amiga plans without real scientific proof of concept. Otherwise known as reference hardware and working hardware. I had a younger friend, who was more familiar with the C64, and would tell him about these AmigaOne boards coming out. Well, we met once in a while and I would tell him a progress report, but never would report that it's actually out as a product. Typically story, as the story never ends, with the same lines being told. Well, he moved away so I never ended up telling him anything came out, but then a funny thing happened. Against all odds, the AmigaOne actually came out!

Sure, it wasn't as exciting as Caipirinha and everything else, including Hombre. If anything it was more regular and being regular made it more realistic. But, it had one thing that was superior to all others, it came out. Even if not technically superior it gave it some value none of the other vapour products had. And possible, despite my Radeon 9200SE being a budget 3d card, the hardware could possibly match what the Caipirinha could have done.

I was really impressed by the ABox and proposed Caipirinha custom chips. After the Hombre failed to eventuate the Caipirinha looked even better. Of course it would be nothing more than Amiga porn, teasing us with machines we couldn't touch, since they didn't exist in real life. But the ABox computer did actually become something after all. It became the ABox layer in MorphOS.

Amithlon was very similar to what OS4 would do without Amiga chipset under the hood. I recall at the time when people discovered it they wanted OS4 to be scrapped and Amithlon put in it's place. I could see why but I didn't see that as helping the platform because I viewed it as an AmigaOS emulator. It would run AmigaOS fast, because of how it ran on the hardware, but it didn't move the OS forward. It was the same old OS, but running on RTG and faster. That was nice but I wanted to see it pushed forward. It also came out first and Bernie stated he would get his out first. I had high hopes for OS4 but in the end Bernie was right. AmigaOS4 became a trailblazer against Amithlon.

Another thing is that Amithlon, like Phase 5 with PPC, added another CPU to support with native code. This was another major feature but I don't know how well it was supported and Aminet looks like PPC had more support than x86. But, the difference is, Amithlon never plugged into an Amiga. It never to my knowledge, could even run on a PC bridgeboard, which would have given it ability to run inside an Amiga even if the Amiga became a dongle. When it came out I recall someone asking if Amithlon would make their A2000 run faster. I almost burst out laughing at the technicalities of what they were asking. Unfortunately not.

I don't know what it is but despite all the scary accounts of AmigaOne boards dying mine managed to survive. It still works now but too slow for modern use so just get it out for testing. I even managed to break mine when I fractured my G4 after a cleaning operation. I swapped it with a G3 and $250AU loss, as despite it being in full use, I thought $500AU to replace the CPU with the same thing and no upgrade was too expensive. I managed to run it stable after sourcing 2GB server RAM that reported as 2GB.

I think you've summed up OS4 and MOS well enough. The X1000 was last high point of OS4 hardware I think. But, even though MOS can run on superior hardware (except the G5 because it doesn't support LE, even if it's clocked faster, when the PA6T does), that Mac hardware is decades old. It's not the same thing to compare old hardware against newer hardware, even if both are unobtanium, when one is restricted to an old decent example at expense and the other is restricted to newer low stock at expense.

However, QBox is still there. But, the ABox has changed. The ABox API used to just be called from the Abox 68K ABI. But they changed it so it's more direct or uses PPC ABI. Old ABox is still supported. But newer and modern MOS code has different ELF tags.

For OS4, there is the extended memory subsystem. But, it really only serves to drag OS4 down to the level of MEMMAKER on DOS. They've been trying to solve SMP or some core support for over a decade, but without even adding threads to AmigaOS despite shared memory which should make it trivial. But, there is some form of memory protection and private memory in OS4. Memory can be allocated private. And other memory is protected by being marked executable or accessible. A process cannot access or trash any memory like it does on 68K, despite consequences or trash going undetected. I found this myself when I had misused a DOS function by sending an unparsed string. After an OS4 update my 68K code started crashing. I looked into it and found I hadn't correctly used DOS functions and missed some fine details which resulted in crashes. Now this was annoying but it was also good because at this point OS4 at least had some memory protection. However, it was like the old OS2 incompatibility problem again, because now working 68K software would crash and people would complain even more unstable OS4 was. But, even though it was too late for 68K, it did reveal buggy 68K software we took for granted. Or didn't know was faulty.

One example it revealed was OpenFromLock() misuse. Unfortunately it's easy to miss an important detail. It releases the lock! Now, I also missed this, and suspected I had other eyesight issues even before they went blurry. It doesn't seem logical, since the name doesn't imply it, and I think it caused more harm than good but it's there. On OS4, be that using FFS or SFS will exhibit different behaviour. One will crash, the other will freeze the whole system. I think it would have been better to check for valid lock and throw a yellow alert. But, like most OS objects, it's in a random location of memory that gets accessed regardless when needed.

I've long suspected UAE crashes and freezes on OS4 because of this but cannot confirm it. The Amiga code handling DOS operations doesn't use it from what I read. But this is just one example that can reveal badly written code and there are surely other misused functions over the years.

@Matt3k

Quote:

Man, sorry to hear about your X1000 flaking out on you, that just sucks! If you don't own a Mac PPC (2.5PCIe or 2.7PCIX) they are highly reliable and fast performing systems to consider if you want to run MorphOS that it...

Thanks. I don't know if it's getting old and faulty or the battery is fading again. But, unlike the XE, it's unusual for it to randomly freeze if nothing crashes first.

A friend gave me a G5 Mac once but I returned it due to lack of space. It did have something in common with my X1000 that had an HD4890 installed at the time. They both took 20 seconds to show an image on the monitor!

Despite being capable and mostly superior to what else does run MorphOS, in the AmigaOne market, the X1000 is unsupported. Likewise, OS4 is unsupported on Macs. Except for that old Mac hack.

@Hypex

I don't blame anyone for the original choice to go for PPC, it was a reasonable choice at the time. What I do find completely unreasonable is the fact that people continue to stick to it now the tables are turned and all the valid reasons for leaving 68K for PPC now apply to PPC with respect to ARM or x64.

PPC/NG totally failed. That's not to say it's not an improvement, clearly many improvement have been made and people are happy enough using them, but what I mean is, it failed with respect to modernising the platform in any fundamental way (by which I mean breaking the original 68K limitations on addressing and SMP). So what you have is not remotely NG, it's just 3.x on 32-bit single core PPC with some UX polish.

I came to terms with that a long time ago. If you are truly stuck with those limitations (if backwards binary compatibility is your key motivation) then you may as well embrace them. That means giving up the utterly absurd quest for "new" PPC hardware and adopting something more accessible, even if it's not theoretically as performant. Would you rather have acceptable performance on your WIP* OS on readily obtainable HW or is a solid gold boat anchor the only acceptable option?

*As in more people could actually work on it because it's now an option more people can justify, as opposed to what we have now.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: What I do find completely unreasonable is the fact that people continue to stick to it now the tables are turned and all the valid reasons for leaving 68K for PPC now apply to PPC with respect to ARM or x64.

Back then many did NOT switch to PPC, not just because of the price but because:
- it offered nothing or to little benefit for their use case to make the switch
- they didn't trust the pie-in-the-sky promises of a great future
- they didn't want themselves to be associated with some loud zealots
- sentimental reasons

Yeah the turns have tabled indeed

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos @Karlos

Most people didn't switch to PPC (MorphOS) because they where waiting for PPC (AmigaOS) that needed
- years to materialize,
- ran into legal problems,
- was much more expensive than gaming on PC or console and
- had no AAA games.

Last edited by OneTimer1 on 01-Jan-2024 at 04:15 PM.
Last edited by OneTimer1 on 01-Jan-2024 at 04:15 PM.

@Kronos

Quote:

Kronos wrote: @Karlos Quote: Karlos wrote: What I do find completely unreasonable is the fact that people continue to stick to it now the tables are turned and all the valid reasons for leaving 68K for PPC now apply to PPC with respect to ARM or x64. Back then many did NOT switch to PPC, not just because of the price but because: - it offered nothing or to little benefit for their use case to make the switch - they didn't trust the pie-in-the-sky promises of a great future - they didn't want themselves to be associated with some loud zealots - sentimental reasons Yeah the turns have tabled indeed

VIA KT-133A chipset was problematic enough and MAI Articia S has cache coherency problems. A Linux programmer labeled MAI Articia S as cache coherent incompetent.

VIA KT-133A's issues have caused reputation damage on VIA. Many AMD K7 customers jumped on NVIDIA nForce 2. AMD Iron Gate didn't have VIA KT-133A's issues.

The 3rd party Northbridge issue was nullified when K8 included integrated Northbridge.

AMD's official chipset partner for the Ryzen era is ASMedia. ASmedia struggled with PCIe 4.0 compliance (i.e. B550 PCI 4.0 arrived later with B550A being PCI 3.0) and AMD released its own X570 PCIe 4.0 chipset which is based on Ryzen's Northbridge chip.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Kronos

Quote:

Kronos wrote: @agami What attitude? The one that predicted the imminent death of any piece of Apple HW 15 years ago? The one that some new 1 man project not fixing a small not-the-problem will somehow make Amiga relevant again in one way or the other (despite all the other 1 man non fixes of the past)? The one ignoring that the average Amiga user is closing on 50? I could go on. So no my ancient decrepit PPC HW dying with all replacements gone in 2040 or later isn't the issue and it never was. The issue isn't even that I'll be pushing 70 by that time. The real issue will most likely be that SW development and thereby the level of HW that can be used will have come to a near standstill since everyone involved in them is also pushing 70. Noone will need a >2GHz G5 to run a version of Wayfarer that is about as usefull for 2040s websites as AWEB on a 68020 is for todays. Noone will need a rPI25 to run the 3rd port of a 3rd class 50 years old (by that time) game in the most inefficient way possible. Now if someone could come up with something even remotely interesting for people to young to remember C= or Amiga we might avoid that fate but sofar I see nothing in that regard and I'm not even sure how that could work while retaining anything "Amiga" in it.

Yep, that one.

_________________
All the way, with 68k

@Hypex

Quote:

Hypex wrote: People tend to blame Hyperion for OS4 being on PowerPC but the choice was really made by Phase 5 who produced the PPC accelerator cards. Quote: Karlos responded: @Hypex I don't blame anyone for the original choice to go for PPC, it was a reasonable choice at the time. What I do find completely unreasonable is the fact that people continue to stick to it now the tables are turned and all the valid reasons for leaving 68K for PPC now apply to PPC with respect to ARM or x64. PPC/NG totally failed. That's not to say it's not an improvement, clearly many improvement have been made and people are happy enough using them, but what I mean is, it failed with respect to modernising the platform in any fundamental way (by which I mean breaking the original 68K limitations on addressing and SMP). So what you have is not remotely NG, it's just 3.x on 32-bit single core PPC with some UX polish. I came to terms with that a long time ago. If you are truly stuck with those limitations (if backwards binary compatibility is your key motivation) then you may as well embrace them. That means giving up the utterly absurd quest for "new" PPC hardware and adopting something more accessible, even if it's not theoretically as performant. Would you rather have acceptable performance on your WIP* OS on readily obtainable HW or is a solid gold boat anchor the only acceptable option? *As in more people could actually work on it because it's now an option more people can justify, as opposed to what we have now.

I agree with @Karlos here.

I don't blame the turn-of-the-millennium Amiga Inc. et al for setting the initial PPC direction, but the key concept here is that it was the "initial" direction, and not the be-all and end-all direction.

I blame Hyperion and A-EON for sticking with PPC at a time when the perfect opportunity was presented to make a shift:

- It's 2009, Hyperion has just come out on top of a long drawn out mediation process surrounding the AmigaOS 4 IP, and here comes this new individual who wants to spend money on getting some new hardware for AmigaOS 4.
- By this point, Apple (the only commercial consumer computing platform that ran on PPC) has already transitioned all their hardware and Operating systems away from PPC to intel (major hint)
- MorphOS is using second hand Apple G4 hardware as a lifeboat
- And the AmigaOS 4 community has bugger all native PPC software. And bugger all that couldn't be easily recompiled for a new ISA.

I could forgive them choosing PPC to just get things up and running quickly, with a transition plan that would've been well completed by now, but milking every dollar from the dying ISA via a desperate, fractured and orphaned Amiga community is something I can never forgive, and never will.

Every addict willingly spends their own money on their vice, but that does not absolve the purveyors of the vice, and nor is their Stockholm Syndrome relationship any less sick.

Last edited by agami on 02-Jan-2024 at 12:23 AM.
Last edited by agami on 02-Jan-2024 at 12:22 AM.

_________________
All the way, with 68k

It’s quite possible to support many architectures, that was the entire point of porting the OS to C in the first place - to make it portable. Yet years pass on and nothing. Now snippets of code is "backported" to OS3, for few good reasons other than to entangle it with "Hyperion IP".

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@agami

Quote:

the AmigaOS 4 community has bugger all native PPC software.

*cough cough* Excuse me??!

_________________
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

@agami

Quote:

agami wrote: Every addict willingly spends their own money on their vice, but that does not absolve the purveyors of the vice, and nor is their Stockholm Syndrome relationship any less sick.

Well that is true for any penny spend on anything "Amiga" in the past 20 years (or more really) as thats when it turned from a somewhat sensible computer platform into a pointless hobby pushed by delusional nutjobs and preachers both on the sellers and buyers side.

None of threads like these would exist if it wasn't so.....


@Hammer
Thank god we can always rely on you posting pointless stats about long forgotten and irrelevant PC specs

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Trixie

Context. He's talking about 2009. What was the list of PPC exclusive software back then, that was not possible to port to a different architecture?

Almost everything ever written for OS4 has been written in C, C++ or another high level language. Assembler usage is diminishingly small and that includes the operating system itself.

You can still ask the same question today, to be honest. What is there that's not a recompile task if someone wanted to switch to ARM BE/32 or even "Uber" 68K?

The biggest challenge is the SDK, with it's interesting custom compiler attributes, but once that's able to generate object code for your new target you most of the way there.

Last edited by Karlos on 02-Jan-2024 at 08:44 AM.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Perhaps the irony is, that if the AmigaDE idea had eventuated and been integrated in the OS4 core, then OS4 and apps themselves could have been coded in AmigaDE portable binaries. This likely would been the best move. That or to run OS4 as Java. Since, conveniently, Java bytecode was big endian

Amiga Anywhere already exists and has been under everyone's nose for decades. It's 68K. We just didn't see it, because we were so hung up on the idea the 68K was an obsolete anachronism we must distance ourselves from. And yet all along, we strove to make it that "runs anywhere" by ensuring OS4 and MorphOS would run it to their best ability.

The only thing that stops it achieving the full potential of "anywhere" is a lack of standardisation around APIs, unless you pick 3.1 only as the baseline and as Kronos points out, that is not attractive to anyone using a specific platform that wants to use features of it.

There's nothing unsolvable there though. You just need to make a new API that can be feature mapped onto the common intersection and add support for extensions where there is no commonality.

Last edited by Karlos on 02-Jan-2024 at 09:16 AM.
Last edited by Karlos on 02-Jan-2024 at 09:10 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: There's nothing unsolvable there though. You just need to make a new API that can be feature mapped onto the common intersection and add support for extensions where there is no commonality.

Sure and while we are on it lets just fix the other issues like 31Bit addressing, open system structures, lack of SMP support etc.

Since we don't want (and don't have the resources) to reinvent every wheel on that trainwreck I suggest we lock for existing open source solution.



-> Kubuntu with a BoingBall wallpaper !!!!


With the total lack of speed and everyone insisting to do his 1 man project anything else is not even a pipe dream.

If you somehow get a team together to work in that direction (based on what Hyperion owned OS3.2 or always-in-alpha-AROS68k?) AND get a big chunk of the community behind it you would in a best case scenario still need several years to make it a reality.

Lets talk again in 2030.....

Last edited by Kronos on 02-Jan-2024 at 09:22 AM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada