@matthey

Like I said, it depends on the workload. Here's some quotes from people who've had these discussions already years ago:

Quote:

> > There are lots of things one CPU could do more simply than another, > > but, normally, there were others that went the other way. I remember, > > back in '80 or so, demonstrating that the 4 MHz 6502 was considerably > > faster and more code efficient than the 8 MHz 68000. This was, of > > course, because the 8 MHz 68K had to fetch two words just to get its > > opcode, though it didn't take long to execute it once the opcode and > > operands were in place. > > In 1980, most 8-bit CPUs were more efficient that the 68000 in terms of > code size as long as you limited yourself to 64K. When you got past 64K, > the 68000 scaled smoothly while programming the 8-bitters became a Chinese > fire drill. > Yes, and the 80x86's of the late-'70's-early '80's fell between the two, being a "Chinese fire drill" either way. It was astonishing, however, to find that a $6 8-bitter performed simple tasks 10x as fast as a $150 "32-bitter."

Anyway, as I said before, ARM won.
In 1987, an ARM1 cpu was 8x faster than 68000 at the same clock speed.

Last edited by Lou on 13-May-2024 at 04:03 AM.

@Lou

Quote:

Anyway, as I said before, ARM won. In 1987, an ARM1 cpu was 8x faster than 68000 at the same clock speed.

ARM2 was introduced in 1986. Acorn Archimedes family of personal computers was built using the ARM2 and the first models were introduced in 1987.

ARM2's MIPS results can be bottlenecked by memory bandwidth.

ARM2 is Doom-capable. Too bad Archimedes wasn't optimized for 2D games.

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

@bhabbott

Quote:

bhabbott wrote: Quote: matthey wrote: The Los Gatos group survived this round of layoffs and competed for the Amiga 2000 and 500 designs which they lost as CBM management moved further and further form Jay's vision. It doesn't say if Thomas or the remaining Los Gatos team was let go first but it doesn't really matter as both had lost power. Which was good because Jay's vision was a bad one. The A500 was the only really successful Amiga, and he was against it. His 'Ranger' design was awful. CBM management were right to choose the A2000 over it. Unfortunately Commodore didn't 'stray' far enough. Instead of building on the strengths of the A500 and A2000 they created the loss-making A3000 and CDTV, and spent years trying to make a high-end graphics chipset while not doing much to improve the low end - until AGA (which should have been made a priority and released at least a year earlier).

That's a flawed argument for running a proper tech hardware company.

AMD has separate engineering teams for at least the current generation and for the next generation. This is applicable for CPU and GPU business.

Intel is known to run parallel and overlapped engineering teams for P5, P6, and P7.
Intel released P5 in 1993, P54 in 1994, P6 G1 in 1996, P55 in 1997 and P6 G2.

1987 A2000 didn't properly address stable high resolution for the larger professional market
such as DTP, WYSIWYG word processing until 1990 released ECS Denise which is too late for 4 color 640x400p when the competition has stable 16 color 640x480 VGA baseline and 256 color 640x480 and beyond.

Apple had stable high-resolution monochrome, 16, and 256 colors unified under Quickdraw in 1987, hence the Mac dominates the larger professional DTP and WYSIWYG word processing markets.

The Amiga had games and small niche Video Toaster markets.

Flicker Fixer Amber with frame buffer solution is expensive due to no access to economies of scale. A2024 monitor is a hack with limited economies of scale.

The PC had MS Word 2.0 Mac port in 1989 with Windows 2.x. MS Word 2.1 with Windows 3.0 in 1990.

Last edited by Hammer on 13-May-2024 at 06:07 AM.
Last edited by Hammer on 13-May-2024 at 06:02 AM.

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

@matthey

Quote:

I wouldn't call the 68000 ISA a mistake

For example, 68010 has corrective instruction set changes for Popek and Goldberg virtualization requirements.

68010 can support virtual memory, but Unix requirements change over time. Motorola was late with MMU integration and didn't guarantee standard MMU mass rollout.

Quote:

There is nothing wrong with it for the embedded market. It was adequate for the desktop market as the choice by Mac, Amiga and Atari shows who all could have used the 68010 (the Amiga could have used the 68000 for a game machine and the 68010 for the desktop).

Requirements change over time.

68010 can support virtual memory, but Unix requirements change over time. Motorola was late with MMU integration and didn't guarantee standard MMU mass rollout.

Motorola had opportunities with the smart handheld market and lost it like on desktop and workstation markets.

A2000 with 68010 is meaningless when mass produced baseline is 68000 instruction set.

You're repeating the same product segmentation as Motorola's.

Quote:

The 68000 ISA was adequate for the workstation market which the 68000 created even though some customers wanted better MMU support. The 68000 ISA is better than some other 68k ISAs. If I were to give grades for the ISAs, they would be something like the following.

Unix requirements change over time and Motorola was late with MMU integration and didn't guarantee standard MMU mass rollout.

386's integrated MMU appeared before PC's 32-bit OS was even ready.

During the 1985 and OS/2 development, Bill Gates wanted direct 386 support while IBM wanted OS/2 to be 286.

Due to IBM's slow OS/2 development pace and bad licensing policies, Microsoft hired David Cutler in 1988 to lead the Windows NT project.

You're repeating the same product segmentation as Motorola's.

Quote:

68000 A- 68010 A- 68020 C CPU32 A ColdFire D

Dragon Ball's CPU32 has missing instructions from 68020's ISA.


Quote:

Notice I didn't change the grade from the 68000 to the 68010. The 68000, 68010 and 68020 ISAs were challenging as they were general purpose ISAs targeting embedded, desktop and workstation markets. The CPU32 and ColdFire ISAs were targeting the embedded market only which is much easier. The fact that there were so many ISAs is a standardization failure by Motorola which is worse than any 68000 ISA "mistake". Was it really that bad to be able to read the whole SR from user mode?

Motorola had opportunities with the smart handheld market and lost it like on desktop and workstation markets.

The smart handheld market evolved into memory-protected Linux with security requirements.

The smart handheld market has separated from the embedded market.


Quote:

Most low end in-order RISC CPU cores need instruction scheduling to have any performance at all. Load-to-use stalls are performance killers that don't exist for CISC cores (instruction scheduling is highly recommended even with PPC limited OoO). The PPC 603 with only one simple int unit contributes to making instruction scheduling impossible with resulting pipeline stalls. The 68060 and 6x86 did a good job of showing the performance advantage of CISC for existing and unoptimized code as these good CPU designs received less developer support but generally had good performance. The SiFive U74 core is a step in the right direction for RISC cores with a deliberate design intention of reducing stalls and making scheduling easier. Of course, a CISC like pipeline design was used even though RISC-V is the ISA least able to take advantage of performance gains.

PalmOS 5.0 on ARM925T @ 144Mhz with 68K emulator beats the previous DragonBall VZ (MC68VZ328, 33Mhz) based Plam device.

"Palm applications usually run faster on ARM devices than on previous generation hardware".

PalmOS 5.0 ditched the Kadak AMX68000 kernel.

Quote:

CISC FPUs and SIMD untis should have a significant performance advantage over RISC FPUs but early CISC FPUs had more limited transistor budgets as integer pipelining used more transistors partially offset by fewer GP registers needed. Most 68k FPU instructions only allow "Fop mem-reg" accesses and not "Fop reg-mem" accessed which gets most of the performance advantage with reduced complexity (no RMW FPU instructions). The 68060 minimalist FPU is likely due to trying to save transistors for caches (68060+) and targeting the embedded market where FPU performance is not as important. The 68k FPU ISA has more performance potential than the x86 FPU and most RISC FPU ISAs but heavy FPU using code would benefit from doubling the FPU registers from 8 to 16. An ABI that passes function fp args in extended precision registers instead of as double precision args on the stack would be a big improvement as well.

ARM's point of entry with Palm OS 5 is with ARM925T which displaced DragonBall VZ (MC68VZ328, 33Mhz).


"Palm applications usually run faster on ARM devices than on previous generation hardware".


The "68060" is unsuitable for Palm Tungsten T size device.


X87 FPU has changed into X86-64v1's 16 registers SSE2 and X86-64v4's 32 registers AVX-512. Closing the stable door after the horse has bolted is not wise.

AVX-512 is mainstream with AMD's desktops PCs regardless of Intel's stall tactics.
https://www.anandtech.com/show/21392/amd-hits-record-high-share-in-x86-cpus-in-q1-2024

AMD's current CPU market share (23.9%, Q1 2024) has passed K7's golden era 20 percent market share for a brief period in 2000(1). K8 reached 17.8 percent market share(1).

Reference
1. https://www.cnet.com/tech/tech-industry/amds-market-share-gains-accelerate/

Quote:

Most low end in-order RISC CPU cores need instruction scheduling to have any performance at all. Load-to-use stalls are performance killers that don't exist for CISC cores (instruction scheduling is highly recommended even with PPC limited OoO). The PPC 603 with only one simple int unit contributes to making instruction scheduling impossible with resulting pipeline stalls.

PowerPC 603 @ 80Mhz benchmark

SPECint92 est = 75
SPECfp92 est = 85

Reference
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=31d6672d1ffb70f2d0183bcc1f82548739b22ff6


Quote:

The 68060 and 6x86 did a good job of showing the performance advantage of CISC for existing and unoptimized code as these good CPU designs received less developer support but generally had good performance. The SiFive U74 core is a step in the right direction for RISC cores with a deliberate design intention of reducing stalls and making scheduling easier. Of course, a CISC like pipeline design was used even though RISC-V is the ISA least able to take advantage of performance gains.

You're mixing up embedded processors with the application processor market.

Google dumped RISC-V from Android support.

My RTX GPU has custom RISC-V and it's meanless for 3rd parties.


Quote:

I believe Bill Mensch and his WDC early fabless semiconductor development capabilities were at least on par with ARMs. The 6502 is a minimal silicon CPU that was and is perfect for many low end low cost CPUs.

ARM had direct VLSI Inc. support.

Quote:

The x86 ISA has less upgrade potential than the 68k ISA but it was done anyway.

Such prophecy is proven false. AMD Zen 5 and Intel Arrow Lake are coming this year.

X86 has a unified desktop platform with PC clones. Software sells the hardware.

Quote:

The 68k has less memory traffic, better code density and has fewer instructions to execute than x86.

68000's four cycles on 16-bit bus access is not less memory traffic.

X86 hardware implementation has a superior data locality.

Quote:

The x86 encoding map is full resulting in a further decline in code density as new instructions were added and used.

AVX-512's single gather instruction beats multiple read instructions from 68K.

Last edited by Hammer on 13-May-2024 at 07:28 AM.

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

@bhabbott

from the site:
However, the sound system may have still been the same as the original chipset. According to R. J. Mical, the new chipset kept the original 13 bit DAC for its CLUT but with quadrupled color registers from 32 to 128. The color palette would have remained at 4096 colors but the resolution could go up to 1024×1024 pixels with 128 colors (7 bit color depth). Additionally the chipset can address up to 2 MB of Chip RAM space.

I still regret that Jay Miner and the others left Commodore. It was the beginning of the end already

@Matt3k

FYI, My early year 2000s PC had a Motorola 56300-based digital signal processor (DSP) on the motherboard The original Xbox also has Motorola 56300-based DSP.

NVIDIA didn't reveal the DSP design behind their SoundStorm.

Last edited by Hammer on 13-May-2024 at 12:13 PM.
Last edited by Hammer on 13-May-2024 at 12:12 PM.

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

@Lou

Quote:

In 1987, an ARM1 cpu was 8x faster than 68000 at the same clock speed.

The 68000 did come out in 1979.
Why compare with an 8 year old CPU?
You should compare it with a CPU of the same age.

Would it not make a lot more sense to compare it with 68020 or 68030?
As these are the 68K CPU having the same age.

@Thread

The failed because the suits didn't understand the value of the 68k architecture and gave it up for the sub-prime PPC architecture, didn't follow Moore's law and basically went all in with the mobile phone market where Apple won supreme and "Hello Moto!" didn't cut it!

Last edited by BigD on 13-May-2024 at 05:11 PM.

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

@Gunnar

68030 is not in mid-range price in 1987.

Was there an Amiga with 68030 @ 50 Mhz for 800 UKP in 1987?

Motorola's 68030-25 was following Intel's 386DX-25 wholesale prices in the early 1990s.

Last edited by Hammer on 13-May-2024 at 05:38 PM.

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

Apple sold 16 MHz 030+882 Mac IIx from 1988, for close to USD 8000.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

NeXTStation, 25 MHz 68040, 8 MB RAM, 100 MB SCSI drive, ethernet and monitor - 1990, USD 4995

Amiga A3000, 16 MHz 68030+882, 2 MB RAM, 40 MB SCSI drive, no ethernet, no monitor… 1992 - USD 3379

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Lou Quote:

Like I said, it depends on the workload. Here's some quotes from people who've had these discussions already years ago:

First of all, they compare an 8MHz 68000 to a 4MHz 6502 which is a lot closer than a 1MHz 6502. This is what I was trying to explain to you. The 6502 is still only close when using small code and 8 bit datatypes. The "more code efficient" comment is bull as the 68000 fetches one 16 bit word at a time where the 6502 fetches one byte at a time. I've heard similar arguments from people trying to justify byte encodings which are less efficient than 16 bit encodings that provide better code density. There were a few 8 and 16 bit CPUs like the 8086 and Z80 that had competitive code density with the 68000 for small programs but the 68000 had very competitive code density and usually better code density for medium to large programs. Code density was improved for the 68020 (and ColdFire code density improvements are possible on top of this) but the 8086 and ARM Thumb2 code densities are better in some cases. Code density declined from the 8086 to x86 and further with x86-64. Code density for the 6502 was poor.

http://deater.net/weave/vmwprod/asm/ll/ll.html

The 68000 reduced memory traffic more than the code density competition as memory traffic is a combination of code traffic and data traffic. The 68000 orthogonal ISA and 16 GP registers reduced data traffic and the number of instructions to execute.

Lou Quote:

Anyway, as I said before, ARM won. In 1987, an ARM1 cpu was 8x faster than 68000 at the same clock speed.

The 68000 was only 4 years after the 6502 while ARM1 was 6 years after the 68000. You are comparing a 6 year older 16 bit CPU to a 32 bit CPU.

1974 6800 8-bit
1975 6502 8-bit
1978 8086 16-bit
1979 68000 16-bit
1982 68010 16-bit
1984 68020 32-bit
1985 ARM1 32-bit
1986 ARM2 32-bit
1987 68030 32-bit

ARM1 initially had a max clock of 6MHz while the 68000 initially had a max clock of 8MHz and likely 12MHz or 16MHz CPUs by that time (68HC000 started production in 1986). This makes the 68000 faster. You are likely talking about performance though. ARM1 didn't see much use outside R&D so we are better off comparing the 1979 68000@8MHz to the 1986 ARM2@8MHz. ARM2 is a 32 bit CPU with 32 bit data bus while the 68000 is a 16 bit CPU with 16 bit data bus. ARM2 was designed for the fastest possible memory operation at the time and upgraded with new ARM versions while the 68000 was designed for 1979 memory with lenient timing so cheaper memory could be used. This may be where the ARM2 is 7 times faster comes from as it may have 6.5 times the memory bandwidth of the 68000 even though this doesn't translate into 6.5 times the performance? ARM2 has a 3 stage pipeline like the 68020 and 68030 while the 68000 is generally not considered pipelined. ARM2 and the 68000 have no cache while the 68020 has a small 256 byte instruction cache and the 68030 adds a 256 byte data cache. The 68000, 68020 and 68030 used microcode which is slower than the ARM2 not using any microcode. ARM2 performance was good but it was more difficult to optimize and 68k CPUs didn't need as much microcode with longer pipelines where performance soon surpassed ARM.

year | in-order CPU (core) | DMIPS/MHz | pipeline
1979 68000 0.16 1-stage
1984 68020 0.30 3-stage
1986 ARM2 0.35 3-stage (Be careful of claims like 0.50 which are likely VAX MIPS)
1987 68030 0.36 3-stage
1990 68040 1.10 5-stage
1994 68060 1.80 8-stage
2005 Cortex-A8 2.0 13-stage
2011 Cortex-A7 1.9 8-stage (went back to more practical 8-stage pipeline)
2012 Cortex-A53 2.3 8-stage

ARM required more than a decade, much newer silicon and much larger caches to reach the integer performance/MHz of the 68060 (I believe their first OoO core was the 2007 Cortex-A9 at 2.5DMIPS/MHz).

The ARM2 CPU core was small making the chip cheaper to produce but more pins were required than the 68000 offsetting this advantage. Code for ARM2 is about 70% larger than 68k code (68k code has about 40% better code density) wasting part of the memory bandwidth and using valuable and expensive memory and ROM space (A305 Archimedes used twice the ROM size compared to the 68k Amiga). The ARM2 Archimedes had a higher performance CPU than the 68000 Amiga but it came at a cost.

1987 Acorn Archimedes A305 ARM2@8MHz 512kiB-mem(~125ns) 512kiB-ROM ~£700
1987 Amiga 500 68000@~7MHz 512kiB-mem(~150ns) 256kiB-ROM ~£500

The 68k Amiga strategy was to offload the CPU with DMA hardware. The ARM2 strategy was to simplify hardware and use the CPU to avoid expensive DMA hardware.

36C3 - The Ultimate Acorn Archimedes talk
https://www.youtube.com/watch?v=Hf67JYkUCHQ

A 68k Apollo workstation was used in development of ARM CPUs by the ~12 man development team on a budget. They did a good job but they probably would have been better off using the 68k. It is difficult to introduce a completely new ISA but there have now been 4 ARM ISAs so I guess they became experienced at do overs. ARM was really slow to catch on and it didn't happen until after the 68k and then SuperH dominated the embedded market. It was only when ARM changed ISAs to the much better code density Thumb ISA after a license of SuperH from Hitachi, a 2nd source 68k producer, that their fortunes started to change. Weak performance limited them to low power embedded markets. Poor performance/MHz is actually bad for the embedded market as clock rates need to be increased but high clock rates are good for marketing.

Last edited by matthey on 16-May-2024 at 06:36 PM.
Last edited by matthey on 14-May-2024 at 12:37 AM.

@matthey

3DO''s Doom port was mostly processed on ARM60 (ARMv3) @ 12.5Mhz without hardware acceleration.

https://www.youtube.com/watch?v=Nx2k8jrCOUU&t=9006s
The result is like close to 68030 @ 50 Mhz

https://www.youtube.com/watch?v=1B1jKjrRUmk
Doom on 68030 @ 50 Mhz + AGA vs Am386 @ 40 Mhz + ET4000AX.

ARM6 (ARMv3) was released in 1991. ARM6 microarchitecture was used for the ARM60, ARM600, and the ARM610.

Like the 68020, ARM6 has a hardware barrel shifter to assist soft bilt. ARMM2 has a hardware barrel shifter to assist soft bilt.

3DO has 2 million unit sales.

3DO's ARM60 usage was due to VLSI Inc's marketing of ARM. VLSI Inc. is not a neutral fab contractor.

For large ROM'ed microcode CISC CPU designs, the RISC threat is real.

Released in 1989, 486 was 1st CISC CPU design with most of its instructions not being ROMed microcode. 68040 was released in 1990.

Again, http://archive.computerhistory.org/resources/access/text/2013/04/102723315-05-01-acc.pdf
Page 89 of 417, DataQuest 1995 report's worldwide market share for 1994
SuperH wasn't a major player. SuperH is mostly "Japan Inc" embedded CPU.

RISC CPU with 1% marketshare in 1994 are AM29000, R3000/R4000 MIPS and SPARC.

Within R3000/R4000 MIPS's 1 percent market share, LSI had 52%, IDT had 35% and NEC had 8%.

Within 68000's 17% percent market share, Hitachi has 8%, Motorola has 83%, Toshiba has 6%, SGS-Thomson has 3%.

Motorola's 683XX (68000, kitbashed 68020 based CPU32) has 9% market share.

N64 (32 million units) is powered by R4x00 MIPS and PS1 (102.4 million units) is powered by R3000 MIPS.

Saturn (SuperH2) has only 12 million unit sales. Dreamcast (SuperH4) has 9.13 million unit sales.

https://www.riscosopen.org/forum/forums/11/topics/14754
Acorn Archimedes was a sales flop.
Quote:

500,000 RISC OS systems shipped as of July 1996.

Archimedes wasn't considered a threat to the Amiga or the Apple Mac.

Quote:

matthey: The 68k Amiga strategy was to offload the CPU with DMA hardware. The ARM2 strategy was to simplify hardware and use the CPU to avoid expensive DMA hardware.

Amiga's custom chips were designed to saturate the available memory bandwidth since 68000 's MIPS wasn't good.

Last edited by Hammer on 14-May-2024 at 02:46 AM.
Last edited by Hammer on 14-May-2024 at 02:39 AM.
Last edited by Hammer on 14-May-2024 at 02:31 AM.
Last edited by Hammer on 14-May-2024 at 01:12 AM.
Last edited by Hammer on 14-May-2024 at 01:09 AM.
Last edited by Hammer on 14-May-2024 at 01:06 AM.
Last edited by Hammer on 14-May-2024 at 12:50 AM.
Last edited by Hammer on 14-May-2024 at 12:46 AM.

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

@Gunnar

Quote:

Gunnar wrote: @Lou Quote: In 1987, an ARM1 cpu was 8x faster than 68000 at the same clock speed. The 68000 did come out in 1979. Why compare with an 8 year old CPU? You should compare it with a CPU of the same age. Would it not make a lot more sense to compare it with 68020 or 68030? As these are the 68K CPU having the same age.

I did compare the 6502 to the 68000. Where were you?
Did you miss the part where ARM is simply an evolution of the 6502?

Here is a 1.2Mhz C128 running a 3D maze Doom-like demo. Extra memory was used to unroll loops and go to 2Mhz mode in the borders to net 1.2Mhz as well as extra feature like relocatable stack and zero page for a 160% improvement over the C64 version. Now we can see why the Atari (1.79Mhz) was a better 3D machine than the C64...

https://www.youtube.com/watch?v=1tDflgqJlTw

Also, let's face it, the C128-enhanced version of Eye of the Beholder is the best version of the game:
https://www.youtube.com/watch?v=V2IWyzAVVBQ

Finally, a 7.16Mhz 6502 and a good graphic chip vs the Amiga ports are uncomparable:
https://www.youtube.com/watch?v=TZaMuFwaJgA
A more apples to apples comparison: TG-16 vs Genesis:
https://www.youtube.com/watch?v=qOXTWCSAyDs

Last edited by Lou on 14-May-2024 at 03:36 PM.
Last edited by Lou on 14-May-2024 at 03:29 PM.

@kolla

Quote:

kolla wrote: NeXTStation, 25 MHz 68040, 8 MB RAM, 100 MB SCSI drive, ethernet and monitor - 1990, USD 4995 Amiga A3000, 16 MHz 68030+882, 2 MB RAM, 40 MB SCSI drive, no ethernet, no monitor… 1992 - USD 3379

It seems there was a price list blackout for Amiga models during the US's 1991 and 1992 Amiga World magazines.

https://archive.org/details/Australian_Commodore_and_Amiga_Review_The_Volume_9_Issue_3_1992-03_Saturday_Magazine_AU/page/n27/mode/2up
From Australia's Amiga Review March 1992, Page 28 of 84

Amiga 3000 has $3350 AUD for 030/822@ 25Mhz with 52 MB HDD.

AUD is usually 30 percent weaker than USD.

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

Hammer Quote:

3DO''s Doom port was mostly processed on ARM60 (ARMv3) @ 12.5Mhz without hardware acceleration. https://www.youtube.com/watch?v=Nx2k8jrCOUU&t=9006s The result is like close to 68030 @ 50 Mhz

The 3DO ARM60@12.5MHz does not have any cache despite other ARM3 cores receiving a 4kiB unified cache. The 3DO hardware has 1MiB of VRAM, which CBM nixed for the Ranger chipset, and 3MiB of memory standard. The 3DO hardware was designed by Dave Needle and RJ Mical who had been Amiga Corporation developers affected by the Ranger chipset and VRAM denial by CBM. Now CBM was feeling the pain with their new but low spec 68EC020@14MHz AGA and 2MiB DRAM standard. They would have been more competitive with 68EC030@28MHz AA+ and 2MiB of VRAM.

Hammer Quote:

3DO's ARM60 usage was due to VLSI Inc's marketing of ARM. VLSI Inc. is not a neutral fab contractor.

Right. VLSI was a valuable business partner helping the small ARM team develop ARM on a budget. ARM CPU cores may not exist today without them.

When I was on the AC team, I found a business partner that specializes in creating ASICs and was interested in helping to create a 68k ASIC they could market for embedded use. Gunnar acted excited by the interest but then became suspicious about his precious and ignored me. I was also talking to a potential embedded business partner planning very high production IoT hardware who could have potentially improved economies of scale but that wasn't going to work with closed hardware and Gunnar protecting his precious either.

Hammer Quote:

For large ROM'ed microcode CISC CPU designs, the RISC threat is real. Released in 1989, 486 was 1st CISC CPU design with most of its instructions not being ROMed microcode. 68040 was released in 1990.

CISC ISAs have to loop through short pipelines to execute one instruction which is complex and better done with microcoding. RISC instructions are simpler and most instructions can execute in a shorter pipeline with no microcoding needed. The classic 5-stage RISC pipeline is optimum for executing RISC instructions but a longer pipeline gives more instruction level parallelism (ILP) and a higher max clock speed. A pipeline of 7-9 stages has worthwhile performance gains without requiring too expensive of branch prediction and pipeline refill costs. Many RISC CPU core designs pipeline the load/store unit separate from executing instructions and the deeper the pipeline the larger the load-to-use stall after a load. This is a major reason why RISC pipelines do not gain as much performance from more pipelining with OoO execution often providing more of a performance gain. CISC cores with adequate hardware become more powerful as they execute more powerful instructions with what is like unrolling a loop through the pipeline which was done with microcode and limited hardware resources. CISC instructions are designed to take advantage of this with the equivalent of 2 RISC instructions per "OP_ALU mem-reg" access and complex addressing modes also requiring multiple instructions for RISC. Also, most CISC designs avoid the load-to-use stalls as the mem/cache access is pipelined with the execution of the instruction. Longer CISC pipelines not only become much more powerful but they become simpler with more dedicated hardware instead of shared hardware used in loops through the pipeline. Some short CISC pipelines used microcoding for control of practically everything while longer CISC pipelines that use microcoding usually use it less and for translation of old instructions to new instructions that are easier to execute in the pipeline. Some RISC cores use microcoding for the same reason. IBM POWER cores use microcoding and POWER now uses a variable length encoding that is far from efficient to support ISA baggage. The 68060 does not use microcoding at all showing how much less baggage it has. Granted, the 68060 cut some of the baggage from hardware choosing traps to maintain compatibility instead and even went too far in this pursuit but there were much more limited resources back then.

Hammer Quote:

Acorn Archimedes was a sales flop.

Archimedes had more of a software problem than the Amiga and it was more expensive. The Archimedes CPU and hardware was competitive with the Amiga CPU and hardware. The Archimedes CPU performance was better but the Amiga chipset performance was better and offloaded the CPU allowing cheaper hardware to be used. Archimedes hardware competed in colors and sound with the Amiga. It's too bad it didn't receive more support but ARM was new and didn't have as much developer support as the 68k. It is difficult to introduce a new ISA and gain developer support which is why it is so sad to see developer support for the 68k fading away.

Hammer Quote:

Amiga's custom chips were designed to saturate the available memory bandwidth since 68000 's MIPS wasn't good.

Game machines poked the chipset hardware registers back then and the hardware did the work. Jay Miner wanted more CPU power for a PC and fortunately talked the game machine people out of a 68008. Unfortunately, CBM used the offloading of the CPU by the chipset to use cheaper embedded 68k CPUs rather than upgrade the 68k CPU standard like Jay wanted.

Lou Quote:

I did compare the 6502 to the 68000. Where were you? Did you miss the part where ARM is simply an evolution of the 6502?

In some ways ARM is like the 6502 and a spiritual successor. They both simplify the hardware, both employ pipelining techniques to improve performance, both try to maximize memory bandwidth, both try to minimize the core size and both ignore code density. In some ways they are very different though. The 6502 is an accumulator architecture while ARM is a load/store RISC architecture with more orthogonal GP registers, ARM supports larger datatype sizes and more (26 bits=64MiB) of flat address space and 6502 and ARM code are not similar. The ARM Archmides version of Elite contains a 6502 emulator while the 68k Amiga version uses native 68000 assembly code. I expect it is much easier to convert 6502 code to 68k code because the 68k has a richer, more flexible and more forgiving but more complex ISA than the ARM ISA.

David Braben's Elite was one of early 3D games which was developed on a 6502@2MHz Acorn machine but with less memory than a C64. There is a good video where David talks about development.

Classic Game Postmortem - ELITE by David Braben
https://www.gdcvault.com/play/1014628/Classic-Game-Postmortem

David mentions the Amiga not having a division instruction which is not true but it is likely that a table was still used for 8 bit datatypes just like the 6502 because it is faster for 8 bit datatypes unlike 16 bit datatypes where a 16 bit table would also use a lot of memory. He mentions the memory cost of the table for 8 bit datatypes which was far from free on early 8 bit systems.

Lou Quote:

Here is a 1.2Mhz C128 running a 3D maze Doom-like demo. Extra memory was used to unroll loops and go to 2Mhz mode in the borders to net 1.2Mhz as well as extra feature like relocatable stack and zero page for a 160% improvement over the C64 version. Now we can see why the Atari (1.79Mhz) was a better 3D machine than the C64...

The following video about the CMD SuperCPU 65816@20MHz accelerator for the Commodore 64 gives a good example of a higher clocked 6502 family CPU and the limitations of performance due to memory.

Exploring the SuperCPU Accelerator for C64
https://www.youtube.com/watch?v=x9clez2fxxw

The 65816@20MHz accelerator has an optional SRAM expansion that allowed performance to increase from roughly 8 times to 20 times that of the original C64. Memory performance is very important for CPU performance without caches. This accelerator with fast memory gives the C64 many times the CPU performance of a 68000 Amiga but the dynamic 68k Amiga design is much less limited with many programs being able to use additional memory and more programs working with additional performance. A high clocked in-order Super68k Amiga today using SRAM the size of original Amiga standards may be able to compete in CPU performance with all but the highest performance OoO CPUs. SRAM is what caches are made from so it is like never having a cache miss when executing code from SRAM. This is why even primitive 6502 MCUs using on-chip SRAM can have surprising performance without the need to clock them up. The 6502 is not a good choice if larger datatypes are needed or slower memory is used. Not even in upgraded 16 bit forms which still have too much memory traffic, poor code density and too many instructions to execute.

Last edited by matthey on 14-May-2024 at 06:45 PM.

@matthey

Quote:

The 3DO ARM60@12.5MHz does not have any cache despite other ARM3 cores receiving a 4kiB unified cache.

What matters is performance per dollar (i.e. bang per buck) and performance target. 3DO designers wanted 68030 @ 50 MHz performance without paying for it.

The good old Doom benchmarks.

Quote:

The 3DO hardware has 1MiB of VRAM, which CBM nixed for the Ranger chipset, and 3MiB of memory standard.

3DO has 2 MB system RAM and 1 MB VRAM.

Quote:

The 3DO hardware was designed by Dave Needle and RJ Mical who had been Amiga Corporation developers affected by the Ranger chipset and VRAM denial by CBM. Now CBM was feeling the pain with their new but low spec 68EC020@14MHz AGA and 2MiB DRAM standard. They would have been more competitive with 68EC030@28MHz AA+ and 2MiB of VRAM.

CLIO @ 24.5454 Mhz has a 32-bit link with VRAM. CLIO has a display generator.

MADAM @ 25 Mhz has links with VRAM and DRAM.

MADAM has
1. A custom math co-processor i.e. CornerEngine. CornerEngine has vertex and transformation, and 4*4 matrix math : multiplication by another 4*4 matrix, multiplication by vector, dot product, and rotation. Fixed point.
2. CEL engine which handles quadrilateral textures. Like Sega Saturn, 3DO's mistake is with the quadrilateral 3D system.

3DO's VRAM has dual ports.

ARM60 CPU has links with system RAM and VRAM.

A1200 could close the gap with the following:
1. DSP3210 @ 50 Mhz for the math power against CornerEngine.

$20 DSP3210 is dual pipelined with fixed point integer and floating units. AT&T marketed DSP3210 as "3D and multimedia DSP".

25 MFLOPS FP32 offers an alternative to fixed point 3D.

DSP3210 @ 50 Mhz has 12.5 MIPS and 25 MFLOPS FP32.

Apple Quadra 840av had 66 Mhz DSP3210 and 40 Mhz 68040.
Apple Quadra 660av had 55 Mhz DSP3210 and 25 Mhz 68040.

2. 68EC020-28 Mhz against ARM60 @ 12.5 Mhz. There's a minor $3 difference between 68EC020-14 and 68EC020-25.

68EC030-25 PQFP = $35.94

Again, https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf
Page 119 of 981

For 1992
68000-12 = $5.5
68EC020-16 PQFP = $16.06, it's $15 in 1993 Q1.
68EC020-25 PQFP = $19.99, it's $18 in 1993 Q1.

68EC030-25 PQFP = $35.94
68030-25 CQFP = $108.75, it's $92.00 in 1993.

68040-25 = $418.52, it's $337.50 in 1993.
68EC040-25 = $112.50 (useless for the Amiga)

---
Competition

AM386-40 = $102.50, it's $42.75 in 1993.
386DX-25 PQFP = $103.00, it's $55.25 in 1993

486SX-20 PQFP = $157.75, It's $87.75 in 1993.
486DX-33 = $376.75, it's $205.75 in 1993.
486DX2-50 = $502.75, it's $275.00 in 1993.

Discounts are not included.

PC's mass MMU deployment destroys Motorola. Motorola didn't create a *nix future for itself.


Quote:

Right. VLSI was a valuable business partner helping the small ARM team develop ARM on a budget. ARM CPU cores may not exist today without them. When I was on the AC team, I found a business partner that specializes in creating ASICs and was interested in helping to create a 68k ASIC they could market for embedded use. Gunnar acted excited by the interest but then became suspicious about his precious and ignored me. I was also talking to a potential embedded business partner planning very high production IoT hardware who could have potentially improved economies of scale but that wasn't going to work with closed hardware and Gunnar protecting his precious either.

Standard 68K MMU would help for Linux68K and it would be independent from AmigaOS-related politics.

Raspberry Pi 3/4/5 is mostly Linux ARM.

VLSI promoted ARM CPUs to other customers and one of them is 3DO. VLSI is not a neutral fabless contractor.

Quote:

In some ways ARM is like the 6502 and a spiritual successor. They both simplify the hardware, both employ pipelining techniques to improve performance, both try to maximize memory bandwidth, both try to minimize the core size and both ignore code density. In some ways they are very different though. The 6502 is an accumulator architecture while ARM is a load/store RISC architecture with more orthogonal GP registers, ARM supports larger datatype sizes and more (26 bits=64MiB) of flat address space and 6502 and ARM code are not similar. The ARM Archmides version of Elite contains a 6502 emulator while the 68k Amiga version uses native 68000 assembly code. I expect it is much easier to convert 6502 code to 68k code because the 68k has a richer, more flexible and more forgiving but more complex ISA than the ARM ISA.

ARM's main entry point is with "smart" handheld devices which diverged from the embedded markets Freescale Dragonball.

ARM scored big with 2 million 3DOs despite Acorn's Archimedes is a platform failure.

From Nov 2023, ARM Holdings PLC has gained the minority ownership of Raspberry Pi Ltd. Raspberry Pi's RISC-V road map went silent.

Quote:

Game machines poked the chipset hardware registers back then and the hardware did the work. Jay Miner wanted more CPU power for a PC and fortunately talked the game machine people out of a 68008. Unfortunately, CBM used the offloading of the CPU by the chipset to use cheaper embedded 68k CPUs rather than upgrade the 68k CPU standard like Jay wanted

For the Amiga, 68000 was used to host the 32-bit OS and the command director for Amiga's value-added multimedia custom chips since 68000's low MIPS is unable to saturate the given 16 bit bus.

Prove 68000 @ 7.1 Mhz can do an average 3.5 MIPS for 3.5 MB/s let alone 7 MB/s for 7 MIPS.


Quote:

The 65816@20MHz accelerator has an optional SRAM expansion that allowed performance to increase from roughly 8 times to 20 times that of the original C64. Memory performance is very important for CPU performance without caches. This accelerator with fast memory gives the C64 many times the CPU performance of a 68000 Amiga but the dynamic 68k Amiga design is much less limited with many programs being able to use additional memory and more programs working with additional performance. A high clocked in-order Super68k Amiga today using SRAM the size of original Amiga standards may be able to compete in CPU performance with all but the highest performance OoO CPUs.

Modern OoO X86-64v4 has GPU-like gather/scatter vector (AVX-512) extensions and it crushes "Super 68060".

When pipelines are lengthened, the Reorder Buffer is also larger as "instructions in flight" are also larger.

The purpose of X86-64 levels is to optimize compiled Linux for modern X86-64 with newer SIMD extensions instead of being stuck in baseline X86-64v1 or IA-32.

Windows 11 H2 2024 update will also follow Linux's X86-64v2 i.e. Intel Nehalem being the minimum instruction set (excluding Intel-specific instructions).

Last edited by Hammer on 15-May-2024 at 06:39 AM.
Last edited by Hammer on 15-May-2024 at 03:49 AM.
Last edited by Hammer on 15-May-2024 at 03:39 AM.
Last edited by Hammer on 15-May-2024 at 03:36 AM.
Last edited by Hammer on 15-May-2024 at 03:34 AM.
Last edited by Hammer on 15-May-2024 at 03:27 AM.
Last edited by Hammer on 15-May-2024 at 03:12 AM.

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

@Lou

6502 operates on the leading and falling edge (double rate), hence 7.16 Mhz 6502 is effectively 14.32 Mhz leading edge cycle.

Commodore had a double-rate processing CPU IP in their hands with good potential. 32-bit ALU equipped 65xx update would be pretty good.

Quote:

Lou wrote: Also, let's face it, the C128-enhanced version of Eye of the Beholder is the best version of the game: https://www.youtube.com/watch?v=V2IWyzAVVBQ

https://www.youtube.com/watch?v=wDaTGdQVZ6o
Amiga AGA had PC's Eye of the Beholder II VGA port.

Quote:

Finally, a 7.16Mhz 6502 and a good graphic chip vs the Amiga ports are uncomparable: https://www.youtube.com/watch?v=TZaMuFwaJgA A more apples to apples comparison: TG-16 vs Genesis: https://www.youtube.com/watch?v=qOXTWCSAyDs

https://www.youtube.com/watch?v=33kH9DdNznA
Amiga AGA's Street Fighter 2 tech demo.

https://www.youtube.com/watch?v=g4sXHhglk6s
Amiga AGA's Castlevania AGA port.

TurboGrafx-16 has a separate system and video memory (VRAM, the video memory type that was rejected by Commodore's soft-drink CEO).

Last edited by Hammer on 15-May-2024 at 07:03 AM.
Last edited by Hammer on 15-May-2024 at 07:02 AM.
Last edited by Hammer on 15-May-2024 at 07:00 AM.
Last edited by Hammer on 15-May-2024 at 06:59 AM.

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

@Hammer

Quote:

Hammer wrote: @Lou 6502 operates on the leading and falling edge (double rate), hence 7.16 Mhz 6502 is effectively 14.32 Mhz leading edge cycle. Commodore had a double-rate processing CPU IP in their hands with good potential. 32-bit ALU equipped 65xx update would be pretty good. Quote: Lou wrote: Also, let's face it, the C128-enhanced version of Eye of the Beholder is the best version of the game: https://www.youtube.com/watch?v=V2IWyzAVVBQ https://www.youtube.com/watch?v=wDaTGdQVZ6o Amiga AGA had PC's Eye of the Beholder II VGA port. Quote: Finally, a 7.16Mhz 6502 and a good graphic chip vs the Amiga ports are uncomparable: https://www.youtube.com/watch?v=TZaMuFwaJgA A more apples to apples comparison: TG-16 vs Genesis: https://www.youtube.com/watch?v=qOXTWCSAyDs https://www.youtube.com/watch?v=33kH9DdNznA Amiga AGA's Street Fighter 2 tech demo. https://www.youtube.com/watch?v=g4sXHhglk6s Amiga AGA's Castlevania AGA port. TurboGrafx-16 has a separate system and video memory (VRAM, the video memory type that was rejected by Commodore's soft-drink CEO).

I was comparing to 68000, not 14mhz 68020 w/AGA. Still the AGA looks jittery.
Eye Of The Beholder, 128-enhance uses 2 screens and has other features not in other ports. Eye of the Beholder 2, is a different game.

My point of comparing the TG-16 to Genesis/Mega Drive port vs port is that other than differences between the ports, most of the time the 6502-based TG-16 was better. Many complaints about the TG-16 were simply about lack of parallax scrolling in the background, but that shows developer weakness, not system weakness as Shadow Of The Beast and other games had it. The TG-16 had more sprites and flicker-free sprites at that than the Geneses/MegaDrive version. Being able to handle more objects is a cpu function. Many games slow down in these situations.

@Gunnar

Quote:

The 68000 did come out in 1979. Why compare with an 8 year old CPU?

You know a lot about the 68k.

The 68k
- is not very effective when it comes to Shift operation,
- memory access is wasting a clock cycle when looking for the bus,
- address misalignment is an exception you can see a design flaw, it never happens on x86.
- 16 MHz versions where not available when the A1000 was released.

I'm not sure if the current 68EC000 fix all this problems, but it can run in 8 or 16 bit mode, the 68010 has enough cache for small loops, making it possible to compete with x86 memory copy loops.
Some soft cores have faster 68k compatible versions, making more speed with compatible address busses.

You may know them better than most people in this forum.

As long as Atari, Amiga, SUN, HP or Apple used the 68k, Motorola had a lot of customers valuing this architecture, but when it comes to further 68k development, Motorola was always a bit to late so RISC systems from SPARC, MIPS or ARM had more performance in comparison.