@WolfToTheMoon

There was a port to the Mac. Which targeted exclusive MacMini hardware. Fine if you had one but I didn't and only had more popular laptops. It might have been a bridge to a laptop given all we wanted for years was a laptop. I don't recall if it was official or not. But I do recall a demo disc was stolen, which pissed some people off, and any such project was cancelled. All it did was to punish the user base. If a MOS developer stole it and knowing the outcome, they could have done so easily, and kept laughing years later at the butterfly effect they knew it would cause.

@Hypex

Kill it with fire and restart with AROS, then. If you are working for free you might as well be free.

The whole who owns what shell game is the absolute death knell of the platform as it stands and if it's come to this, as much as it pains me to say it, it's really time to move on.

It could've been nice to see an ARM native version running on PiStorm on bonafide Amiga hardware (as well as standalone) with a performant 68K JIT built in for all your legacy needs, but the technical feasibility is irrelevant under the circumstances we are in.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Hypex wrote: @WolfToTheMoon There was a port to the Mac. Which targeted exclusive MacMini hardware. Fine if you had one but I didn't and only had more popular laptops. It might have been a bridge to a laptop given all we wanted for years was a laptop. I don't recall if it was official or not. But I do recall a demo disc was stolen, which pissed some people off, and any such project was cancelled.

Thats was project Moana but you got events out of order.

It existence pissed of one of "the partners" which at that time were already in the "hostage negotiation" phase of would end up as the OG lawsuit.
Thus it was canceled which pissed off the developer who then somehow managed to have his laptop stolen by someone who not only found the ISO on the HD but also cared enough to release to the public.

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

@Karlos

Quote:

How do you think all these old components became PPC native? Answer: by being re-implemented in a more up to date C standard.

I said for years, given it was popular back then, that porting AmigaOS to PPC brought it closer to x86 for this reason. Now, that didn't mean OS4 would be available for x86 obviously. But the hard work was done.

Quote:

Any code can be dirty. A requirement for a "universal" 68K standard would be to avoid dirty tricks.

The problem then, is that there is all this legacy 68K code which can be full of code tricks, you want to have access to. So one group is dirty and another group clean. But, OS4 has already dealt with this old code, with various success.

Quote:

You can write self-modifying code for just about any architecture. It's not considered a good thing. For any "standard" bytecode solution, not modifying your own instruction stream.

I imagine in the least the code modification would be ignored with some faulty behaviour. As I see it, the code loader caches the 68K binary in memory and generates the native code in the executable segment. With the data and strings being in the cache. Code comes along and modifies itself, which modifies the cache, but the native code then continues. Without any detection the native code would continue as if nothing happened until it goes faulty.

Quote:

ELF is unrelated to the ISA, how do you think 68K linux worked?

I read it used a.aout which sounds more like an output object binary and later they moved to ELF. But my point was ELF binaries are organised into sections. Yes hunks are organised in sections as well but 68K code tends to intermix data with code and more so for code written in ASM.

However, when basing a load format on 68K, it is in CISC which can complicate a code translator. This is why, for the same idea, I thought PPC would be a better load format. The code is wider at 32 bit minimum, but, there's only one code per instruction so should be easier to decode and translate. However, like 68K, most codes are split up into 16 bit opcode and 16 bit data so perhaps it doesn't matter in the long run. It does reduce code deciphering into either 16 bit or 32 bit code, with 16 bits specifying major code, so should still be simpler to translate in theory.

Quote:

PPC also lacks SIMD if you don't have AltiVec (or Cell). Has that prevented it from running on 603, 604, 440, G3, etc?

No but SIMD is expected in modern CPUs. Most of those cases predate AltiVec. And before then the FPU was used for 64 bit operations to optimise speed.

Early on there were math libraries for Amiga so a vector library isn't such a bad idea. However, now days code is expected to have more direct access, by being able to specify vector types.

Quote:

Virtual 68K is big endian, end of story. You can run it BE directly on PPC, ARM or with endian conversion and/or big endian memory model (i.e. Amithlon style) on x64.

It may slow the code down a tad. But not enough to make any difference. The funny thing would be, if it was running code designed for LE, ported to BE, then eventually running on an LE CPU but broke because it needed to run purely in LE.

Quote:

Kill it with fire and restart with AROS, then. If you are working for free you might as well be free.

As that point it's lost the original code base. Though that's what System 54 will really be. Though somehow using AROS as an OS base was accepted by the Vampire community who are hard core Amiga chipset guys.

Quote:

The whole who owns what shell game is the absolute death knell of the platform as it stands and if it's come to this, as much as it pains me to say it, it's really time to move on.

I can see your point. There is likely too much effort to port it in any fashion to new hardware. Let's face it, all it would do is move a buggy code base to another platform, and drag all the old bugs across! That's about as useful as moving a catholic priest pervert to another diocese. That's not solving the problem, it's moving the problem elsewhere, but the problem still remains!

I was getting vague compiler errors out of gcc. Like it tells me the line but not the specific construct it had a problem with. So decoded to update the SDK although I already had been running the 2021 release. So get the latest SDK installing. Click an icon in my dock. Whole system freeze! Seriously it's a project icon that opens a guide file. How unstable can the system be!?

Quote:

It could've been nice to see an ARM native version running on PiStorm on bonafide Amiga hardware (as well as standalone) with a performant 68K JIT built in for all your legacy needs, but the technical feasibility is irrelevant under the circumstances we are in.

I wonder if they've been avoiding it. First there was PowerUP and now there is PowerARM. It makes sense but would add yet another CPU (YAP) to the Amiga that software needs to support. They'd need to write a PowerARM kernel and then later it would need to be challenged by WarpARM. Naturally people would expect a new Fusion with M1 support to run the latest Mac RISC binaries. And the MOA project, Mac on Arm, would be born. Perhaps an even sillier idea is a PPC loader for ARM, so that ARM equipped Amigas have a kernel that can load PPC WarpUP binaries, so that they can play WipeOut 3d!

Last edited by Hypex on 05-Jan-2024 at 02:31 AM.

@ppcamiga1

Quote:

ppcamiga1 wrote: @Karlos there is not virtual 68k it is just emulator want people to use commodity hardware give them commodity quality os leave ppc as it is and start working on something new that will be worth of use on commodity hardware

There's a userland 68K and a supervisor capable 68K emulators.

AmigaOS 4.1 FE has a userland 68K emulator under the OS.

Emu68 has a supervisor-capable 68K emulator under a light-weight hypervisor.

_________________
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)

@Hammer

Quote:

The blame for PowerPC migration is on Escom-era Amiga Technologies GmbH's Petro Tyschtschenko who collaborated with Phase 5.

So Petro was involved as well. I know he was keen on keeping the Amiga going. Where as Escom wasn't.

Quote:

Phase 5 was involved with PowerPC upgrades for the Apple Mac market.

I recall this. Though given the Mac still had a parent company. It does seem strange a 3rd party would produce PPC upgrades since the Mac already had PPC and it's not as if PPC boards were cheap.

Quote:

Gateway 2000 inherited Amiga Technologies GmbH's PowerPC direction.

And didn't do anything with it since PC Power moved in the other direction.

Quote:

ARM in 1996 wasn't performance-competitive when compared to other RISC and X86 competitions.

It was however competitive with 68K which was stagnant. Even when 68K was still around ARM was said to compete and beat 68K in performance at the same clock rate. So I read online in places. But, ARM wasn't big endian, support was only added later. Had it survived, the 88K would have made a logical replacement for the 68K. Thanks Motorola!

@Kronos

Quote:

It existence pissed of one of "the partners" which at that time were already in the "hostage negotiation" phase of would end up as the OG lawsuit.

I was unclear on what the details were.

Quote:

Thus it was canceled which pissed off the developer who then somehow managed to have his laptop stolen by someone who not only found the ISO on the HD but also cared enough to release to the public.

It seems like it was a good idea but executed poorly. From the unofficial status then on. I didn't recall the laptop. I recall something about a CD. Cared enough to release it. Ha. What a caring gesture! Was it a Mac laptop? Would be funny as it didn't normally boot on one.

@Hypex

Oh boy....

1st of all right up until the last G4 PowerMacs 3rd CPU upgrades for Macs were just as common as they were with Amigas, so nothing special bout Phase5 doing cards there.

Petro's big "plan" was produce more obsolete A1200s 3 years after they triggered a "meh" response on initial release.
Made a bit over 200000 units, failed to sell them all and came up with the conclusion that Amiga needed another AGA machine with a slightly less obsolete CPU and plenty of extra compatibility issues backed in (the Walker).

If PPC had been center stage he would have gone after proDad who had an alpha OS and plans for legacy free HW which could have been something like early MorphOS+Pegasos only 7 years earlier.

GateWay2000, yeah the more I look at their plans and how little to nothing was actually done the more I come to the conclusion that they were just a less obvious prequel to the Amino scam(s).

ARM at that time made 0 sense for various reasons and the failure of 88k in gaining any traction was what made Motorola join AIM and drop it favor of PPC.

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

@Kronos

PPC was absolutely a sound move when Phase5 first introduced them. We got to sidestep the totally embarrassing 601 and got a 603e as a bare minimum. And even that wasn't a bad chip at the time. For me, it made a lot of things possible that were infeasible on the 68040 I had.

The kernel war was annoying and writing for context switch minimisation was an interesting discipline, but it was all good.

I know I come across as a huge hater of PPC, but that's a mischaracterisation. I just don't see it being a viable option today.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @Kronos PPC was absolutely a sound move when Phase5 first introduced them.

I never said anything to the contrary.


What was wrong both in hindsight and (IMO) also quite clearly at that time was wasting all the resources in building that HW when most of it should have been done in SW.

While a piOS/P.I.O.S.One combo might have destroyed binary compatibility to the point of not gaining any traction, something like MorphOS_0.1 onboard a basic 603 card (no 680x0) should have been feasible and would have opened a much cleaner, faster and more reliable start into PPC scarifying only some HW hitting c##p (aka games) which weren't really part of the same market even at that time.

Might have also spared us the kernel wars.

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

@Hypex

Quote:

The problem then, is that there is all this legacy 68K code which can be full of code tricks, you want to have access to. So one group is dirty and another group clean. But, OS4 has already dealt with this old code, with various success.

You can have your cake and eat it. Dirty self modifying 68K legacy code still runs, it just takes a performance hit because when there are code changes, the translation cache is invalidated for any traces that span it. It's not as if this doesn't work just fine in existing JIT emulations - just the performance penalty. Except, even with the penalty and even on a 603e, you are dealing with such an edge case for any system friendly code that you won't encounter it most of the time anyway.

However, "clean" code will not have this problem and by by sticking to a well documented 68020 subset, you can tune that for best performance. You may even be able, with some effort and strict guidelines, get to a point where translation can be done AOT.

Quote:

I wonder if they've been avoiding it. First there was PowerUP and now there is PowerARM. It makes sense but would add yet another CPU (YAP) to the Amiga that software needs to support. They'd need to write a PowerARM kernel and then later it would need to be challenged by WarpARM. Naturally people would expect a new Fusion with M1 support to run the latest Mac RISC binaries.[/quopte] Depends how overloaded their crack pipes are, I guess. [quote]And the MOA project, Mac on Arm, would be born. Perhaps an even sillier idea is a PPC loader for ARM, so that ARM equipped Amigas have a kernel that can load PPC WarpUP binaries, so that they can play WipeOut 3d!

Well most things that required WarpOS have moved on to OS4 in one way or another and should therefore be in a recompilable state. As it goes for WO2097, you don't need to worry, there's a 68K port in the works already.

I see a lot less value in providing backwards compatibility with PPC primarily because most PPC software that is maintained still, ought to be recompilable - especially to another 32-bit/Big Endian target.

_________________
Doing stupid things for fun...

@Kronos

Quote:

I never said anything to the contrary.

No, I realise that. I was lazy-replying so it looked like I was responding specifically to something you said. I just wanted to clarify my position. I'm so jaded and old these days people might actually think I hate PPC and the software that runs on it.

I honestly don't.

Quote:

While a piOS/P.I.O.S.One combo might have destroyed binary compatibility to the point of not gaining any traction, something like MorphOS_0.1 onboard a basic 603 card (no 680x0) should have been feasible and would have opened a much cleaner, faster and more reliable start into PPC scarifying only some HW hitting c##p (aka games) which weren't really part of the same market even at that time.

It didn't exist at the time, but I think it's more than fair to say that both trance and petunia on the 603e* turn in better performance than the 68K those cards were equipped with. Had something like that been available then, the cards would have been less expensive, we wouldn't have had the context switch or kernel issues to worry about. Effectively you'd have had something akin to what the PiStorm is today, except on a PPC.

*proof was in the pudding for me, lots of applications were significantly quicker than the 040 anyway. The 020 doom attack port was more playable at 640x400 in a window than the 040 was at 320x200 fullscreen on my system (except for the screen wipe - read from VRAM sucks on BVPPC).

Last edited by Karlos on 05-Jan-2024 at 02:06 PM.

_________________
Doing stupid things for fun...

Quote:

Kronos wrote: Made a bit over 200000 units, failed to sell them all and came up with the conclusion that Amiga needed another AGA machine with a slightly less obsolete CPU and plenty of extra compatibility issues backed in (the Walker).

talked with some Amiga 3rd. party hardware techs back then.

The A1200 was expensive in production, the restart of production needed a lot of time and if they had started Walker development earlier without this 'PC Super IO-Chips' it could have been in production before the Escom bankruptcy.

Would it have saved Amiga Inc. ? Not as a long term solution.

Quote:

Kronos wrote: GateWay2000, yeah the more I look at their plans and how little to nothing was actually done the more I come to the conclusion that they were just a less obvious prequel to the Amino scam(s).

Most of their press releases looked like if they had some middle ware like TAO/Elate and wanted to sell x386 hardware as SetTop Box / Gaming Console / Home Computer thingy under the name AmigaMMC. 68k compatibility may (or may not) have been done via UAE that was still in its infancy.


Quote:

Kronos wrote: ARM at that time made 0 sense for various reasons and the failure of 88k in gaining any traction was what made Motorola join AIM and drop it favor of PPC.

Ack! Back in the time when P5, Amiga or PIOS announced their PPC systems it was still a valuable plan, it might have been a solution but after Apple bailed out and PPC went south, it became obsolete and this went faster than I had thought.

ARM still lacked performance therefor most game consoles used MIPS (PS1) and later exclusive PPC versions, not available for public use.

ARM is much better now but as long as you don't get cheap powerful system you should stick to AMD64.

@OneTimer1

The Walker was still using AGA which was "meh" in 92, so not a "seller" in 96 (or later depending on how long it was supposed to stay available)
The Walker was based on a 68030 only slightly less underwhelming as the 020 in the barely selling A1200.
The Walker would have made compromises in compatibility beyond the slightly off floppy in the A1200.
Nothing in the Walker suggest that it could have been made cheaper than an A1200

Now if C= had introduced something like that in 92 instead of A4000/1200 it might have made some sense and even sold in o.k. numbers, but in 95/96 it was nothing more than a brainfart.

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

@Kronos

Let's not forget the fact it looked like a retrofuturistic vacuum cleaner.

Whatever happened to that clone system? There was something - I remember it being a weird drive bay form factor, that had AGA but had significantly improved the memory timings.

Damn. I can't remember the name. Was it this? https://bigbookofamigahardware.com/bboah/product.aspx?id=39

Last edited by Karlos on 05-Jan-2024 at 02:45 PM.
Last edited by Karlos on 05-Jan-2024 at 02:43 PM.

_________________
Doing stupid things for fun...

Quote:

Kronos wrote: The Walker ...

Ack!

Quote:

Kronos wrote: Nothing in the Walker suggest that it could have been made cheaper than an A1200

I was not writing about the Walker there, it would have always been more expensive than A1200. It was the restart of the A1200 that could have been cheaper ...

Quote:

Now if C= had introduced something like that in 92 instead of A4000/1200 it might have made some sense and even sold in o.k. numbers, but in 95/96 it was nothing more than a brainfart.

Ne they didn't had something new, no AGA+ nor AAA but Petro didn't had any know how about production or hard- / software development, this is something that could have started earlier and could have been much more efficient.

What would have made sense in 1996 would have been an Amiga motherboard in the brand new ATX form factor, just like what Hese did 20+ years later.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OneTimer1

How could have been cheaper?

The chips were hold hostage by companies that were still owned form C= so thats a no go.
Only "development" that was done was the incomplete floppy fix, without it even more games would have failed making the A1200 an even harder sale....

They did not have the funding/vision to make something that could have restarted the Amiga.

What they did was something that could be sold in limited numbers which they hoped would have ended in some positive cashflow only to find out that their numbers just didn't match with reality.

-> all the wasted years

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

@kolla

An ATX Amiga would have only made sense as an A4000 like systems, which already existed as the A4000T which could be mounted in (big) off the shelf AT tower cases.
So lots of engineering for solving a non problem on a niche product.

Now if you were talking about something like a low end version of the Draco..

Basic backplane with ISA slots (see here ) and maybe onboard IDE.
030-060 CPU card with some RAM and minimal boot ROM.
Basic RTG SW compatible with the supplied ISA-VGA (based on the same chips as the early Z2 RTG cards).

Sure, might have made sense.

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

@kolla

Quote:

kolla wrote: What would have made sense in 1996 would have been an Amiga motherboard in the brand new ATX form factor, just like what Hese did 20+ years later.

Yeah, that happened in 1994 with the A4000T and was re-released by Escom in 1996! Did you want one without the case?

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