@kolla

Quote:

kolla wrote: @agami Is emulation of PowerPC really so much worse than emulation of m68k? Do you have side-by-side comparisons?

It’s just simple economics. More person-hours have been put towards honing emulation of 68k cores than there has been for PowerPC cores. So less performance is being left on the table.

Perhaps when one day about 50% of the person hours invested in 68k emulation is invested in PowerPC, it will reach the same level of optimization, but that might take a while.

While I do not have the time to perform a side-by-side comparison on any of my x64 systems, I have seen enough data from WinUAE and QEMU to see that more work needs to be done on the PPC side.

I hear that emulating PPC on ARM fairs better, but desktop class ARM64 is not widely available nor as cost effective as x64.

A lot of things are technically possible and achievable, given enough time and money. I’m talking about what is available now, and that is fast 68k emulation on either ARM64 or x64.

_________________
All the way, with 68k

@matthey

Quote:

Sarcasm? Of course there is no x86 emulation or even simulation in a x86-64 CPU. Some of the x86 support may be microcoded but microcode is still hardware. If microcode support is emulation then the 68000 CPU was a big emulator which is just plain wrong. I thought about correcting Nuts too but Nuts will be Nuts.

LOL. Just a touch. Mostly my reaction to Nuts statement about x86 emulating itself or x64 emulating some x86 codes.

@agami

Quote:

The whole point of porting AmigaOS 4 to high performance 68k is to take PPC out of the Amiga equation. If we have AmigaOS 4 on emu68 atop RPi 4 and RPi 5, and on UAE 68k atop x64, then it doesn’t matter how bad or almost usable the PPC emulation is on x64.

At that point OS4 on PPC has reached the same level as 68K. It's running on a dead desktop CPU. If it needs it to be backported to the CPU from whence it came, in order to run on emulation, then that's a big red flag it's time to give it up. I kinda think that's pointless and an emulated platform is a dead platform. The excitement around reviving the Amiga 25 years ago wasn't to get excited about emulation. Even Amithlon was a band aid solution despite the excitement. At this point I think Bones needs to be misquoted again, "It's dead Jim, but not as we know it."

@AMIGASYSTEM

Quote:

AMIGASYSTEM wrote: @kolla Hi, attention, this happened with "one" version of LHA, then I tested other version of LHA and the file "output.txt" is saved correctly with data in it !

You're focusing too much on LhA now, LhA was just one example and the same happens with other programs that output to stderr instead of stdout. It's not a solution to replace all programs with different versions that output in different ways, but the question is why AROS isn't capable to redirect stderr streams.

The page you linked earlier doesn't tell anything about redirecting stderr output, it just tells how to redirect stdout stream in the Amiga way, so this hints that AROS doesn't support redirecting stderr at all.

If we still use LhA as an example, there are Unix ports of LhA that usually output their help page etc. to stderr, but then there are Amiga based LhA ports that output to stdout. You can demonstrate this, for example, on both AmigaOS and MorphOS, and in these systems you can redirect Amiga LhA with "lha >output.txt" and Unix LhA with "lha *>output.txt", but on AROS the Unix LhA can't be redirected because it doesn't understand *> and takes it as a filename.

When I noticed this, the only LhA version I found for AROS was Unix based that outputted to stderr, so I just wasn't able to do what I needed to do. Apparently there is another LhA port nowadays that outputs to stdout, but it doesn't help me, because I'd need a generic solution for all cases.


Quote:

@matthey I don't know if OS4 or MOS can do it, but even AROS x86/68k can start an application or Game "Without starting the Workbench first" Just start AROS from "Aros Early Startup", and from the prompt run Games and many Applications

MorphOS has a bootmenu just like Early Startup Menu on Amiga, and you can boot the system without startup-sequence and start programs from the shell prompt then.

Last edited by jPV on 30-Apr-2024 at 01:08 PM.

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

@agami

Quote:

agami wrote: @kolla Quote: kolla wrote: @agami Is emulation of PowerPC really so much worse than emulation of m68k? Do you have side-by-side comparisons? It’s just simple economics. More person-hours have been put towards honing emulation of 68k cores than there has been for PowerPC cores.

Really? Who is counting?

Quote:

Perhaps when one day about 50% of the person hours invested in 68k emulation is invested in PowerPC, it will reach the same level of optimization, but that might take a while.

What about all the hours put into emulation of the PowerPC based games consoles?

Quote:

While I do not have the time to perform a side-by-side comparison on any of my x64 systems, I have seen enough data from WinUAE and QEMU to see that more work needs to be done on the PPC side.

What software did you use that runs on both WinUAE and QEMU?

Or are you comparing OS3 on WinUAE with OS4 on QEMU here?

OS3 and WinUAE with JIT, vs OS4 and Qemu without JIT?

If so, how do you know that PPC emulation is to blame, and not just OS4?

Does OS4 require MMU?
On WinUAE it isn't possible to have MMU and JIT at the same time - so what if OS4 requires MMU, and JIT isn't possible?

Here's some exercises for you...

Compare MacOS 8 on WinUAE and Shapeshifter with MacOS 8 on Qemu/PPC emulation. Compare MacOS 8 on Qemu/m68k with MacOS 8 on Qemu/PPC... Compare Linux and/or NetBSD on WinUAE against same on Qemu/68k and Qemu/PPC..

Last edited by kolla on 30-Apr-2024 at 01:18 PM.
Last edited by kolla on 30-Apr-2024 at 01:17 PM.
Last edited by kolla on 30-Apr-2024 at 01:15 PM.
Last edited by kolla on 30-Apr-2024 at 01:14 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@jPV

The lack of some sort of amigaland "posix" is actually the source for a lot of frustration.

The current Amiga shell is utterly over-engineered when you look at how "most people" (like AMIGASYSTEM) actually use it, and they just don't want to learn it anyways. IMO it would make sense to have a very basic shell in the kickstart and then rather load a more advancd Shell-seg from disk... all this is luckily now possible again in 3.1.4+ (like it was back in 1.x days)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

Quote:

Hypex wrote: I wanted to do this: RequestFile >ENV:Drawer DRAWERSONLY Set File "Test" Set Path "$Drawer$File" Echo $Path But it kept messing up. Choosing a dir should merge the two together. So if you chose Workbench: as drawer it should print Workbench:Test in shell. But on MOS the Path was messed up. So I had to do this after experimenting: RequestFile >ENV:Drawer DRAWERSONLY Set File "Test" Set Path "`Echo $Drawer`$File" Echo $Path It took me ages to figure it out. Don't know why I didn't put RequestFile in back ticks. That may have solved it and I preferred not to redirect into ENV.

For me it works exactly the same on MorphOS and AmigaOS 3.1, so I can't see any incoherence here. Both add quotation marks on the RequestFile output, and give the same result when combining.

Here's how it looks on a plain 3.1 setup: screenshot

Be it a bug or not, but MorphOS has copied also bugs to retain maximum compatibility :)

Last edited by jPV on 30-Apr-2024 at 01:47 PM.

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

Hammer Quote:

By 1996, 68060 wasn't competitive with the 1996 Pentium product stack.

The 68060 wasn't competitive because Motorola wouldn't allow it to be clocked up despite the longer 8 stage pipeline giving a major advantage over the P5 Pentium 5 stage pipeline (later 6 with P55C). The problem was that the 68060 performance already threatened the PPC 601 and PPC 603 with only 4 stage pipelines at the same clock speed and it should have been able to out clock the P5 Pentium, PPC 601 and PPC 603 by at least 25%. The OoO P6 Pentium Pro moved to a 14 stage pipeline which did allow it to clock higher but limited by the additional heat from an overly long pipeline and OoO so I believe the in-order 68060+ would have remained competitive due to competitive performance at a significantly lower cost and power.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45085&forum=33&start=780&794#867044 Quote:

68060+@100MHz (25% performance increase over 68060) int: ************************************** 1.88 FP: ************************* 1.23

The Intel Pentium Pro @200MHz has scores of int=2.80 and fp=3.50 from https://www.macinfo.de/bench/bytemark.html but scaling up to a 68060+@200MHz gives at least int=3.76 and fp=2.46. The 68060+ with 16kiB I+D caches would have been ~3.3 million transistors and should have been much cheaper than the P6 Pentium with ~5.5 million transistors.

Hammer Quote:

PowerPC direction was done with German-located Amiga Technologies GmbH and Phase 5 GmbH. Amiga Technologies was stacked by ex-Commodore Germany's personnel. Commodore Germany wasn't the core logic design of Commodore. Amiga's 68K-to-PowerPC approach mirrored Apple's move from 68K to PPC with a userland 68K emulator since Phase 5 is involved with PowerPC accelerators for the Mac market. This Apple-influenced pathway wouldn't work for hit-the-metal Amiga games. Apple established the color QuickDraw layer in 1987 as their RTG solution. The Amiga 68K games are like PC's hit-the-metal i386 protected mode VGA games with 68K CPU and Amiga custom chips.

IBM and Motorola were pushing PPC hard as a replacement for the 68k and Apple chose the PPC path so it is not surprising they were initially successful. Apple was not happy with PPC performance and low clock speeds from shallow pipelines though. Steve Jobs convinced IBM to make the high end 64 bit PPC 970 (G5) based on POWER 4 with a deep pipeline and 3GHz clock speed which he promised for the Mac.

https://en.wikipedia.org/wiki/Mac_transition_to_Intel_processors#Background Quote:

At 2003's WWDC keynote address, Jobs unveiled a Power Mac with a processor from IBM's PowerPC G5 product line, the first personal computer to feature a 64-bit processor. He promised a 3 GHz Power Mac G5 within 12 months, but never released such a product. In 2004's WWDC keynote address, Jobs addressed the broken promise, saying IBM had trouble moving to a fabrication process lower than the 90 nm process. Apple officials also said in 2003 they planned to release a PowerBook with a G5 processor, but such a product never materialized. Tim Cook, then Apple's Executive Vice President of Worldwide Sales and Operations, said during an earnings call that putting a G5 in a PowerBook was "the mother of all thermal challenges".

Jobs received what he asked for with impressive high performance features a mile long. So what went wrong? The PPC G5 usable performance was disappointing for the power used and it was an expensive CPU to produce. Jobs moved to x86 with the first CPU a 32 bit Core Solo based on the P6 Pentium microarchitecture with a more practical shortened pipeline of 10-12 stages. The P6 microarchitecture was one of the most power efficient often used for mobile applications while the performance is often considered lacking by x86 fans. The expensive 64 bit PPC G5 only achieved 2.9 DMIPS/MHz of integer performance and could only be used in high end systems with expensive cooling and power supplies while the more practical, cheaper and lower clocked Core Solo was likely barely over 4 DMIPS/MHz which allowed it to be used practically everywhere. A similar core was used for the low end Celeron and mobile Pentium M lines yet was enough of a performance upgrade from the high end PPC G5 that x86 was considered a Mac performance upgrade and was well received despite unfounded concerns it would not be. It is not just the peak performance of a core which is important but the usable general purpose performance for the resources used. The in-order 68060 was more efficient and better than the P5 Pentium and a 68060+ very likely could have remained competitive against the OoO P6 Pentium which was as low of power as practical for a x86 core. Intel tried again to make a practical in-order P5 based core with the Atom Bonnell microarchitecture and GPGPU Larrabee microarchitecture but gave up in favor of the OoO P6 which limited the ability to scale down into embedded markets. CISC performance was not a problem for x86 or the 68k but the 68k can have smaller cores and use less power. Ironically, PPC has 32 GP registers but was outperformed by a low power x86 core with 8 GP registers. The 68060 has 16 GP registers, which reduces memory traffic to approximately PPC levels, and still is a smaller CPU than the P5 Pentium. Economies of scale are hugely important and a major reason why x86 crushed PPC but lack of performance was a major reason why PPC died on the desktop in 2005 when Jobs announced the transition to x86.

Hammer Quote:

The direction should be Transmeta's method e.g. Emu68 pathway being the closest to it. The Amiga is not a Mac.

There may be some similarities but no. Transmeta was a failure due to "code morphing" translation overhead and poor VLIW general purpose performance. CISC 68k hardware avoids both of these issues and is cheaper and easier to develop. Billions of U.S. dollars were invested in VLIW for general purpose use with Transmeta, Itanium and Qualcomm VLIW CPU architectures with not much to show for it today.

Hypex Quote:

At that point OS4 on PPC has reached the same level as 68K. It's running on a dead desktop CPU. If it needs it to be backported to the CPU from whence it came, in order to run on emulation, then that's a big red flag it's time to give it up. I kinda think that's pointless and an emulated platform is a dead platform. The excitement around reviving the Amiga 25 years ago wasn't to get excited about emulation. Even Amithlon was a band aid solution despite the excitement. At this point I think Bones needs to be misquoted again, "It's dead Jim, but not as we know it."

I agree even though a 68k AmigaOS 4 may be interesting. It would likely be more work to port AmigaOS 4 back to 68k than to improve the performance of the emulation of PPC. The poor performance of the emulation of PPC likely is due to the MMU with the easy solution being an option to disable the use of the MMU in AmigaOS 4. The Hyperion 68k AmigaOS developers are currently porting back some of the AmigaOS 4 features to improve API compatibility for software development which may be better than a full AmigaOS 4 backport. There are AmigaOS 4 features that are heavy for an emulated 68k Amiga virtual machine like compositing and MMU use.

With emulation, the major development effort goes into the emulator instead of the compiler as this gives the most benefit. This is why emulation of the 68k Amiga is so good while 68k Amiga compiler support declines. There is minimal effort to improve the performance of the 68k AmigaOS which is only compiled for the same 16 bit 68000 target from 1985. The A600GS performs optimizations for ARM software to recover the lost performance from RISC load-to-use stalls during 68k emulation. The 68k Amiga is not moving forward but rather x86(-64) Windows with WinUAE, ARM Raspberry Pi with emu68, ARM custom hardware with THEA500 Mini and A600GS, etc. Where is the new 68k Amiga development with hundreds of thousands of units using emulation of the 68k Amiga already sold?

Last edited by matthey on 30-Apr-2024 at 07:21 PM.

@matthey

Quote:

Where is the new 68k Amiga development with hundreds of thousands of units using emulation of the 68k Amiga already sold?

That would be the 080 equipped Vampire/Apollo Boards wouldn't t? AMMX and all that?! I prefer emulation on Arm or Emu68 to be honest but for 68k development it's the 080 core surely?

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

@jPV

Thanks for the info, ok then MOS has the same Boot Menu as AROS (Early Startup Menu equal Amiga)

On AROS One or added Boot Menu (Early Startup) on the Gurb so that you can do small maintenance, you can see a screenshot HERE

Last edited by AMIGASYSTEM on 30-Apr-2024 at 10:14 PM.
Last edited by AMIGASYSTEM on 30-Apr-2024 at 10:12 PM.

_________________
AROS One Home Site
AfA One Amiga OS 3.9

matthey Quote:

Where is the new 68k Amiga development with hundreds of thousands of units using emulation of the 68k Amiga already sold?

BigD Quote:

That would be the 080 equipped Vampire/Apollo Boards wouldn't it? AMMX and all that?! I prefer emulation on Arm or Emu68 to be honest but for 68k development it's the 080 core surely?

FPGA CPUs typically do not receive official compiler support but they may receive "unofficial" support in preparation for a new ASIC CPU based on the FPGA CPU. FPGAs are used to develop ASICs so this is usually how development is done. FPGA CPUs are sometimes used in low production embedded hardware but they usually follow an existing ISA with minimal new features. One of the reasons why FPGA CPUs are usually not supported is that they can and often do change during development so they are a moving target. Does this apply to the AC68080?

Gunnar von Boehn Quote:

But its not impossible to do. We have added support for a six common 68080 instructions to GCC already. And this pretty good. We see that these instructions are used GCC many thousands of times in some programs. Using these new instructions helps to make compiled programs smaller and faster.

Robo Kupka Quote:

What is "mvs" instruction ? I only found it mentioned with the ColdFire cpus and your own note from 2016, mentioning the instruction being removed from Apollo ISA. (http://apollo-core.com/knowledge.php?b=1¬e=1943)

Tommo Noorduin Quote:

It cannot be the coldfire one, that opcode is already used by bank. There was talk about it on discord yesterday, and... today at 17:07 Gunnar wrote: lets us talk about .... 68080 instructions -- ROBINHOOD.exe instruction count mvs = 833 mvz = 5670 mov3 = 8826 dbf = 1787 addiwl = 2186 cmpiwl = 5511 src: EXTERNAL LINK I guess it is very new and does move.b & extb.l like the coldfire one.

Gunnar von Boehn Quote:

MVS and MVZ are move with extend instructions. MVS does sign extend. MVZ does zero extend. This instruction is useful when you convert from byte to long, char to int - or short to int, word to long. As the 68K address mode (An,Dn) uses Word Index always as signed, using unsigned Short Index in any high level language requires also to Zero extend the Index to int. Arne which you know as coder of Apollo Invader, has recently activated a number of instructions for the Apollo 68080 CPU, that were dormant. These re-activated instructions are: - MVS - MVZ - MOV3 - MOVIW - CLR.Q - MOVE2 and others In parallel I've created a number of patches for GCC, allowing the C compiler to make good use of these instruction. The patches improve the code of GCC in regards of both performance and code density. Its widely known that the code density of the 68K family is exception good. And the Apollo 68080 is here by far the best of the 68K family having the most dense code and the highest performance.

http://www.apollo-core.com/knowledge.php?b=4¬e=40433&z=ji_ixo

"Re-activated instructions" means a change that is possible with a FPGA but not an ASIC so the ISA is a moving target. Code previously compiled for the AC68080 that uses new ISA features is likely to fail with the ISA change. The fact that few developers and users noticed their software failing shows how little these features were used. The previous BANK instruction that used this encoding space was used to add more registers but I considered this too complex and not orthogonal enough for compilers to take advantage of and, indeed, there was no support. The new instructions include the ColdFire MVS, MVZ and MOV3Q instructions. At least the MVS and MVZ were available for re-activation because I had pushed for inclusion arguing that they improved code density, reduced partial pipeline stalls, improved ColdFire compatibility for the embedded market and most compiler 68k backends also support ColdFire allowing these ColdFire instructions to be easily activated. I even modified an updated ADis disassembler which gathered statistics on some of the places where MVS, MVZ and MOV3Q could be used and how much code savings would result (I also added support to ADis tp disassemble ColdFire instructions in 68k code). I suggested new ColdFire peephole optimizations which were implemented in the vasm assembler. I was more skeptical about adding MOV3Q as the encoding is in A-line which is generally documented as reserved on the 68k, the immediate encoding size is tiny and MOV3Q was mostly used for popping arguments off the stack because of the ancient 68k ABI that passes arguments on the stack (ColdFire designers did not bother updating the 68k ABI). MOV3Q does improve code density but I came up with a more versatile alternative supporting much larger immediates. This is likely the MOVIW mentioned above but also includes many instructions like the CMPIW.L and ADDIW.L mentioned later in the same thread which can be applied in a mostly orthogonal way and can be easily optimized to with good compatibility by a compiler (or assembler like vasm).

Gunnar von Boehn Quote:

Already available both for V2 and V4 since a number of releases are: CMPIW.L ADDIW.L DBRA.L BRA.B+ BSR.B+ BCC.B+ With the next release planned for eastern, the above mentioned instructions will be released.

"With the next release" also verifies the ISA change only possible in an FPGA. The ISA changes were easily applied to compiled code which can be seen by the ROBINHOOD.exe saving at least 45kiB of code while the addition of registers was not supported by compilers after several years as there are few if any complaints about software incompatibility. This is much closer to the open 68k32 ISA I tried to negotiate and document which could have been supported by other 68k FPGA cores and emulators as well to improve performance and code density.

The AC68080 ISA still has some unresolved issues for 64 bit support and questionable ISA choices. Gunnar chose to add 64 bit support on top of the 32 bit ISA while retaining 32 bit ISA compatibility. I thought we should consider a separate 64 bit mode for a 68k64 ISA and new 64 bit ABI (register args!). A separate 64 bit mode would allow cleaning up and recovering encoding space, datatype sizes of 8, 16, 32 and 64 bit that are easier to decode with a more orthogonal encoding and maintain better 32 bit compatibility in a separate mode. Gunnar never explained why he hated the idea but I suspect that it would have required a larger FPGA core and perhaps more development work. Another issue is the SIMD unit which uses 64 bit registers limiting the amount of parallel SIMD operations and it only supports integer operations while modern SIMD units use 256 bit registers and mostly use floating point. The choices made may limit upgrading to modern standards or at least add x86 like baggage which a newer x86 ISA is trying to eliminate some of to better compete with the new AArch64 ISA which has no baggage. It is challenging to make an ISA that works for small 68k FPGA cores and much larger ASIC cores but the solution is to plan for and make an ASIC which I also pushed for. Not only did I find some of Gunnar's technical decisions highly questionable but his ethics are questionable as well. He lied about me resulting in his AC forum cult followers coming and attacking me on EAB. I don't expect him to admit to anything I have said, admit that any of my ISA recommendations were good, admit that I was an AC team member or admit that I was right about anything, let alone apologize.

A FPGA CPU is nowhere near competitive with an ASIC CPU. The AC68080 core is clock at ~100MHz where an ASIC using old silicon could clock over 1 GHz which improves competitiveness. Small ASIC SoC chips with CPU and chipset including I/O like the RP2040 sell for $1 USD or less but have several times the resources of the AC68080 FPGA core (68060+AA+ uses fewer transistors than the $1 USD RP2040 SoC too). Where Gunnar looks for ways to save logic in a FPGA, ASIC developers look for ways to add logic in a way that increases value since the logic is so cheap. There is no comparison between a FPGA and ASIC when it comes to value, provided that there are adequate economies of scale to mass produce an ASIC. THEA500 Mini, Natami interest and RPi hint that a 68k ASIC for a small SBC may be successful but there is considerable risk too. There is no risk with the Amiga status quo as it is guaranteed decline and death as a virtual machine.

Last edited by matthey on 01-May-2024 at 02:50 AM.
Last edited by matthey on 01-May-2024 at 02:37 AM.
Last edited by matthey on 01-May-2024 at 02:27 AM.

@matthey

Quote:

The 68060 wasn't competitive because Motorola wouldn't allow it to be clocked up despite the longer 8 stage pipeline giving a major advantage over the P5 Pentium 5 stage pipeline (later 6 with P55C). The problem was that the 68060 performance already threatened the PPC 601 and PPC 603 with only 4 stage pipelines at the same clock speed and it should have been able to out clock the P5 Pentium, PPC 601 and PPC 603 by at least 25%. The OoO P6 Pentium Pro moved to a 14 stage pipeline which did allow it to clock higher but limited by the additional heat from an overly long pipeline and OoO so I believe the in-order 68060+ would have remained competitive due to competitive performance at a significantly lower cost and power.

68060's FPU wasn't pipelined. Your 8-stage pipelines are for integers. CPU's clock speed potential is only as good as the weak point.

My 1994 era 68060 Rev 1 with a 50 Mhz rating can be overclocked to 62.5 Mhz and it's unstable in the 75 Mhz range.

My other FPU-less 68LC060 Rev 4 can do 75 Mhz.

Without a 64-bit front-side bus, sustained FP64 and dual INT32 wouldn't be optimal.

AMD's K5 has a 6-stage pipeline and runs into a 133 Mhz clock-speed wall. AMD's K6 (with technology from NexGen's ex-Alpha DEC engineers) still has 6-stage pipelines and can reach higher clock speeds.

Pipeline stages are one aspect of clock speed potential.

Quote:

The Intel Pentium Pro @200MHz has scores of int=2.80 and fp=3.50 from https://www.macinfo.de/bench/bytemark.html but scaling up to a 68060+@200MHz gives at least int=3.76 and fp=2.46. The 68060+ with 16kiB I+D caches would have been ~3.3 million transistors and should have been much cheaper than the P6 Pentium with ~5.5 million transistors.

That's a flawed argument when Pentium Pro's larger cache and front end cover the gap between the slower 64-bit 66 Mhz front side bus and the CPU's higher clock speed.

Additonal transistors are spent when there's a large gap between the slower front side bus and CPU clock speed.


-----------------
http://archive.computerhistory.org/resources/access/text/2013/04/102723315-05-01-acc.pdf
Page 86 of 417, DataQuest 1995

1994 Worldwide Microprocessor Market Share Ranking.

For 1994 Market Share
1. Intel, 73.2%
2. AMD, 8.6%
3. Motorola, 5.2%
4. IBM, 2.2%

Page 84 of 417,

Supply Base for 32-Bit Microprocessors—1994,
For Product's Share of Total 32-Bit-and-Up MPU Market 1994

68000, 17%

80386SX/SL, 3%

80386DX, 3%

80486SX, 16%

80486DX, 21%

683XX, 9%

68040, 3%

68030, 1%

68020, 3%

80960, 4%

AM29000, 1%

32X32, 3%

R3000/R4000, 1%

Sparc, 1%

Pentium, 4%

Others, 10%

Motorola wasn't able to convert 68000's success for 68020, 68030 and 68040. This factor has weakened Motorola's independent R&D capability.

Last edited by Hammer on 01-May-2024 at 03:19 AM.
Last edited by Hammer on 01-May-2024 at 03:18 AM.
Last edited by Hammer on 01-May-2024 at 03:18 AM.
Last edited by Hammer on 01-May-2024 at 03:04 AM.

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

@Hypex

Quote:

Hypex wrote: @agami At that point OS4 on PPC has reached the same level as 68K. It's running on a dead desktop CPU. If it needs it to be backported to the CPU from whence it came, in order to run on emulation, then that's a big red flag it's time to give it up. I kinda think that's pointless and an emulated platform is a dead platform. The excitement around reviving the Amiga 25 years ago wasn't to get excited about emulation. Even Amithlon was a band aid solution despite the excitement. At this point I think Bones needs to be misquoted again, "It's dead Jim, but not as we know it."

Of course I'd rather see actual funds injected in creating a new operating system which aims to re-establish a 3rd commercial consumer personal computing platform, and I'm convinced that the differentiating spirit of Amiga from back in the early '90s could be adapted to a contemporary market. Which would be the kind of exciting that most of us hoped for in the first decade of this new millennium, but that's not what is really on table here and now.

So why not port AmigaOS 4 to x64 or ARM64? To answer a question with a question: With what resources?

Don't think of it as emulation. Think of it as porting AmigaOS 4 to Java. Not exciting in itself, but at least it would be free from the choke-hold of the ever diminishing viability of PowerPC as a consumer desktop/laptop computing CPU.

With what few resources are available to Hyperion, a port of AmigaOS 4 to high performance 68k is juuuusst within their wheelhouse. It's about the only play left beyond riding the PPC thing all the way down.

I'm sure I'm not an isolated case. AmigaOS 4 is not interesting enough to me to expend discretionary income on poor price/performance hardware. And OS 3.2 is not all that interesting either.
Running Amiga OS 3.x on emu68 or WinUAE is cool, but I'm just running a lot of the old stuff, faster. But having the less old AmigaOS 4 68k running on emu68 or WinUAE? That's the kind of thing that would be interesting. If not just for the ability to have a semi-modern web browser.
That to me is worth the asking price of entry.

Ah, it's all just fantasy talk. I know that. Of course it's not going to happen.
I just think it's the right amount cooler than whatever is currently going on.

_________________
All the way, with 68k

@matthey

Quote:

There may be some similarities but no. Transmeta was a failure due to "code morphing" translation overhead and poor VLIW general purpose performance. CISC 68k hardware avoids both of these issues and is cheaper and easier to develop. Billions of U.S. dollars were invested in VLIW for general purpose use with Transmeta, Itanium and Qualcomm VLIW CPU architectures with not much to show for it today

Transmeta received a total of $969M in funding during its lifetime.

https://en.wikipedia.org/wiki/Transmeta#/media/File:Transmeta_Corporation_financials,_1996_to_2007.png

Transmeta had a reasonable 2005 year. Efficeon was released in 2004. Efficeon gained traction in 2005.

This is before Intel's Core 2 Duo's July 2006 release.

After Intel Core 2's release, it was declines for AMD, Transmeta, and desktop PowerPC. Intel's Core 2 was a very strong competitor. AMD was headed in the wrong direction with Bulldozer.

Last edited by Hammer on 01-May-2024 at 05:27 AM.
Last edited by Hammer on 01-May-2024 at 05:25 AM.
Last edited by Hammer on 01-May-2024 at 05:22 AM.

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

@kolla

Amiga Os 4 require MMU.
On WinUAE ppc emulation have MMU and JIT at the same time.

@matthey

Quote:

Where is the new 68k Amiga development with hundreds of thousands of units using emulation of the 68k Amiga already sold?

nobody sane waste time for making software for emulator

@agami

Quote:

So why not port AmigaOS 4 to x64 or ARM64

it should be just amiga gui and graphics on top of unix.
nobody stop you stop trolling start working on mui.

@agami

porting Amiga Os 4 to emulated 68k is simply stupid
just use winuae

@ppcamiga1

Quote:

nobody sane waste time for making software for emulator

Luckily there’s plenty of “insane� developers.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@ppcamiga1

Quote:

ppcamiga1 wrote: @agami Quote: So why not port AmigaOS 4 to x64 or ARM64 it should be just amiga gui and graphics on top of unix.

Which unix should that be?

Quote:

nobody stop you stop trolling start working on mui.

MUI is closed source, only available to its developers.

There are far more advanced and modern options existing for unix already, so why bother with MUI?

MUI relies on Intuition and BOOPSI, but there is no Intuition nor BOOPSI on unix, so what do you suggest then? Oh and… X11, Wayland, or something else, like native unix (whichever you want) Intuition?

Last edited by kolla on 01-May-2024 at 11:21 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC