@Karlos

ppc was chosen as new amiga cpu in 1995
it was good decision
ppc cards for amiga was available in 1997 and it works

problem is too many scumbags and idiots waste time on attack on ppc
instead of leaving ppc as it is and working on something new worth use on x86/arm
we still have no working open source gui clone
zune from aros is still not compatible with mui from 1997

so karlos stop your crap and start working on zune
together with szulc, szonwejs, dimauro, pixie, kolla,

@kolla
Quote:

And so few of the OS devs has the spine to stand up and say enough is enough of all the BS.

And do what? Bully the company's management into doing what we want? Realistically, the only option is to walk away, and that's definitely been done.

Quote:

I predict that OS3 devs soon enough will be in same situation (if they aren’t already.) And with lots of code in 3.2 being infected with Hyperion copyright claims, one has to start anew, from 3.1, again.

You know, people can and do learn from their mistakes. Not always, but it does happen...

@agami

Quote:

FYI, if you AmigaOS 4 independent developers would form a union, I can get you out of your NDAs.

I see no need for that. For starters, an NDA doesn't stop anyone from doing their own independent work, and publicizing confidential information without permission is unethical except in very exceptional circumstances (of which there are none).

Forming a union (or joining an existing one) doesn't make any sense either. Most people who have worked on OS4 did so as volunteers (i.e., no employment relationship or contract). I imagine that forming a union that spans multiple countries would be a nightmare to do.

Quote:

But something tells me there's a whole bunch who feel superior for being on the inside of Hyperion's scheme, and love stating how they can't say anything because they're under NDA.

Signing an NDA is nothing to be proud of. It's simply how things are done.

Quote:

But something tells me there's a whole bunch who feel superior for being on the inside of Hyperion's scheme, and love stating how they can't say anything because they're under NDA.

I don't see the value in having an NDA that's so secretive that you can't even tell anyone that you signed it.

Hans

Last edited by Hans on 18-Feb-2024 at 09:30 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Karlos

Quote:

Whatever the root cause(s), the end result as it stands today is pathological to the platform. Hardware that's difficult to obtain, an OS that seems completely moribund whether or not there's actually any stuff happening behind the scenes, no visibility or statement of intent. We have an upcoming hardware release that was first discussed years ago.

Yeah, it's in pretty poor shape.

I hope that the A1222 release goes well, and also that more regular updates will be restarted.

Longer term, it's no secret that I'd prefer a switch to ARM.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Karlos

Quote:

If you go back a good number of pages, you'll see that this probably isn't going to work. Too slow.

Will it technically work?
Yes you can put a PPC core into FPGA.

How complex is it?
Making a PPC is significantly easier than making a complex high end CISC like the Apollo 68080.

What performance can you expect
From my experience, 100 MHz in a consumer FPGA is a reasonable goal.
It depends a lot on your CPU development experience and the type of FPGA.
For example our APOLLO 68080 reaches up to 220 MHZ in high end FPGAs.

@Gunnar

A 200MHz PPC isn't going to cut it if people are used to 2GHz. Having your own independent design and doing it "just because you can" are motivational enough for a few individuals but I don't think you'll get a viable product from it.

Entertaining ppcamiga1's idea for a moment, there are of course FPGA with embedded PPC cores. I have no idea how suited they are to his suggestion, though, and again, the embedded CPU might still be lacklustre.

_________________
Doing stupid things for fun...

@Hans

Quote:

Longer term, it's no secret that I'd prefer a switch to ARM.

Brace yourself to be ppcamiga1's next target, then.

I think an ARM port is entirely feasible today if ARM32/BE is your target. Priority would go to exposing the inbuilt SoC hardware capabilities for 2D, 3D, network etc.

Personally though, I'm more interested in abstracted out system. With the exception of some form of bare metal hypervisor/emulator, running it all, or as much as possible, in 68K and running that same 68K platform on as many different things as possible, from the original machines (with suitable acceleration) to every sensible flavour of ARM, x64 and PPC. Ideally such a solution should be designed to permit the inclusion of "metal side modules", to allow native acceleration of critical features like data types, codecs, etc. Equally, such native components could be used to manage sensitive data (encryption keys, certs, etc) outside the 68k environment, though providing a means to interface with it might be a bit of a challenge.

Regardless, these would need to be optional since the system still needs to be able to run on physical 68 machines without such hidden niceties.

I have no delusion that the Amiga described this way is ever going to be modern, but equally it can be the best retro platform.



Not a million miles from Amiga Anywhere concept but with the added advantage of still being Amiga/software compatible.

Last edited by Karlos on 18-Feb-2024 at 11:06 AM.

_________________
Doing stupid things for fun...

@Karlos

Sometime ago I was doing the 3d model of an A4000 keyboard and wondered, if it would be able to fit an arm/FPGA board in here how sweet it would actually be to have an Amiga in this form factor!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

You fit a whole SoC powered computer in the palm of your hand already so an A4K keyboard is probably rather spacious.

_________________
Doing stupid things for fun...

@ppcamiga1

Quote:

ppcamiga1 wrote: @Karlos ppc was chosen as new amiga cpu in 1995 it was good decision ppc cards for amiga was available in 1997 and it works problem is too many scumbags and idiots waste time on attack on ppc instead of leaving ppc as it is and working on something new worth use on x86/arm we still have no working open source gui clone zune from aros is still not compatible with mui from 1997 so karlos stop your crap and start working on zune together with szulc, szonwejs, dimauro, pixie, kolla,

Karlos Quote:

A 200MHz PPC isn't going to cut it if people are used to 2GHz. Having your own independent design and doing it "just because you can" are motivational enough for a few individuals but I don't think you'll get a viable product from it.

"A 200MHz PPC isn't going to cut it" but emulation of the 68k@200MHz is more than adequate? Neither is remotely competitive with an ASIC. Emulation of the 68k@200MHz is more tolerable because 68k performance is the base measuring stick due to most Amiga software using 68k code and being developed for low performance CPUs. A 68k@200MHz is barely more competitive for modern software. And yes, I do understand emulation of the 68k may provide performance the equivalent of a 68000@1GHz or a 68060@400MHz but that is a step backward in performance for some PPC owners. Software emulation and FPGA simulation of the 68k can't unite the 68k and PPC AmigaOS camps and move them forward. Neither will a port of AmigaOS to ARM or x86-64. A professionally developed 68k SoC ASIC could though.

Karlos Quote:

I think an ARM port is entirely feasible today if ARM32/BE is your target. Priority would go to exposing the inbuilt SoC hardware capabilities for 2D, 3D, network etc.

The emu68 and PiStorm projects are fine to use ARM32/BE but a proper port of the AmigaOS to ARM should use ARM64/LE with reduced 68k and PPC AmigaOS compatibility (sandbox for compatibility). ARM32/BE is being removed in newer ARM cores and LE is needed for many GPUs on ARM devices as Hans has stated before. Do I think most AmigaOS users would move to ARM64/LE hardware? No. I think it would divide AmigaOS users between 68k, PPC and ARM flavors of AmigaOS with some choosing to convert to MorphOS or AROS x86-64 instead.

@matthey

Quote:

The emu68 and PiStorm projects are fine to use ARM32/BE

For over two years Emu68 supports big endian aarch64 mode only. Support for aarch32 has been removed,

@Karlos

Quote:

A 200MHz PPC isn't going to cut it if people are used to 2GHz

How many PPC people use which clock today?

What clocks have PPC system that are used?

EFIKA was around 400 ?

PEG1 was 600 ?

PEG2 was 1000 ?

SAM was 400 ? than 600 ?

SAM 460 was 1100 - but effectively slower than PEG?

AmigaOneXE 900 ?


How is the distribution of the users ?

And what clock do you need to run the system well?

Are the 400 MHZ SAM able to do this?


The total performance is of course the combination of CPU speed and Memory speed .
Many of the "older" PPC system have slow memory.
And even if the CPU runs at 1000 of some their memory underperforms.

So here a solution with more memory speed would be nice.

Last edited by Gunnar on 18-Feb-2024 at 03:03 PM.

@Gunnar

All these number are irrelevant as they represent the older/slower end of usable PPC systems.

People want to upgrade from Xx000 and G5s not downgrade to what would have been o.k. 25 years ago.

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

michalsc Quote:

For over two years Emu68 supports big endian aarch64 mode only. Support for aarch32 has been removed,

Does ARM64/BE (AArch64/BE) still work on newer ARM cores where ARM32 has been dropped? Have you tested Emu68 on one of these newer cores?

Kronos Quote:

All these number are irrelevant as they represent the older/slower end of usable PPC systems. People want to upgrade from Xx000 and G5s not downgrade to what would have been o.k. 25 years ago.

I think the specs of the older PPC hardware are important. The average and minimum installed hardware base is as important, if not more important, than the high end hardware specs. The standard installed base is also important. A side grade for high end PPC hardware is likely more acceptable than a downgrade, especially if it is significantly cheaper, allowing more users to upgrade to a higher hardware spec. The C= 68k Amiga suffered from low standard hardware specs including a 68000@7MHz or 68EC020@14MHz, 512kiB-2MiB of memory and no hard drive. The standard spec was far more important for software developers than high end Amiga hardware. PPC standard hardware is not well defined, less standard than C= days and perhaps deteriorating with the loss of SIMD unit support for the high end and now even the standard FPU from "expensive" low end hardware.

Gunnar is intelligent and sometimes makes some good points but I still believe he is an imposter of Gunnar von Boehn, likely MEGA_RJ_MICAL. It looks like he is copying and pasting info from the AC forums, his answers are elusive or suspect and there are flaws in his technical knowledge. For example just in this thread, he claimed the 68060 only had a 4 byte/cycle instruction fetch due to limited time where I later posted the explanation of the chief architect of the 68060. Another example from this thread comes from the following quote.

Gunnar Quote:

The 68060 can execute up to 2 instructions per cycle but it has severe limit in doing this How many the 68060 can do per cycle depends a lot on the program. And varies a lot. I would say that in real live the 060 gets maybe an average of 1.2 The Apollo 68080 is designed as an highly improved 68060. The Apollo 68080 has fixed nearly all limit of the 060. The Apollo 68080 CPU can execute up to 4 instruction per cycle. But for instruction to be executed in the same cycle - they need to be independent. you can not execute for example this in the same cycle move.l (A0)+,D0 cmp.l A0,A1 Why can you not execute them in the same cycle? Because the MOVE will increment the A0 pointer, and the CMP needs the result of this to start this means the CMP needs to wait for the MOVE to be finished before it can run.

Much of this information is correct, likely copied from the AC forums. The example of dependent instructions can be executed together on the 68060. The first instruction is executed in the AGU (EA calc) stage of the execution pipeline and the (A0)+ result forwarded/bypassed to the 2nd instruction. The 68060 can also execute a 2nd instruction in the same cycle like "add.l d0,d1" which is normally dependent for the same reason. The early execution and forwarding/bypassing of many instructions and EA calc results in the AGU stage is very powerful. Combined with the elimination of load-to-use penalties, it is even more powerful as this pipeline design is good for even RISC code as the SiFive U74 core demonstrates, even though it can't execute CISC instructions which are the equivalent of two RISC instructions like "add.l (a0)+,d0" (the d0 result can't be forwarded/bypassed in this case but the EA calc result in A0 can be).

@Gunnar
You can show you are the real Gunnar von Boehn by answering the following questions.

What did Gunnar von Boehn call the pipeline design of the 68060 (SiFive U74 core design is similar)?

What were the nicknames and nationalities of the original non-core Apollo core team members including me?

Most likely, Gunnar will do everything possible to avoid answering these simple questions or attack me. Right MEGA_RJ_MICAL?

Last edited by matthey on 18-Feb-2024 at 06:12 PM.

@matthey

Judging from the last AmigaMetting in NeuMünster. all MorphOS users either had an PowerBook or G5 (sometimes both) and most of team Red was running X1000/5000 with a 1 or 2 midrange system (Peg2, A1-XE, SAM460).

I'd say most people with lower class HW have either given up or already upgraded to one of the above.

That fake 200MHz PPC would only be a "sidegrade" for people using Phase5 HW or emulation, so it's quite clear that it would fail hard if it was just that.

As for "Gunnar" being "MEGA_RJ_MICAL" I see 3 options:

1. the similarities are only in your mind
2. MEGA has far more technical expertise as he had shown previously
3. MEGA was Gunnar's troll account from day 1

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

@matthey

Quote:

What were the nicknames and nationalities of the original non-core Apollo core team members including me?

This is easy.
Your nickname was:ARMCHAIR QUARTERBACK



Matthey why do you try go on personal and try argue?




Matthey you posted a lot of false facts about the V2 cores.

The reason for you posting all this false information is that you not have a Vampire.
And you never coded on it. You have no real knowledge about it.
Your only source of information is google ...


And you mixed up 2 different cards.
You mixed up the Vampire 1 Test card with small 8000 LE FPGA and limited features
with the Vampire 2 Product card with big 40000 LE FPGA with lots of features.

I helped to clear up your misunderstanding up and corrected the information.


Matthew how do you want to continue this now?
Do you want to continue to waste time fight and argue?

Last edited by Gunnar on 19-Feb-2024 at 09:44 AM.

@Kronos

Quote:

That fake 200MHz PPC would only be a "sidegrade" for people using Phase5 HW or emulation, so it's quite clear that it would fail hard if it was just that.

Mind that 200MHz, was for a __high_end__ FPGA.
Most of us here dont have the money for a high end FPGA.
A high end FPGA system $5000 per chip.


Using FPGA as an alternative to outperm an 1000MHz ASIC will not work.
You can maybe outperform existing PPC system in memory speed.
The same way as the Vampire V2 and V4 easily outperm from many 1000MHz PPC system in memory speed.


You can with PPC FPGA not outperforming the ASIC PPC in CPU speed.
But you can usegFPGA to develop an new PPC core that you then own - and which you can later put into an ASIC - this is workable option.

Last edited by Gunnar on 18-Feb-2024 at 06:41 PM.

@Gunnar

A proper ASIC on a semi current process (so you have a chance to beat existing PPC) isn't even remotely viable unless you find a huge untapped market outside Amiga.

Everyone (except IBM with POWER) has dropped PPC in favor of ARM suggests that such a market does not exist.

Same goes for 68k only with a 10 year headstart.

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

@Kronos

Quote:

A proper ASIC on a semi current process (so you have a chance to beat existing PPC)

With 90nm process from year 2003, you can reach up to 4 GHz clock.
So even a 20 year old process is perfectly good to make a very competitive ASIC

@Gunnar

And have something as "efficient" as the "G5"

Might work for this market, but everyone else?

Nope, nope and nope again.

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