Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
31 crawler(s) on-line.
 20 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 Karlos:  5 mins ago
 amigasociety:  24 mins ago
 daydreamer:  27 mins ago
 OlafS25:  39 mins ago
 Mobileconnect:  44 mins ago
 matthey:  52 mins ago
 OneTimer1:  53 mins ago
 minator:  1 hr 40 mins ago
 pixie:  2 hrs 8 mins ago
 Everblue:  2 hrs 39 mins ago

/  Forum Index
   /  Classic Amiga Hardware
      /  One major reason why Motorola and 68k failed...
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 Next Page )
PosterThread
Hammer 
Re: One major reason why Motorola and 68k failed...
Posted on 22-Jun-2024 16:03:26
#241 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5883
From: Australia

@OneTimer1

Quote:

OneTimer1 wrote:
@Hammer

A 680EC30 would have fixed it for low cost systems like the A1200
But all this came to late or was to expensive for a mass market like the PS1.


http://archive.computerhistory.org/resources/access/text/2013/04/102723299-05-01-acc.pdf

Data Quest buyer's guide for 1993, page 49

68030-25 CQFP = 54.50
68EC030-25 PQFP = $34.00, higher clock speed variants would cost more. No MMU.

386DX-25 PQFP = $54.23
AM386-40 PQFP = $38.50 Includes MMU.

For 68030-25, Motorola brain dead copies Intel's 386DX-25 prices. The majority of Intel CPU sales in 1993 were 486s. AMD dominates the fast 386 market. Motorola ignores AMD.

68040-25 = $227.75
68EC040-25 = $86.88, no MMU, useless for Amiga or any DMA'ed desktop computers. Another Motorola brain-dead move.
68LC040-25 is not listed.

80486DX-33 = $291.75
80486SX-25 PQFP = $88.87, functional for PC with DMA.

It sets up a situation for PC's Doom.

Last edited by Hammer on 22-Jun-2024 at 04:15 PM.
Last edited by Hammer on 22-Jun-2024 at 04:14 PM.
Last edited by Hammer on 22-Jun-2024 at 04:14 PM.
Last edited by Hammer on 22-Jun-2024 at 04:10 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

 Status: Offline
Profile     Report this post  
kolla 
Re: One major reason why Motorola and 68k failed...
Posted on 22-Jun-2024 19:26:23
#242 ]
Elite Member
Joined: 20-Aug-2003
Posts: 3227
From: Trondheim, Norway

How much was a Compaq Prolinea 4/25S when was it released in 1993 and what was the specs?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
OneTimer1 
Re: One major reason why Motorola and 68k failed...
Posted on 22-Jun-2024 20:11:16
#243 ]
Super Member
Joined: 3-Aug-2015
Posts: 1077
From: Unknown

@Hammer

1993 and 34$ - No wonder 68k and x86 where refused.

 Status: Offline
Profile     Report this post  
matthey 
Re: One major reason why Motorola and 68k failed...
Posted on 22-Jun-2024 23:29:41
#244 ]
Elite Member
Joined: 14-Mar-2007
Posts: 2353
From: Kansas

Hammer Quote:

Reminders:

1994's MIPS
R8000 with MIPS IV instruction set, 2.6 million transistors.
R4600 with MIPS III instruction set, 2.2 million transistors.

MIPS R3000 has 110,000 transistors, hence Sony's CPU selection is in the 68020 to 68030 transistors range.

PS1's CPU is MIPS R3000A with about 125,000 transistors from LSI.


The PS1 MIPS R3051 variant CPU core has a 4kiB instruction cache and 1kiB scratch pad cache in place of a data cache. These caches would have been SRAM and use 6 transistors per bit minimum.

5 kiB * 1024 Bytes/kiB * 8 bits/Byte = 40,960 bits * 6 transistors/bit = 245,760 transistors

The cache transistors above do not include tags which exist for the instruction cache while the scratch pad cache would require none after conversion from a data cache. The R3051 caches are direct mapped so there is not much tag overhead but increased conflict misses. The 4kiB instructions cache would have the performance of a 1kiB 68k instruction cache due to poor code density. There is likely no virtual address MMU or TLBs like the R3051.

The PS1 MIPS R3051 variant CPU core is simple and likely could outperform a 68030 per clock for general purpose integer workloads but the 68030 may remain competitive at higher clock speeds. The 68040 is likely a better performance match but with nicer features and the 68060 out classes it. Sony likely wanted a simple minimalist CPU core for their customizations. The PS3 Cell processor also added customizations to a stripped down PPC CPU but this did not work well anymore because x86 games required strong single core single thread performance by then. RISC cores were more competitive in the PS1 days when there was limited space on chips and power limitations. Code density became more important as cache sizes became larger killing Alpha, PA-RISC, MIPS, SPARC and PPC.

Hammer Quote:

PS1's custom chipset has a 1 million transistors budget. This is similar to Amiga Hombre's 1 million transistors budget for the CD64 game console.


Yes, both the PS1 and Hombre are simple RISC cores with customizations for 3D. There are many similarities.

Hammer Quote:

68EC060/68LC060/68060 is beyond Sony's PS1 "cheap RISC "budget".

Similar decision was made for Saturn's 68030 vs SuperH-2 selection.

Motorola's 68K is out of the mainstream 3D game console business.

AMD/Intel wouldn't be in games console business until AMD's K7 Duron (original Xbox prototype before Bill Gates override) and Intel Pentium III Coppermine-128L2 cache via the original Xbox.


Hardware with x86 CPUs used too much power for a console for many years and even the first generation XBox had heat problems and tried PPC. It's too bad there was no competitive 68k hardware available at that time as the 68k is simpler, decoding is simpler and in-order CPUs are more efficient reducing power use and temps.

Hammer Quote:

68060 lost hardware 32x32=64 instruction.


I expect more than 80% of MUL.L instructions are 32x32=32.

Hammer Quote:

68K instruction sizes on average are either 2 or 4 bytes each, and 6 bytes for longword (32-bit) instructions.


I expect more than 80% of 68k instructions are 6 bytes or less. See a trend? Yes, there was more performance available but the 68060 was designed for more than 80% of existing code. This philosophy was taken further with ColdFire which removed the ability to have instructions longer than 6 bytes altogether. The x86(-64) ISAs and CPU designs moved in the opposite direction of larger and more powerful instructions. The 68k has a better ISA and doesn't need as large of instructions but designs could trade power for performance compared to the low power 68060.

Longword size instructions are usually less than 6 bytes except for instructions using longword immediates. ColdFire MVS/MVZ instructions and my immediate compression method from longword to word when immediates fit into 16 bits would help reduce instruction sizes. The larger issue is not just immediates but combinations of immediates and addressing modes which are clipped by a 6 byte arbitrary instruction limit. ColdFire requires cracking instructions into multiple instructions like RISC including immediates, displacements and addressing modes thus reduce performance. The 68060 allows large instructions but the combination of not allowing them to superscalar execute and requiring multiple cycles practically deprecates larger instructions. Increasing the arbitrary limit from 6 to 8 bytes would boost performance and simplify 68k compiler backends already.

Hammer Quote:

SysInfo's instruction usage is biased towards 6 bytes. 68060's 4 byte per cycle fetch from the instruction cache is performance-gimping for stream compute.

Motorola deliberately gimped the 68060.

68060 needs to be modified to improve sustained longword instructions stream compute.


I don't think Motorola deliberately gimped the 68060. Performance was balanced with power and area is all. It is a practical and efficient CPU with better performance than expected. The 68060 has decoupled fetch and execution pipelines with an instruction buffer which handles large instructions well despite a small 4 byte/cycle fetch. There is usually not a loss of performance from normal immediate use in existing 68k code. An 8 byte/cycle fetch would not boost performance much without other changes like being able to superscalar execute larger instructions in a single cycle. Those larger instructions should gain a 4 times performance boost but would likely be less than 20% of instructions on average.

Hammer Quote:

Cyrix 6x86 fetches 16 bytes (128 bit) per cycle from the instruction cache.


The Cyrix 6x86 does not have decoupled fetch and execution pipelines with an instruction buffer like the 68060. Also, 68k code density is significantly better than x86 code density. The result is increased power and heat problems even for a mostly in-order CPU.

https://en.wikipedia.org/wiki/Cyrix_6x86#6x86 Quote:

The 6x86 (codename M1) was released by Cyrix in 1996. The first generation of 6x86 had heat problems. This was primarily caused by their higher heat output than other x86 CPUs of the day and, as such, computer builders sometimes did not equip them with adequate cooling. The CPUs topped out at around 25 W heat output (like the AMD K6), whereas the P5 Pentium produced around 15 W of waste heat at its peak. However, both numbers would be a fraction of the heat generated by many high performance processors, some years later. Shortly after the original M1, the M1R was released. The M1R was a switch from SGS-Thomson 3M process to IBM 5M process, making the 6x86 chips 50% smaller.


The 68060 was a high performance CISC CPU without a heat problem. With a long pipeline and without a heat problem, why wasn't it clocked up? Perhaps here is where the political sabotage came in from Motorola upper management (not from the architects and designers IMO)?

Last edited by matthey on 22-Jun-2024 at 11:34 PM.

 Status: Offline
Profile     Report this post  
Hammer 
Re: One major reason why Motorola and 68k failed...
Posted on 23-Jun-2024 1:27:43
#245 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5883
From: Australia

@matthey

Quote:

The PS1 MIPS R3051 variant CPU core is simple and likely could outperform a 68030 per clock for general purpose integer workloads but the 68030 may remain competitive at higher clock speeds. The 68040 is likely a better performance match but with nicer features and the 68060 out classes it. Sony likely wanted a simple minimalist CPU core for their customizations. The PS3 Cell processor also added customizations to a stripped down PPC CPU but this did not work well anymore because x86 games required strong single core single thread performance by then. RISC cores were more competitive in the PS1 days when there was limited space on chips and power limitations. Code density became more important as cache sizes became larger killing Alpha, PA-RISC, MIPS, SPARC and PPC.


For PS3, CELL's SPUs were being used as a GPU to patch RSX's G71's design flaws wasn't good either since it was crushed by CUDA based G80.

PS3 has similar total system GFLOPS as a single G80 based GeForce GTX 8800 GTS and PS3 wasn't raster render efficient since G80 can render the same era games at higher frame rate and resolution.

GpGPU's thousands of registers takes RISC's higher registers count concept to the extreme.

SPE is dead and CUDA is still alive e.g. RTX 4000 series ADA generation.

Later Xbox 360 has combined PPE and Xenos GpGPU on a single chip package and it was 1st APU with shared pointer capability as per AMD's "Fusion" APU. Xenos GpGPU has async compute engine front end (with 8 concurrent context) that later characterised Graphics Core Next (GCN)'s multiple async compute engine front end (with 8 concurrent context per ACE).

Sony selected AMD's Graphics Core Next (GCN) and Jaguar AMD64 for PS4.

With Direct3D, Graphics Core Next (GCN) has enough backward compatibility to run Xbox 360 games on Xbox One.

Quote:

Hardware with x86 CPUs used too much power for a console for many years and even the first generation XBox had heat problems and tried PPC. It's too bad there was no competitive 68k hardware available at that time as the 68k is simpler, decoding is simpler and in-order CPUs are more efficient reducing power use and temps.

FYI, Motorola 56300 DSP was repackaged as NVIDIA's SoundForce.

Without MS's Xbox subsidy, NVIDIA dumped Motorola 56300 DSP starting with nForce 3 generation due to cost reasons. LOL

For a time, my gaming PC with nForce 2 motherboard had Motorola 56300 DSP under the NVIDIA's SoundStorm branding. It resulted in very low CPU usage when running popular multimedia applications. Audigy offers similar performance as SoundStorm.

In October 2013 AMD presented products with AMD TrueAudio. A block of DSPs to be used to offload calculations for 3D sound and mostly used for game consoles i.e. Xbox One and PS4.
AMD TrueAudio repackaged Cadence Tensilica HiFi EP DSP with Tensilica Xtensa SP float support. The use case is mostly driven by game consoles.

PC GPUs like Radeon R7 260 had TrueAudio DSPs. Again, the use case is mostly driven by game consoles.

AMD's TrueAudio Next dumped Cadence DSP for AMD's in-house GCN Polaris which includes new DSP instructions. Again, the use case is mostly driven by game consoles.

For PS5 and XSX, AMD GCN CU based DSP is equivalent to the entire 8 cores Jaguar @ 1.6 Ghz. Again, the use case is mostly driven by game consoles.

Game consoles and gaming PCs are "safe space" for AMD/NVIDIA/Intel to attack other markets.

Handheld devices are "safe space" for ARM/Qualcomm to attack other markets.

Quote:

I expect more than 80% of MUL.L instructions are 32x32=32.

No modern CPU and GpGPU has dumped 32x32=64 functions

NVIDIA CUDA (PTX ISA Version 1.2 document) supports 32x32=64. Two 32-bit registers combines.

Quote:

The Cyrix 6x86 does not have decoupled fetch and execution pipelines with an instruction buffer like the 68060. Also, 68k code density is significantly better than x86 code density.

FALSE on " 68k code density is significantly better than x86 code density."

Pentium has FIMUL (integer mul on FPU) and MUL instructions. Pentium FPU is not limited by floating point datatypes. Integer only 3D games can be optimised for the Pentium.

Cyrix M1 has out of order processing from the execution stage after the decoder stage. FPU's fetch is attached X integer pipe line.

https://www.youtube.com/watch?v=XHqLYzqZciM
Tomb Raider 1 PC uses hardware FPU despite the game was from integer-only PS1.

FPU-less 486SX2-66 has 0 average frame rate and still runs in slide show.
FPU equipped 486DX2-80 has 18.5 average frame rate.

As for Doom benchmarks https://thandor.net/benchmark/32
6x86 PR166 (133 Mhz) = 84.21
Pentium 133 = 80.23
6x86 P150+ (120 Mhz) = 77.08 fps

For Doom benchmark, I don't have Warp1260's 68060 Rev6 @ 100 Mhz with RTG or BlizzardPPC (with 68060 Rev6) with BVision RTG. These 68060 with RTG configs avoid the Super Buster bottlenecks.

My TF1260 doesn't have RTG.

Quote:

The result is increased power and heat problems even for a mostly in-order CPU.

Your argument is irrelevant for desktops. I disregard "embedded low power" when I overlocked my 68060 Rev1 and TF1260 has a 3 pin fan header.







Last edited by Hammer on 23-Jun-2024 at 03:08 AM.
Last edited by Hammer on 23-Jun-2024 at 03:06 AM.
Last edited by Hammer on 23-Jun-2024 at 02:55 AM.
Last edited by Hammer on 23-Jun-2024 at 02:47 AM.
Last edited by Hammer on 23-Jun-2024 at 02:14 AM.
Last edited by Hammer on 23-Jun-2024 at 01:29 AM.
Last edited by Hammer on 23-Jun-2024 at 01: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

 Status: Offline
Profile     Report this post  
agami 
Re: One major reason why Motorola and 68k failed...
Posted on 23-Jun-2024 3:57:09
#246 ]
Super Member
Joined: 30-Jun-2008
Posts: 1826
From: Melbourne, Australia

@ppcamiga1

Quote:
ppcamiga1 wrote:
@agami

amiga mouse and keyboard were copied form pc 40 years ago
amiga joystick is atari joystick
so changing amiga into joystick mouse and keyboard interface is extremelly stupid way of wasting money for nothing
just use rpi with emulator

Computer keyboards were copied from typewriters 150 years ago.
The computer mouse is just a reverse plotter from 70 years ago.
The computer mouse was not standard on a DOS PC in 1984/1985. If Amiga (Commodore) copied the mouse, it copied it from Apple, or Xerox. But I guess they're all "PC" to you.
Amiga joystick is Commodore 64 joystick, which is Atari joystick. It's actually a remarkable emergence of standardisation in the "wild west" of the early and rapidly developing personal computing and video gaming landscape.

Everything is inspired by or is innovated upon things that precede it. There is no true invention.
The thing that was "Amiga" about the Amiga, is the OS and the chipset. The PiStorm + emu68 enable the continued use of the Amiga OS and the chipset. Things don't get much more Amiga than that.

Here's what I know you hate:
- You hate that people use their old Amigas for more than just playing OCS games.
- You hate that with the PiStorm + emu68, they can play ports of classic PC 3D FPS titles at frame rates and screen sizes, previously unimaginable on a 68k Amiga.
- You hate that old productivity software just got a new lease of life. Image, audio, and 3D graphics can all be produced much quicker.
- You hate that emu68 provides a very fast 32-bit, big-endian, target for not-PC software .
- And most of all you hate how this has taken away what little interest remained in the long dead idea of a PowerPC Amiga.

Which is why you would love nothing more than if people would rip the Raspberry Pi's out of their loved and treasured Amiga's, use it with Linux in 64-bit, little-endian (PC = work) mode, and if they want a faster Amiga, they should spend $1,000+ on an AmigaOS 4 system.


Last edited by agami on 23-Jun-2024 at 04:06 AM.

_________________
All the way, with 68k

 Status: Offline
Profile     Report this post  
agami 
Re: One major reason why Motorola and 68k failed...
Posted on 23-Jun-2024 4:07:34
#247 ]
Super Member
Joined: 30-Jun-2008
Posts: 1826
From: Melbourne, Australia

@ppcamiga1

P.S. I love this little "Artificial Unintelligence" game based on the Small Language Model (SLM) trained on @ppcamiga1 AW.net posts. Which appears to run with about 200 tokens, and on a very weak computer because it takes at least a day for a response.

Unlike a contemporary LLM, where a concise and well formatted prompt can generate structured and logically connected responses of several hundred words; The @ppcamiga1 SLM takes lengthy and logically connected prompts, and outputs brevity without logic, or wit.

Last edited by agami on 23-Jun-2024 at 04:10 AM.

_________________
All the way, with 68k

 Status: Offline
Profile     Report this post  
matthey 
Re: One major reason why Motorola and 68k failed...
Posted on 23-Jun-2024 6:52:57
#248 ]
Elite Member
Joined: 14-Mar-2007
Posts: 2353
From: Kansas

Hammer Quote:

For PS3, CELL's SPUs were being used as a GPU to patch RSX's G71's design flaws wasn't good either since it was crushed by CUDA based G80.

PS3 has similar total system GFLOPS as a single G80 based GeForce GTX 8800 GTS and PS3 wasn't raster render efficient since G80 can render the same era games at higher frame rate and resolution.

GpGPU's thousands of registers takes RISC's higher registers count concept to the extreme.

SPE is dead and CUDA is still alive e.g. RTX 4000 series ADA generation.

Later Xbox 360 has combined PPE and Xenos GpGPU on a single chip package and it was 1st APU with shared pointer capability as per AMD's "Fusion" APU. Xenos GpGPU has async compute engine front end (with 8 concurrent context) that later characterised Graphics Core Next (GCN)'s multiple async compute engine front end (with 8 concurrent context per ACE).

Sony selected AMD's Graphics Core Next (GCN) and Jaguar AMD64 for PS4.

With Direct3D, Graphics Core Next (GCN) has enough backward compatibility to run Xbox 360 games on Xbox One.


PS1, PS2 and PS3 had similar design philosophies with each surpassing the predecessor in compute performance. It was a given that the PS1 and PS2 needed significant rework of PC games to port them but there was no other option as x86(-64) hardware used too much power for a console. Theoretical compute performance increased with the PS3 but the superpipelined PPC CPU is terrible for general purpose code. Not only did SIMD code need optimizing for a different ISA but also general purpose code that should have been a simple recompile. The thinking became how many die shrinks does it take to make x86(-64) hardware practical to avoid wasting so much development time.

Hammer Quote:

FYI, Motorola 56300 DSP was repackaged as NVIDIA's SoundForce.

Without MS's Xbox subsidy, NVIDIA dumped Motorola 56300 DSP starting with nForce 3 generation due to cost reasons. LOL

For a time, my gaming PC with nForce 2 motherboard had Motorola 56300 DSP under the NVIDIA's SoundStorm branding. It resulted in very low CPU usage when running popular multimedia applications. Audigy offers similar performance as SoundStorm.

In October 2013 AMD presented products with AMD TrueAudio. A block of DSPs to be used to offload calculations for 3D sound and mostly used for game consoles i.e. Xbox One and PS4.
AMD TrueAudio repackaged Cadence Tensilica HiFi EP DSP with Tensilica Xtensa SP float support. The use case is mostly driven by game consoles.

PC GPUs like Radeon R7 260 had TrueAudio DSPs. Again, the use case is mostly driven by game consoles.

AMD's TrueAudio Next dumped Cadence DSP for AMD's in-house GCN Polaris which includes new DSP instructions. Again, the use case is mostly driven by game consoles.

For PS5 and XSX, AMD GCN CU based DSP is equivalent to the entire 8 cores Jaguar @ 1.6 Ghz. Again, the use case is mostly driven by game consoles.

Game consoles and gaming PCs are "safe space" for AMD/NVIDIA/Intel to attack other markets.

Handheld devices are "safe space" for ARM/Qualcomm to attack other markets.


I'm still not a fan of tacking on DSPs here and there for increased compute performance. Different pipelines may introduce stalls when exchanging data between them and shared data caches between CPU and DSP cores reduce performance gains. DSPs are fine for doing specific workloads separate from the CPU like audio mixing or CD decoding. More powerful SMP CPU cores, SIMD units and custom logic has largely replaced DSPs except for low end embedded use which may use CPU DSP ISA extensions, MAC units and rarely separate DSP cores.

Back in the Amiga days before SMP multi-core CPUs, DSPs provided more compute performance than CPU cores but not as good of general purpose performance. They required DSP specific careful coding to keep from stalling and compilers may have trouble generating code for them in the same way that compilers had trouble generating code for the PS3 Cell PPC CPU. This is often what happens when stripping out stall avoidance hardware, increasing compute units and lengthening pipelines too far to boost the clock speed. Everything has to be just right to keep the compute units fed. A good general purpose CPU makes the opposite choices and tries to minimize stalls.

The AT&T DSP as planned by CBM engineers would have been interesting for the Amiga as it had floating point capabilities. This likely would have been better performance and cheaper than adding a 6888x FPU to every Amiga as standard. However, once the FPU was integrated in the 68040 and 68060, this was likely better for performance, cost and compilers. The AT&T DSP could have still been used for dedicated DSP workloads but a standard DSP would have required Motorola and AT&T IP and more licenses to further integrate the 68k Amiga. A Motorola 56k DSP would have limited the IP sources and thus IP dependence but the 56k DSP did not have floating point support. Another option was organic development of a DSP by CBM. The Amiga blitter was already used for some simple DSP like workloads like floppy decoding. It may have been worthwhile to increase functionality to handle chunky blitting. In any case, no DSP or specialized processor is as easy as recompiling ported code for a good general purpose CPU like the 68060 which allows amazing 3D performance considering the in-order CPU on ancient silicon, 8kiB I+D caches, non-pipelined FPU and 50-100MHz clock speed. Too bad Motorola stopped there because the 68060 made the shallow pipeline PPC CPUs look bad.

Hammer Quote:

No modern CPU and GpGPU has dumped 32x32=64 functions

NVIDIA CUDA (PTX ISA Version 1.2 document) supports 32x32=64. Two 32-bit registers combines.


Some people would argue that 32x32=64 is a violation of the RISC philosophy for a 32 bit RISC ISA. MIPS allowed it by using non-GP custom 32 bit LO and HI registers. Some RISC ISAs like PPC have low (MULL) and high (MULH) versions of multiply instructions requiring 2 multiplies to get a 64 bit result. CISC doesn't have to worry about violating any philosophy but back then the 68060 designers were trying to reduce the 68060 and ColdFire to be more RISC like while x86 designers were trying to beef up x86 to out performance RISC.

Hammer Quote:

FALSE on " 68k code density is significantly better than x86 code density."

Pentium has FIMUL (integer mul on FPU) and MUL instructions. Pentium FPU is not limited by floating point datatypes. Integer only 3D games can be optimised for the Pentium.


The 68k may have a 20% code density advantage over x86 and 25%+ compared to x86-64. Recall from RISC-V research that every 25%-30% code density improvement gives the same performance as doubling the instruction cache size. Poor code density is what killed Alpha, PA-RISC, MIPS, SPARC and PPC as competing ISAs with better code density replace them.

Sharing the integer and FPU MUL and DIV units does not improve code density. It reduces CPU area and is not unusual. Integer only 3D games have a large advantage on the 68060 and Pentium competitors which mostly had superior integer performance. Optimizing for the Pentium FPU decreased code density due to the many FXCH instructions. SIMD code for x86(-64) whether integer or floating point has worse code density as demonstrated by the Photoshop stats.

Hammer Quote:

Your argument is irrelevant for desktops. I disregard "embedded low power" when I overclocked my 68060 Rev1 and TF1260 has a 3 pin fan header.


The 68060 was not low power for an embedded CPU but it was for a high end embedded or desktop CPU. Increasing performance increases power which is why CISC CPUs tend to dissipate more power. The 68060@66MHz "typically dissipates ~4.5W of power". Isn't it funny that the chief architect gave specs at introduction for a clock rating that was never reached? Why would the 68060@66MHz already be in testing only to be canceled forever?

Last edited by matthey on 23-Jun-2024 at 07:04 AM.

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: One major reason why Motorola and 68k failed...
Posted on 23-Jun-2024 7:30:40
#249 ]
Cult Member
Joined: 23-Aug-2015
Posts: 902
From: Unknown

@agami

you are stupid. you change your amiga into mouse and keyboard interface for rpi.
amiga mouse and keyboard were 40 years ago copied for pc.
so this is extremelly stupid way to waste money.
drop this shit pistorm and just use rpi.

 Status: Offline
Profile     Report this post  
pixie 
Re: One major reason why Motorola and 68k failed...
Posted on 23-Jun-2024 10:03:49
#250 ]
Elite Member
Joined: 10-Mar-2003
Posts: 3330
From: Figueira da Foz - Portugal

@ppcamiga1

Talking about stupid, you do know that you still can use rpi, don't you?

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

 Status: Offline
Profile     Report this post  
Hammer 
Re: One major reason why Motorola and 68k failed...
Posted on 23-Jun-2024 14:34:32
#251 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5883
From: Australia

@matthey

Quote:

PS1, PS2 and PS3 had similar design philosophies with each surpassing the predecessor in compute performance. It was a given that the PS1 and PS2 needed significant rework of PC games to port them but there was no other option as x86(-64) hardware used too much power for a console.

For game consoles, the major factor is price vs performance and certain lowish price targets.

PS4's estimated BOM cost
https://electronics360.globalspec.com/article/3781/exclusive-video-teardown-sony-close-to-breakeven-on-ps4?cid=nl

The most expensive subsystems in the PlayStation 4 are the core processor and the associated graphic DRAM, which together entail $188

PS4 APU = $100 (Y2013)
PS3 CPU/GPU = 83.55 (Y2009)

PS4 RAM = $88 (Y2013)
PS3 RAM = $8 (Y2009), not including the cost of GDDR3 mounted on RSX.

PS3 is a 2009 version, not the original 2006 version.

https://www.minneapolisfed.org/about-us/monetary-policy/inflation-calculator
Factor US inflation, 2013's $100 is $60.32 in 1992. This is for AMD's Liverpool APU for PS4.

Slightly above Commodore's Amiga Hombre's $40 cost for a CD64 game console.

Quote:

The 68k may have a 20% code density advantage over x86 and 25%+ compared to x86-64.

1. X86x-64 runs IA-32 code as 1st class.

2. On 3D code density, X86-64 has the edge due to SSE2.

For FP32 FMUL, 68060 version would need four 32-bit FMUL instructions while X86-64's SSE2 version would need a single 128-bit FMUL SIMD instruction.

For FP16 FMUL, 68060 version would need eight 16-bit FMUL instructions while X86-64's SSE2 version would need a single 128-bit FMUL SIMD instruction.

For INT8 MUL, 68060 version would need sixteen INT8 MUL instructions while X86-64's SSE2 version would need a single 128-bit MUL SIMD instruction.

During the Ghz race, Alpha couldn't keep up with the clock speed race yet it had an edge via FMA instructions.

Quote:

The 68060 was not low power for an embedded CPU but it was for a high end embedded or desktop CPU. Increasing performance increases power which is why CISC CPUs tend to dissipate more power. The 68060@66MHz "typically dissipates ~4.5W of power".

For desktops, your argument is a secondary priority.

Quote:

Isn't it funny that the chief architect gave specs at introduction for a clock rating that was never reached? Why would the 68060@66MHz already be in testing only to be canceled forever?

https://techmonitor.ai/technology/motorola_plans_to_sample_the_68060_next_quarter
68060 @ 66 Mhz is mentioned in the PR announcement. Prices are given for 68060-50, 68LC060-50 and 68EC060-50.

Without a gaming use case factor, where's the demand for squeezing out the performance?


Quote:

The AT&T DSP as planned by CBM engineers would have been interesting for the Amiga as it had floating point capabilities. This likely would have been better performance and cheaper than adding a 6888x FPU to every Amiga as standard. However, once the FPU was integrated in the 68040 and 68060, this was likely better for performance, cost and compilers.

Commodore has talked about the Amiga IEEE library ported to DSP3210.

Quote:

The AT&T DSP could have still been used for dedicated DSP workloads but a standard DSP would have required Motorola and AT&T IP and more licenses to further integrate the 68k Amiga. A Motorola 56k DSP would have limited the IP sources and thus IP dependence but the 56k DSP did not have floating point support. Another option was organic development of a DSP by CBM.
The Amiga blitter was already used for some simple DSP like workloads like floppy decoding. It may have been worthwhile to increase functionality to handle chunky blitting. In any case, no DSP or specialized processor is as easy as recompiling ported code for a good general purpose CPU like the 68060 which allows amazing 3D performance considering the in-order CPU on ancient silicon, 8kiB I+D caches, non-pipelined FPU and 50-100MHz clock speed. Too bad Motorola stopped there because the 68060 made the shallow pipeline PPC CPUs look bad.

From Commodore The Final Years by Brian.

"CSG was able to produce Agnus, Denise, and Paula for $5.49, $5.19, and $7.91 respectively"

Total: $20 in 1987 prices. Note why the Amiga Hombre two-chip solution has a $40 price target and includes a CPU.




Last edited by Hammer on 23-Jun-2024 at 03:04 PM.
Last edited by Hammer on 23-Jun-2024 at 02:59 PM.
Last edited by Hammer on 23-Jun-2024 at 02:44 PM.
Last edited by Hammer on 23-Jun-2024 at 02:41 PM.
Last edited by Hammer on 23-Jun-2024 at 02:39 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

 Status: Offline
Profile     Report this post  
bhabbott 
Re: One major reason why Motorola and 68k failed...
Posted on 24-Jun-2024 7:25:47
#252 ]
Regular Member
Joined: 6-Jun-2018
Posts: 440
From: Aotearoa

@Hammer

Quote:

Hammer wrote:

From Commodore The Final Years by Brian.

"CSG was able to produce Agnus, Denise, and Paula for $5.49, $5.19, and $7.91 respectively"

So much good info in that book - I'll have to read it again to remember it.

Quote:
Total: $20 in 1987 prices. Note why the Amiga Hombre two-chip solution has a $40 price target and includes a CPU.

Big difference between 1987 and 1994. IIRC Hombre was nothing more than a list of features. Whether it could have been produced is anyone's guess, but I'm betting it would have taken ages to debug - by which time it would be too late. In 1995 Microsoft pulls the plug on the Amiga's only remaining advantage.

 Status: Offline
Profile     Report this post  
Hammer 
Re: One major reason why Motorola and 68k failed...
Posted on 24-Jun-2024 13:15:26
#253 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5883
From: Australia

@bhabbott
.Quote:
So much good info in that book - I'll have to read it again to remember it.

It's one of many sources.

Quote:
Big difference between 1987 and 1994.

For game consoles, the basic price allocation range remained similar.

Agnus, Denise, and Paula would need Gary and the two CIAs. AMD APUs have built-in USB host controllers.

Jeff Porter's "8 bitplanes with 16 million colors" won the debate i.e. AGA. "8 bitplanes" focus has no chunky pixels.

Quote:

Hombre was nothing more than a list of features.

The bulk of Sony's CPU R&D effort was outsourced to LSI's CoreWare IP. Ken Kutaragi applied his DSP skills to geometry engine DSP. 1st party game software and good SDK were the main keys to PS1's successes.

Early texture mappers evolved from spites that gain distortion features.

PS1 doesn't have a hardware Z-buffer and it's just a step up from software renderer.

At a higher level concept, the MIPS R3000 CPU is similar to the 68LC040 class CPU i.e. single powerful ALU, one shifter, and no FPU.

PS1's CPU has 33.8 Mhz and"Geometry Transformation Engine" (GTE) has 53.69 MHz.

Think of 68LC040 @ 33 Mhz attached to a DSP3210 geometry engine @ 50 Mhz and you got most of PS1.

68LC040 needs to be cost-reduced into the 68030 cost range with improved MUL i.e. semi-custom 68030 with hardware MUL like the hardware barrel shifter.

DSP3210 is a dual pipeline CPU-DSP i.e. separate integer and floating point pipelines similar to 68040. DSP3210 is designed for 3D IEEE FP32.

Pentium has two ALUs and FPU (with dual-purpose integer and FP processing capability) in a triple pipelines configuration.


Remember,
Quote:

The v1000 was basically just a slow CPU (25MHz) that had a 1-clock 32*32 multiply (which took up a significant fraction of the chip!), a 1 clock approximate reciprocal instruction (so a 2 clock approximate integer divide), and the usual set of RISC instructions. Oh, and one more thing - a "bilinear load" instruction which effectively read a 2x2 block of linear memory and performed a bilinear filtering based on the u and v fraction passed in the instruction. There was a tiny cache, I believe it was just 4 pixels. So if you had overlapping 2x2's you'd get a reduction in memory bandwidth, but not if the 2x2's didn't overlap.

There was no hardware support for Z buffers. So the software that ran on the v1000 had to read Z, do the compare, then decide to write or not.

- Walt Donovan (Algorithm Architect)


This is before the workstation class ex-SUN GX and ex-SGI-influenced GPU companies like 3DFX, NVIDIA, and ARTX.

3DO MX (M3)'s leadership was an ex-SGI engineer.

For Intel's GPU business, Intel assimilated 3DLabs, Real3D (from Lockheed Martin), and many of ATI's Canadian employees, hence creating Intel's GPU design center in Canada.

Additional information from https://en.wikipedia.org/wiki/Real3D

Quote:

Whether it could have been produced is anyone's guess, but I'm betting it would have taken ages to debug - by which time it would be too late.

It depends on the implementation approach e.g. outsourcing the bulk of R&D by licensing Hitachi's PA-RISC clone and customizing it for 3D. Hitachi was developing its own CPU business with the Super H family e.g. Sega Saturn.

Commodore's approach was the "cheap RISC" with a high clock speed target and we have it with modern ARM. Amiga's user base majority is not Mac's user base. AmigaPPC camp thinks Amiga is a Mac.

Think of a user-friendly "cheap RISC" games machine that can handle school homework/education and SOHO.

Quote:

by which time it would be too late. In 1995 Microsoft pulls the plug on the Amiga's only remaining advantage.

Pentium's price range is not low enough to compete against PS1's price range.

The gaming PC didn't kill PS1.

Last edited by Hammer on 24-Jun-2024 at 03:13 PM.
Last edited by Hammer on 24-Jun-2024 at 01:43 PM.
Last edited by Hammer on 24-Jun-2024 at 01:31 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

 Status: Offline
Profile     Report this post  
Hammer 
Re: One major reason why Motorola and 68k failed...
Posted on 24-Jun-2024 15:02:22
#254 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5883
From: Australia

@kolla

Quote:

kolla wrote:
How much was a Compaq Prolinea 4/25S when was it released in 1993 and what was the specs?



https://vintageapple.org/pcworld/pdf/PC_World_9306_June_1993.pdf
Gateway Party List, Page 72 of 314

4SX-33 with 486-SX 33Mhz, 4MB RAM, 170 MB HDD, Windows Video accelerator 1MB video DRAM, 14-inch monitor for $1494,

4DX-33 with 486-DX 33Mhz, 8MB RAM, 212 MB HDD, Windows Video accelerator 1MB video DRAM, 14-inch monitor for $1895,

Page 128 of 314
Polywell Poly 486-33V with 486SX-33, 4MB of RAM, SVGA 1MB VL-Bus, price: $1250


https://vintageapple.org/pcworld/pdf/PC_World_9308_August_1993.pdf
Gateway Party List, Page 62 of 324

4SX-33 with 486-SX 33Mhz, 4MB RAM, 212MB HDD, Windows Video accelerator 1MB video DRAM, 14-inch monitor for $1495,

4DX-33 with 486-DX 33Mhz, 8MB RAM, 212 MB HDD, Windows Video accelerator 1MB video DRAM, 14-inch monitor for $1795,

Remember Gateway 2000? mooo.

Page 292 of 324
From Comtrade
VESA Local Bus WinMax with 32-Bit VL-Bus Video Accelerator 1MB, 486DX2 66 Mhz, 210 MB HDD, 4MB RAM, Price: $1795



https://vintageapple.org/pcworld/pdf/PC_World_9310_October_1993.pdf
October 1993, Page 13 of 354,
ALR Inc, Model 1 has Pentium 60-based PC for $2495.



https://archive.org/details/amiga-world-1993-10/page/n7/mode/2up
Amigaworld, October 1993, Page 66 of 104
Amiga 4000/040 @ 25Mhz for $2299
Amiga 4000/030 @ 25Mhz for $1599


Page 82 of 104
M1230X's 68030 @ 50Mhz has $349
1942 Monitor has $389
A1200 with 85MB HDD has $624
A1200 with 130MB HDD has $724

The Commodore solution is beaten by the Gateway solution.


Target sales period: XMas of 1993 Q4.. 1993 XMas sales period was Commodore's last chance.

_________________
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

 Status: Offline
Profile     Report this post  
matthey 
Re: One major reason why Motorola and 68k failed...
Posted on 25-Jun-2024 0:42:00
#255 ]
Elite Member
Joined: 14-Mar-2007
Posts: 2353
From: Kansas

Hammer Quote:

For game consoles, the major factor is price vs performance and certain lowish price targets.

PS4's estimated BOM cost
https://electronics360.globalspec.com/article/3781/exclusive-video-teardown-sony-close-to-breakeven-on-ps4?cid=nl

The most expensive subsystems in the PlayStation 4 are the core processor and the associated graphic DRAM, which together entail $188

PS4 APU = $100 (Y2013)
PS3 CPU/GPU = 83.55 (Y2009)

PS4 RAM = $88 (Y2013)
PS3 RAM = $8 (Y2009), not including the cost of GDDR3 mounted on RSX.

PS3 is a 2009 version, not the original 2006 version.


Full consoles switching to x86-64 certainly saved development time as they became closer to desktop specs. Desktop computers had higher specs for the clock rates and memory resulting in consoles becoming higher performance but more expensive, physically larger and hotter. The table below shows the memory of the PS which jumped with x86-64.

Year | Sony Model | CPU ISA | Memory
1994 PS1 MIPS 2MiB + 1MiB VRAM
2000 PS2 MIPS 32MiB + 4MiB VRAM
2006 PS3 PPC 256MiB + 256MiB
2013 PS4 x86-64 8GiB + 0.25-1GiB
2020 PS5 x86-64 16GiB + 0.5GiB

The PS has become a more standardized x86-64 desktop with a different UI and more arbitrary limitations on what it can be used for. The PS3 single core Cell CPU operated at 3.2GHz. The PS4 increased to 8 cores but the CPU cores dropped to 1.6 GHz, likely to minimize power and heat in a small case. The PS5 8 core CPU increased back to 3.5GHz partially due to chip fab improvements but the case and power supply are significantly larger.

Sony Model | Case Volume | Weight | Power Supply | Intro Price
PS4 4,429cm^2 2.8kg 250W $399.99
PS5 10,546cm^2 4.5kg 350W $499

Sony is practically stuffing a x86-64 desktop computer into a not so small or cheap box. My sister has a PS5 and it runs hot like a little space heater. I don't recommend a PS5 without air conditioning and a well ventilated cabinet. With x86-64 consoles upscaling closer to the x86-64 desktop standard and bloat, it would be a perfect time for a microconsole that is small, cool and cheap. We can see what RPi hardware can do when aggressively cost reducing hardware but RPis lack good integrated 3D graphics and ARM lacks games with emulation not being competitive. Having a huge game library and existing fan/customer base would help too. Retro games are hot right now as demonstrated by Mini consoles sales. A platform that has already demonstrated at least hundreds of thousands of unit sales are possible would reduce risk. Where would we find such a platform?

Hammer Quote:

1. X86x-64 runs IA-32 code as 1st class.


I expect it is rare that someone uses x86 code on a x86-64 system because of code density even though the code is more likely to remain cached, memory is saved and programs loads faster. The x86 ISA only has 7 GP integer registers so performance is often reduced. It's not like the 68k with 16 GP integer registers in 32 bit mode after a 64 bit mode is added.

Hammer Quote:

2. On 3D code density, X86-64 has the edge due to SSE2.

For FP32 FMUL, 68060 version would need four 32-bit FMUL instructions while X86-64's SSE2 version would need a single 128-bit FMUL SIMD instruction.

For FP16 FMUL, 68060 version would need eight 16-bit FMUL instructions while X86-64's SSE2 version would need a single 128-bit FMUL SIMD instruction.

For INT8 MUL, 68060 version would need sixteen INT8 MUL instructions while X86-64's SSE2 version would need a single 128-bit MUL SIMD instruction.

During the Ghz race, Alpha couldn't keep up with the clock speed race yet it had an edge via FMA instructions.


SIMD instructions may improve code density for SIMD/vector operations. However, SIMD instructions for scalar operations as a FPU replacement reduce code density and they are much more common on x86-64. Overall, SIMD instructions on x86-64 reduce code density and newer SIMD ISAs likely more so as the instruction sizes have grown. Performance likely still improves but the reduced code density reduces performance gains.

Hammer Quote:

https://techmonitor.ai/technology/motorola_plans_to_sample_the_68060_next_quarter
68060 @ 66 Mhz is mentioned in the PR announcement. Prices are given for 68060-50, 68LC060-50 and 68EC060-50.

Without a gaming use case factor, where's the demand for squeezing out the performance?


It makes sense to offer higher clock rated parts up to the limit of the design using the current chip process. This maximizes the price efficiency (performance/$) of the chip. Price efficiency is very important for desktop use. While performance efficiency (performance/MHz) and power efficiency (performance/W) are also important for embedded use, price efficiency remains important for embedded uses.

Desktop efficiency importance
1. performance/$ (price efficiency)
2. performance/W (power efficiency)
3. performance/MHz (performance efficiency)

Embedded efficiency importance
1. performance/$ (price efficiency)
2. performance/W (power efficiency)
3. performance/MHz (performance efficiency)

or for low power embedded use...

1. performance/W (power efficiency)
2. performance/$ (price efficiency)
3. performance/MHz (performance efficiency)

Performance efficiency may seem less important but it is necessary to provide good single core single thread performance. The core can be clocked up to increase performance instead but this uses more power and lower clocked cores offer many advantages. CISC CPUs often have good performance efficiency, which is important for gaming, while RISC CPUs often try to outperform CISC CPUs by out clocking them.

The 68060 had an 8 stage pipeline and it should have been clocked up more to maximize the price efficiency and value. This may have required optimization of some critical timing logic but I expect this is cheaper than creating a new design or trying to clock up a shallow pipeline PPC design. Die shrinks and doubling the caches like PPC 603 to 603e and PPC 604 to 604e, are not a good way to improve competitiveness but an act of desperation as is sabotaging the 68060 competitiveness to make PPC look better.

Hammer Quote:

From Commodore The Final Years by Brian.

"CSG was able to produce Agnus, Denise, and Paula for $5.49, $5.19, and $7.91 respectively"

Total: $20 in 1987 prices. Note why the Amiga Hombre two-chip solution has a $40 price target and includes a CPU.


Why was Paula the most expensive Amiga custom chip to produce? Didn't it use the least amount of transistors (all 3 chips were originally 48 pins)? Was it more expensive analog chip features?

The CBM post bankruptcy docs has the Amiga "semiconductor chips" at only $11 for the Amiga 1200 and $6 for the CD32 (missing some custom chips and integrates MOS CIA chips). Another location shows the HP produced CMOS Lisa chip at $7.70 and MOS chips at $10.85 but increasing. Another location shows "less than $15" for "the new low cost multimedia chipset" of AGA. Hombre is listed at "approx. $35". I don't see any price estimate for the 2 chip AA+ chipset or the single chip Amiga SoC but I expect it would be low as integration should provided a cost savings. A 68060 with AA+ chipset SoC ASIC could be mass produced for less than $1 today, judging by the sub $1 RP2040 SoC ASIC which uses more transistors.

Last edited by matthey on 25-Jun-2024 at 01:05 AM.

 Status: Offline
Profile     Report this post  
Hammer 
Re: One major reason why Motorola and 68k failed...
Posted on 25-Jun-2024 2:59:31
#256 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5883
From: Australia

@matthey

Quote:

@matthey

Full consoles switching to x86-64 certainly saved development time as they became closer to desktop specs. Desktop computers had higher specs for the clock rates and memory resulting in consoles becoming higher performance but more expensive, physically larger and hotter. The table below shows the memory of the PS which jumped with x86-64.

Year | Sony Model | CPU ISA | Memory
1994 PS1 MIPS 2MiB + 1MiB VRAM
2000 PS2 MIPS 32MiB + 4MiB VRAM
2006 PS3 PPC 256MiB + 256MiB
2013 PS4 x86-64 8GiB + 0.25-1GiB
2020 PS5 x86-64 16GiB + 0.5GiB

The PS has become a more standardized x86-64 desktop with a different UI and more arbitrary limitations on what it can be used for. The PS3 single core Cell CPU operated at 3.2GHz. The PS4 increased to 8 cores but the CPU cores dropped to 1.6 GHz, likely to minimize power and heat in a small case. The PS5 8 core CPU increased back to 3.5GHz partially due to chip fab improvements but the case and power supply are significantly larger.

PS4 has 8GB GDDR5-5500.
PS4 Pro has 8 GB GDDR5-6800 and 1 GB DDR3.
PS5 has 16 GB GDDR6-14000 and 512 MB DDR4.
PS5 Pro has 16 GB GDDR6-18000 and an unknown DDR4.

PS5's Zen 2 CPU is based mobile version with half the L3 cache from the desktop PC's Zen 2.

PS5's semi-custom Zen 2 CPU has reduced vector units https://chipsandcheese.com/2024/03/20/the-nerfed-fpu-in-ps5s-zen-2-cores/

Four pipelines into 3 pipelines.
https://chipsandcheese.com/2024/03/20/the-nerfed-fpu-in-ps5s-zen-2-cores/zen2_fpu_nerf/
2nd 256-bit FADD, 2nd 256-bit ALU, 2nd 256-bit FMA and 2nd AES were ditched.

Remaining, 1st 256bit FMA, 1st 256bit ALU, 256bit IMUL, 1st AES, 1st 256bit FADD, 1st 256bit ALU, Vector Shift, two Vector Shuffle, and FStore.

AMD BC-250 APU uses a harvested PS5 chip with six enabled Zen 2 cores and a cut-down IGP.

BC-250 APU targets crypto mining. It can boot normal Linux or Windows, but existing Windows Radeon drivers don't recognize PS5 IGP, but Linux Radeon drivers can recognize PS5's IGP e.g. https://www.youtube.com/watch?v=4dFmwjDCdLw&list=WL&index=7&t=3s

AMD allows semi-custom CPU designs like ARM's semi-custom design services e.g. Cortex A510's configured with different FP pipe counts.

----------------
Most of PS4's TDP comes from the Radeon R7 265 class GPU (256-bit bus-equipped video memory), not from 8 Jaguar "tablet" CPUs.

PS4's GPU has Hawaii (GCN 2.0) improvements on the Pitcairn GCN scale. PC didn't receive the Pitcairn GCN scale with Hawaii improvements i.e. PC market has a product renamed from Radeon HD 7800 series (256-bit bus-equipped video memory, renamed into R7 265 and R9 270). PC's 256-bit bus-equipped GPU class evolved into the larger Togna GCN 3.0 scale.

Quote:

@matthey

Sony is practically stuffing a x86-64 desktop computer into a not so small or cheap box. My sister has a PS5 and it runs hot like a little space heater. I don't recommend a PS5 without air conditioning and a well ventilated cabinet. With x86-64 consoles upscaling closer to the x86-64 desktop standard and bloat, it would be a perfect time for a microconsole that is small, cool and cheap. We can see what RPi hardware can do when aggressively cost reducing hardware but RPis lack good integrated 3D graphics and ARM lacks games with emulation not being competitive. Having a huge game library and existing fan/customer base would help too. Retro games are hot right now as demonstrated by Mini consoles sales. A platform that has already demonstrated at least hundreds of thousands of unit sales are possible would reduce risk. Where would we find such a platform?

Most of PS5's heat generation comes from the IGP. PS5's IGP is RX 6700 class with around 175 W TDP.

AMD's existing Hawk Point APU's 780M crushed Qualcomm's little IGP in Snapdragon X Elite. Next month, Strix Point APU (with 880M) will be released.


Quote:

@matthey

The CBM post bankruptcy docs has the Amiga "semiconductor chips" at only $11 for the Amiga 1200 and $6 for the CD32 (missing some custom chips and integrates MOS CIA chips).

Another location shows the HP produced CMOS Lisa chip at $7.70 and MOS chips at $10.85 but increasing. Another location shows "less than $15" for "the new low cost multimedia chipset" of AGA. Hombre is listed at "approx. $35".

Stock A1200 and CD32 couldn't run contemporary texture-mapped 3D games. A500 was running contemporary 2D games from 1987 to 1990 with superior versions.

You're "selling dreams" in the gaming market.

AGA is not operational without Fat Gary or AA-Gayle or Akiko (integrates AA-Gayle and two CIA chips).

Quote:

@matthey

I don't see any price estimate for the 2 chip AA+ chipset or the single chip Amiga SoC but I expect it would be low as integration should provided a cost savings.



From http://www.bambi-amiga.co.uk/amigahistory/leweggebrecht.html
Quote:

Lew: AA+ will be a more profitable version of AA with all the things we wished we'd got in but didn't have time. We have a list of all the problems we currently have at the low end. The serial port, we can't read high density floppies, there isn't enough band width to do 72 Hz screens plus there are no chunky pixel modes for rendering. We listed all those and said "OK let's go out and fix them as quickly as we can", so AA+ is an extension, not radically new architecture. We're doing the best that we can, takin g advantage of advances in technology, significantly reducing the cost and that's the goal.

AA+ has lower costs with higher profits.

Lew's AA+ plan includes AT&T DSP from the lowest Amiga SKU.

Quote:

Question: Does that mean that a AA+ machine will have a DSP?

Lew: "We can't make that decision right now - it's something we'll have to look at but in that time frame, even in the low end, every machine is likely to have a DSP. It's a cost thing - although the AT&T chip itself is only $20 to $30 or so. AT&T has a number of lower cost options, as well, that are designed more specifically to go on the motherboard. The problem with the present DSP design is that it has one serial channel and everything you attach to it has to be run through at that channel rate. I think th ey're looking at having four independent channels running at different clock rates, and with that kind of enhancement, DSP makes a lot of sense."



Quote:

From Commodore the Inside Story - The Untold Tale of a Computer Giant - David John Pleasance

"Meanwhile our UK-based Consumer Products business was in a very healthy position – we had taken massive orders for the Amiga 1200, scheduled for specific volume deliveries from September through to Christmas from all the major retailers. It was a profitable product with a healthy margin for Commodore at both corporate head office and in the UK"



Atleast 65,000 CD32 boards destined for Amitech's A2200 clone are frozen in the Philippine warehouse. https://bigbookofamigahardware.com/bboah/Product.aspx?id=19


Quote:

@matthey

A 68060 with AA+ chipset SoC ASIC could be mass produced for less than $1 today, judging by the sub $1 RP2040 SoC ASIC which uses more transistors.

RPi has economies of scale to pay for TSMC's wafer starts and pay professional engineers.

https://hackaday.com/2022/01/17/new-part-news-raspberry-pi-cuts-out-the-middleman/
For RP2040
Quote:

According to CEO Eben Upton, they’ve sold 1.5 million in a year, and have wafers in stock for 20 million more.


The old 68060 needs to be ported into a semi-modern process node e.g. 28 nm. Design the so-called AA+ or license SAGA for the actual silicon imprint. Engineers need to be paid to design SoC.

68060 doesn't have the front-end hardware to cover the gap between a Ghz-clocked CPU with slow external memory!

A big chunk of RP2040 SoC is consumed by on-chip SRAM. https://assets.raspberrypi.com/static/floorplan@1x-642e9c1ff35ab90927eeaddd4826846e.png


https://community.arm.com/support-forums/f/architectures-and-processors-forum/5176/arm-cortex-m0-details
Quote:

Without going into details, some of the low cost Cortex-M0 microcontrollers on the market has less than 50K gates and that included bus system, peripehrals, and possibly DMA support, etc (exclude memory area and analog components). The 12K gate number is based on minimum configuration at 180ULL process. However, you can get different gate count using different processes, some gives better figure and some give larger areas. For the Cortex-M0 DesignStart, as it has got 16 interrupts and the SysTick timer, the area would be a bit larger than 12K.


The major issue with 68060 is the platform cost.

https://www.raspberrypi.com/news/raspberry-pi-direct-buy-rp2040-in-bulk-from-just-0-70/
For rp2040 SoC
$0.70 x 1.5 million sales = $1.05 million annual revenue estimate.
$0.80 x 1.5 million sales = $1.20 million annual revenue estimate.

RP2040 SoC is an annual single-digit million-dollar business for RPi.

RPi sells a completed Raspberry Pi Pico SBC from $4.

Quote:

@matthey

The 68060 had an 8 stage pipeline and it should have been clocked up more to maximize the price efficiency and value. This may have required optimization of some critical timing logic but I expect this is cheaper than creating a new design or trying to clock up a shallow pipeline PPC design. Die shrinks and doubling the caches like PPC 603 to 603e and PPC 604 to 604e, are not a good way to improve competitiveness but an act of desperation as is sabotaging the 68060 competitiveness to make PPC look better.

Motorola's 68040 has a 6-stage pipeline vs Intel's 486 has a 5-stage pipeline. 486s was able to reach 66 Mhz and 100 Mhz. Motorola lost this clock-speed race despite having a slightly longer pipeline.

68060 is not fully pipelined e.g. FADD throughput is 1/3 clocks.

68060 could have slow sections that bring the entire chip into lower clock speed potential. There's a craftsmanship issue with 68060.

AC68080's 1 clock FMUL matched Rendition Verite v1000's 1 clock 32x32 multiply. AC68080's FPU is fully pipelined.

From https://exxosforum.co.uk/atari/last/CT60/fake/index.htm
68060's improvement timeline
Quote:

rev1: maskset 01F43G (1994, engraved 0.60µm)
rev2: maskset 01G65V (1996, engraved 0.60µm)
rev5: maskset 74E41J (1998, engraved 0.42µm)
rev6: maskset 71E41J (1999, engraved 0.32µm)


0.32µm 68060 Rev 6 wouldn't match 0.32µm Pentium P54CS's 200 Mhz clock speed and 0.32µm Pentium MMX P55's 233 Mhz clock speed.


Last edited by Hammer on 25-Jun-2024 at 04:31 AM.
Last edited by Hammer on 25-Jun-2024 at 04:25 AM.
Last edited by Hammer on 25-Jun-2024 at 04:12 AM.
Last edited by Hammer on 25-Jun-2024 at 03:49 AM.
Last edited by Hammer on 25-Jun-2024 at 03:43 AM.
Last edited by Hammer on 25-Jun-2024 at 03:39 AM.
Last edited by Hammer on 25-Jun-2024 at 03:33 AM.
Last edited by Hammer on 25-Jun-2024 at 03:25 AM.
Last edited by Hammer on 25-Jun-2024 at 03:13 AM.
Last edited by Hammer on 25-Jun-2024 at 03:12 AM.
Last edited by Hammer on 25-Jun-2024 at 03:08 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

 Status: Offline
Profile     Report this post  
bhabbott 
Re: One major reason why Motorola and 68k failed...
Posted on 25-Jun-2024 3:05:38
#257 ]
Regular Member
Joined: 6-Jun-2018
Posts: 440
From: Aotearoa

@matthey

Quote:

matthey wrote:

Why was Paula the most expensive Amiga custom chip to produce? Didn't it use the least amount of transistors (all 3 chips were originally 48 pins)? Was it more expensive analog chip features?

Yes. The D/A converters have analog parts to generate the output currents, which have to be very precise to get 8 bit accuracy. I don't see any evidence of laser trimming, so I'm guessing it was done purely by geometry. Yields were probably quite low, at least initially.

This may also explain why the planned improvements to Paula weren't completed in time for AGA (these improvements weren't very exciting, so it was no great loss).

Last edited by bhabbott on 25-Jun-2024 at 03:06 AM.

 Status: Offline
Profile     Report this post  
bhabbott 
Re: One major reason why Motorola and 68k failed...
Posted on 25-Jun-2024 4:52:40
#258 ]
Regular Member
Joined: 6-Jun-2018
Posts: 440
From: Aotearoa

@Hammer

Quote:

Hammer wrote:

4SX-33 with 486-SX 33Mhz, 4MB RAM, 212MB HDD, Windows Video accelerator 1MB video DRAM, 14-inch monitor for $1495

M1230X's 68030 @ 50Mhz has $349
1942 Monitor has $389
A1200 with 85MB HDD has $624

The Commodore solution is beaten by the Gateway solution.
No, it isn't.

Without proper sound that 486 is no solution. Must add ~$150 for a Sound Blaster card and speakers. But even that isn't enough to run the latest hot PC titles. So better make it a Creative Labs CD-ROM multimedia kit for $388. Now the 486 system costs $1883.

A1200 $399 - that's all you need to enter the wonderful world of Amiga!

Your Gateway 486 system is nearly 5 times more expensive than the awesome Amiga 1200!

Well OK maybe you really want a monitor and don't have one already, so add $129.95 for a 1084S. Must have a hard drive too? Add $146 for A1200HD/40. Now you're at $675, still way under half the price of the 486. "But I want a 50MHz 030 with 4MB of 32 bit RAM too!!!". Then add an MBX1230XA + 4MB ($349 + $139), for a total of $1163. Now you're ready for Doom when when it arrives 4 years later, and still $720 cheaper than the 486!

 Status: Offline
Profile     Report this post  
kolla 
Re: One major reason why Motorola and 68k failed...
Posted on 26-Jun-2024 0:21:24
#259 ]
Elite Member
Joined: 20-Aug-2003
Posts: 3227
From: Trondheim, Norway

Price was _the_ main factor when I bought my first Amiga in January 1994 - it wasn’t possible to buy a PC at even two or three times the price of an A1200. And I could just plug the A1200 into the scart of the 14" Philips TV I already had, and hook it into my Aiwa sound system. And so started my carreer in computers (distracting me from bio-physics)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
agami 
Re: One major reason why Motorola and 68k failed...
Posted on 27-Jun-2024 0:07:28
#260 ]
Super Member
Joined: 30-Jun-2008
Posts: 1826
From: Melbourne, Australia

@kolla

Quote:
kolla wrote:
Price was _the_ main factor when I bought my first Amiga ...

Yep price, but also more than that, value.
This is what @Hammer doesn't seem to be able to grasp when he lists prices from old magazines.

Where I bought my A1200HD (Maxwell Computers), they also sold PC Compatibles of the 386 and 486 variety. It's also where I first saw and "experienced" a Pentium system.
Maxwell also maintained a library of Amiga PD software, so before I purchased a modem and joined a BBS, I'd be there at least once a month to check out what's new.

I had plenty of opportunities to try out 386 and 486 systems. But even if a 386 system at the same price of the A1200HD outperformed the 020@14MHz in raw grunt, this held no value for me.
The A1200HD could run all the software I already had on my A500. Could do multi-media and multi-tasking. It was a complete package for me. I was its target audience.
The A1200HD was a dream machine for a creative person. The 386 was a business machine for the unimaginative, mono-tasker. It had no appeal.

For me, it wasn't until Windows 95 came out that I purchased a Pentium 90 no-brand beige box with 2MB SVGA, 8MB RAM, can't remember what size HDD, 1.44MB FDD, sound card, CD-ROM, 14" monitor, Win 95 + Encarta 95, for just under $2,500 AUD.
That was a lot of money for me in late 1995, but at the time it represented decent enough value. Interestingly, that's $5,170 in today's money. While I earn a lot more than I did back in 1995, I would have to be earning quite a bit more before I would be OK to spend $5k+ on a computer these days. Because, value.

Last edited by agami on 27-Jun-2024 at 12:32 AM.
Last edited by agami on 27-Jun-2024 at 12:31 AM.

_________________
All the way, with 68k

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle