@Lou

Quote:

If Commodore had chosen a faster 6502-based cpu like the TurboGraphx/PCEngine combined with an MMU to handle more memory, we'd have MUCH cheaper and better performing Amiga at launch and going forward.

What was that CPU path since then?

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

@Lou

65K CPU's clock speed ramp and supply road map are late.

https://www.youtube.com/watch?v=UDUQEKxfGEw

65816 struggle to reach higher clock speed with sufficient yields and supply.

From my cited Youtube video, Dave Haynie complained about 65C816's supply.

SNES obtained their 65C816 supply in the late 1980s.

ARM was created as a response against 65K's slow road map issues. ARM has 32-bit programming model, good IPC and low cost.

68020's ADD/SUB has 2 to 3 clock cycles. For 3D, MUL.L has 43 cycles and DIVU.L has 78 cycles. For faster MUL, Motorola wants the platform vendor to purchase 56K DSP or 68LC040.

$100 68EC040-25 is brain-dead with DMA enabled desktop computers.

MIPS R3000 attacked Motorola's product stack and pricing policy weakness.

For 68030-25, Motorola followed Intel's 386DX-25 pricing policy until Motorola where caught out by AMD's Am386-40 with a status quo breaker pricing strategy.

ARM addressed the MUL instruction issue with ARMv3M via certain ARM60 variant.

Intel has the superior road map with good clock speed ramps with supply and integrated MMU. Baseline MMU install base allows for large scale memory protected OS deployment. Remember, Linux is born on 386 PC.

Last edited by Hammer on 09-Aug-2024 at 02:57 AM.
Last edited by Hammer on 09-Aug-2024 at 02:44 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

Quote:

Lou wrote: YEAR CPU MIPS/MHz 1975 6502 .430 1983 65C02 .516 1988 65CE02 .645 1979 68000 .175 1984 68020 .303 1987 68030 .360 1990 68040 1.1 1994 68060 1.33 It took the 68K line 15 years to surpass the 6502 line in MIPS/Mhz Motorola was the problem. Meanwhile WDC still exists and Motorola doesn't. Motorola defined the Mhz myth.

Reaching higher clock speed is part of the performance criteria.

Performance = IPC x clock speed.

Remember, 65xx and 65K CPU family operates in "double rate" processing.

65CE02 @ 3.5 Mhz "double rate" is effectively 7 Mhz. The designer for CSG 4510 CPU was later hired by AMD and joined for K7 Athlon R&D team. K7 Athlon has DDR.

Reaching high clock speed is an art in itself e.g. DEC Alpha.

Like HP PA-RISC, DEC Alpha is designed to address Motorola's 68K performance weakness. Both DEC and HP shipped 68K Unix workstations.

Last edited by Hammer on 09-Aug-2024 at 05:20 AM.
Last edited by Hammer on 09-Aug-2024 at 05:13 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

Quote:

Compared to the 6502? You must be joking.

Commodore's 65CE02 has 1 IPC for 8-bit instructions improvement over 6502's 2 cycles. 65CE02 was later used for A2232 serial port card for Amigas with Zorro II.

65xx's strong IPC idea was applied for 32-bit GPR equipped ARM.

TheA500mini, A600GS and PiStorm are powered by ARM, the CPU family that is designed to address MOS-CSG/WDC's slow road R&D map.

Quote:

It's no coincidence that the Mac, ST, and Amiga all used the 68000 rather than some 8-bit CPU. It was the key to allowing the Amiga's capabilities to grow as expectations increased. Thanks to the fully 32-bit design, today we can make it powerful enough to largely keep up with modern systems without any significant changes to the architecture. Imagine trying to do that with an 8-bit CPU like the 6502!

Apple ditched the old MacOS with NeXTSTEP based MacOS X.

NeXTSTEP is designed to be portable across different CPUs since Steve Jobs doesn't trust Motorola and burnt from MOS/CSG's 65xx slow R&D road map.

Atari ST's OS is Digital Research's GEM 68K port.

For GEM X86, Digital Research angered Compaq due to software lockout against their Compaq's PCs i.e. early GEM X86 only works for IBM's PC. Compaq responded in full Windows 2.x support and the rest of PC cloners followed it.

Quote:

The SNES is a shining example of something I have not the slightest interest in. A boring box that does nothing but play expensive cartridge games, and not very good ones.

That's very centric of you.

Quote:

The four top selling games on the SNES were all derived from that stupid Donkey Kong game, highlighting the pathetic lack of originality and blatant commercialism of the platform. The SNES was designed for one purpose only, and couldn't even do that as well as it needed to - thus all those expensive cartridges with extra hardware in them. Nintendo didn't care of course, it was just more money for them!

Money is money. There's nothing wrong with earning money from the entertainment business.


Quote:

The CD32's real strength was that it was a cut down A1200 with CD-ROM drive. That meant developers didn't have to treat it as a separate platform with proprietary stuff they had to get familiar with - it was just another Amiga. As a former CD32 developer myself, I can say that this was a big advantage over some console that required a huge commitment. If you knew anything about Commodore's situation you would know that no hardware could have 'saved' the CD32. If they had made an exact copy of the PlayStation for half the price they still wouldn't have survived.

Commodore's $116 million debt is on management i.e. Mehdi Ali, Bill Sydnes and Jeff Franks.
$366 million loss is on management i.e. Mehdi Ali, Bill Sydnes and Jeff Franks.

Before taking over from Jeff Porter, Jeff Franks proposed Amigas for low-end and PC has mid to high-end product stack to Bill Sydnes. Bill Sydnes replaced Jeff Porter for Jeff Franks.

Jeff Franks is from Commodore PC division.

Mehdi Ali has to directly override Bill Sydnes' product stack approach from February 1992.

To save face, A300 renamed into A600 and A500's cancellation is on management i.e. Bill Sydnes. "Pride before the fall". This debacle needs to be avoided.

1991 year is the critical year for Commodore.

I stripped DRM from "Commodore The Final Years" ebook for debates like this.

Last edited by Hammer on 11-Aug-2024 at 04:09 AM.
Last edited by Hammer on 09-Aug-2024 at 06:11 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

Quote:

Lou wrote: @cdimauro http://commodore128.mirkosoft.sk/vic-iie.html Here you see that the VIC-IIe in the C128 has a real interlace mode supporting 320x400.

Irrelevant?
Quote:

The 65C02 offered a 20% IPC gain over the 65[02/10]. Many instructions reduced to 1 cycle, added 29 new instructions. The 65CE02 improved another 25%.

Irrelevant (without question mark).
Quote:

This puts the 65CE02 far above the 030 in IPC but below the 040. The 65CE02 was release in 1988 for a few dollars, the 040 in 1990 for $595 in quantities of 1000.

LOL You continue talking of things that you've no clue at all. IPC, as I've already tried to explain you, is a completely CRAPPY measure for processors, even inside the same members of the family.

The ONLY relevant measure when processors' performances is: how long do they take to accomplish a certain task. And nothing else!

Do you finally understand it, or Nature was a bad step-mother with you?
Quote:

https://www.krsaborio.net/unix-scalability/research/1990/1126.html Motorola: Too little, too late and WAY TOO expensive!

Irrelevant.
Quote:

Yes, WDC licensed the 6502, 65816..etc. The licensees were able to customize it in some cases even adding an MUL and DIV registers in the case of the Ricoh 65C816(5A22).This is no different than LC/EC models from Motorola.

The difference is that you don't know how the SNES SoC worked. Yes, because the 5A22 is a SoC integrating multiple devices with the processor.

In fact, the main processor (65C816) is UNTOUCHED: as it was provided by WDC.

The multiplication/division registers are EXTERNAL to the processor core, since they are DEVICES, as you can read even from the Wiki: https://en.wikipedia.org/wiki/Ricoh_5A22
Or, even better, from programmers documentation: https://snes.nesdev.org/wiki/Multiplication
Pay attention to this important "detail":
This takes 8 CPU clock cycles before it's finished (regardless of if those clock cycles are 2.68MHz or 3.58MHz)

So, you needed ADDITIONAL hardware to fill the gap of using this weak (from ISA perspective) CPU. Even a 020 obliterates such processors, and you don't have to cite the 030 or the (monster!) 040...
Quote:

This is why the 8502 got relocatable stack pointer and relocatable ZeroPage...which eventually became part of the 65C02 formally.

Still with SAME access time...
Quote:

Some later SNES games came with the 10.74Mhz version of the 65C816. https://snescentral.com/chips.php?chiptype=SA-1

Let me quote a relevant part:

this chip can be used to remove common SNES problems like slowdown

Funny, eh?
Quote:

Here's the SA-1 chip doing 3D, no SuperFX required... https://www.youtube.com/watch?v=42GeYsPGSjM

That's very basic stuff.
Quote:

Here is an SA-1 hack of Race/Hard Drivin: https://www.youtube.com/watch?v=ThMRXZbiIcE

Seriously? Just 1/3 of the screen was used for the 3D part, and it's also missing "transparencies".

Take a look at Amiga's Hard Drivin' running on a plain Amiga 500: https://www.youtube.com/watch?v=YyA9CupcHK0&t=342s
2/3 of the screen are for the 3D.

And here's the game running also on an A1200.
Quote:

Apple IIgs never got formally upgraded because GTE, the main supplier of 65816's had poor yields ... Meanwhile Sanyo had no problem producing 12+Mhz 65816s for their products. I'm not sure who CMD's supplier was in the mid 90's but they were doing 20Mhz...that's like a 80-160Mhz 68000...depending on the tasks.

Yes: STRICTLY depending on the tasks.
Quote:

If Commodore had chosen a faster 6502-based cpu like the TurboGraphx/PCEngine combined with an MMU to handle more memory, we'd have MUCH cheaper and better performing Amiga at launch and going forward.c Do you read what you write?!? The Amiga went in production on 1985? Which 65xx process was available at the time, giving similar performances and addressing 16MB of RAM? But, even more important, its development started on... 1982! Do you have a time machine for bringing at 65816 at least at 3,5Mhz on 1982? [quote]In case you are still confused ... a C128 can multi-task: https://www.youtube.com/watch?v=Zp4zonl4gQ0

Confused me? As I've already told you (and you clearly aren't able to get it), I've tinkered A LOT with mu C128.

In fact, I've also created a similar system, running two programs (in assembly) in parallel (using interrupts to change their context). It wasn't an entire o.s., of course, but it was fun.
Quote:

With continuous processor upgrades in speed, bus-width and features, Commodore could have spent the extra profits investing in better custom chips...which is always where the real magic happens. OCS was ok in 1985, ECS in 1987 was barely an upgrade...AGA in 1992 with no chunky-mode was too little too late.

I agree on that.
Quote:

Meanwhile Commodore have a VIC-III in 1988 that could compete with ECS but was chunky and offered fast tile-graphics.

Absolutely no: it was PLANAR! NOT packed/chunky!

Only Commodore engineers made it possible!
Quote:

SNES and PCEngine/TurboGrafx ran circles around the Amiga as a games machines with 'inferior' (according to you) cpus. MegaDrive/Genesis got beat by SNES and PCEngine. NEO-GEO ... again too expensive. Performance came from the gpu which was a monster with sprites. No real 3D games. Atari Jaguar, 1993, again 68000@13Mhz - lame...but by that time finally cheap. Lazy developers never really used the real RISC cpu in there...

Again, you're comparing ENTIRE systems!
Quote:

Motorola held the Amiga back.

No, it was Commodore.
Quote:

Garbage IPC until the over-priced and late '040.

ROFL. Again the IPC. You're hopeless...
Quote:

If an Amiga cost [only] $100 more than a C64 in 1987, no one would be talking about any other system but Amiga.

LOL. I don't even comment on that...
Quote:

Lou wrote: YEAR CPU MIPS/MHz 1975 6502 .430 1983 65C02 .516 1988 65CE02 .645 1979 68000 .175 1984 68020 .303 1987 68030 .360 1990 68040 1.1 1994 68060 1.33 It took the 68K line 15 years to surpass the 6502 line in MIPS/Mhz

And now MIPS: another crappy measure which says nothing.

Is anything else stupid that you want to show?
Quote:

Motorola was the problem.

No, the problem here is that you do NOT understand. And there's nothing that can be made to "fix" it...
Quote:

Meanwhile WDC still exists and Motorola doesn't.

Wrong: Motorola still exists.
Quote:

Motorola defined the Mhz myth.

Weren't they the so called (but which aren't now) RISCs?

Anyway, I gave you an homework to show how much modern are your beloved 65xx processors, but you're still no providing it.

Guess what: it should be embarrassing for you to show much much crap they are on doing modern stuff.

Whereas a 68000 from 1979 can easily show the exact opposite.

@Lou

Quote:

Lou wrote: YEAR CPU MIPS/MHz 1975 6502 .430 1983 65C02 .516 1988 65CE02 .645 1979 68000 .175 1984 68020 .303 1987 68030 .360 1990 68040 1.1 1994 68060 1.33 It took the 68K line 15 years to surpass the 6502 line in MIPS/Mhz

A bogus comparison. Absolute MIPS are what matter, not MIPS/MHz. In 1979 the 6502 topped out at 2MHz, while the 68000 was running at 8MHz. That's 0.86 MIPS on the 6502 vs 1.4 MIPS on the 68000, with the same memory cycle time. So in fact the 68000 surpassed the 6502 from the moment it was introduced.

By 1982 the 68000 was rated at up to 12.5MHz for 2.19 MIPS, 2.5 times faster than a 2MHz 6502. In 1983 the 65C02 closed the gap at 4MHz and 1.72 MIPS, but a year later Motorola pulled further ahead with the 68020 at 3.8 MIPS.

And that's not counting the 68000's wider bus, more powerful instructions and much larger flat memory model. As soon as you needed more than 64k and/or had to deal with 16 or 32 bit quantities the 68000 had a huge advantage, which is why it was the CPU of choice for more sophisticated 16-bit home computers.

Quote:

Motorola was the problem. Meanwhile WDC still exists and Motorola doesn't. Motorola defined the Mhz myth.

Yesterday I watched an interesting video about the Apple IIGS.

The Apple IIGS Megahertz Myth

The video investigates why the Apple IIGS only ran its 65C816 at 2.8 MHz when 4 MHz parts were supposed to be available and 8 MHz was 'coming soon'. Turns out that due to the chip being laid out by hand by WDC, the manufacturer had difficulty getting it to run properly even at 2 MHz. The first batch that Apple got wouldn't run at all, and the second batch weren't much better (apparently running at 0.5 MHz max). In late 1984 they managed to get chips that ran OK at 3 MHz, so they settled for 2.8 MHz (28 MHz master clock / 10). That's why many Apple IIGS's had a CPU marked at 3MHz when that wasn't an official rating.

Even as late as 1989 Applied Engineering was unable to get 7 MHz 65C816 chips for its IIGS accelerator card. Eventually Sanyo made a version that did work properly at high clock speeds by completely redesigning the chip.

The 65C816 was supposed to be a 68k killer, but didn't achieve that goal because the design was not suited to being clocked at higher speeds. Just using a denser process was not enough, advanced chip design tools would be needed rather than doing it by hand. Bill Mench's amateur attitude was the problem.

Quote:

Motorola was the problem. Meanwhile WDC still exists and Motorola doesn't. Motorola defined the Mhz myth.

The 'MHz myth' as you describe it is defined by people who are deliberately misrepresenting it to make their favorite CPU look better.

Motorola produced a lot more stuff than WDC ever did. Manufacturing microchips is a lot harder than designing them. The 6502 wasn't even a fully new design, it was a simplified derivative of the 6800 which took advantage of recently developed process innovations to make it faster and cheaper. The 6502's main attraction was it was cheap. It was targeted at hobbyists who were happy to get anything at all at a price they could afford, for which they were willing to overlook its design flaws.

First,
I am not a fan of the 65816 as that was an 8/16 design for APPLE. The 65CE02 for Commodore is a better 8/16bit design though they didn't do the trick to access 16MB of memory, only 1MB.

What is the path forward ... well when your licenses dry up what is the path forward? What is the path forward of the 680X0 line? Oh that's right it's dead.

The difference is you can obtain a license from WDC and can customize it.
WDC have a 32 bit design but by then the brainwashing was in full effect.
Most of the things holding back the 65XXX line is pin compatibility. Most 65XXX chips are drop-in accelerators.

Google 65F02.

Sanyo was able to re-implement the 65816 to 12+Mhz because WDC's design was flawed...but having a license let's you do that.
It was WDC's bad design that essentially launched ARM.


MIPS/MHz is a bad metric? Are you insane? Commodore had an 8Mhz 8/16bit cpu in 1988 that cost $6 compared to a 7.14Mhz 68000. Even at the C65's downclocked 3.57Mhz it could outperform the then-current Amigas. The Amiga 3000 came out in 1990 and no one could afford it.

All Commodore would have to do is ask for a 65CE02 variation with a 32bit memory bus that didn't have to be pin-compatible with the 6502 and you have your problem solved.
A 32bit design already existed but with no licenses, it was never proto-typed.

I swear you guys are drones with no vision. You just regurgitate 'google' search info.

.43/.175 = 2.457142 ... This means at the same clock speed a mere 6502 is 2.457142 times more efficient. So a 2Mhz C128 can do 45% more instructions than a 7.14Mhz 68000. The 65C02 and 65816 we even more efficient...almost 3x and widely available at 4Mhz in the mid-80's. So the A1000 could have had almost double the performance it launched with if it used a 4Mhz 65816. Heck it could have been 3.57Mhz matched directly to the bus-speed/chip speed and still been WAY ahead of the 7.14Mhz 68000.

Out of the box, Amiga didn't exceed that performance until the A3000 in 1990 which no one could afford. By then we had the 65CE02 and 12-14 Mhz 65816s...

Where's the Amiga market today?

Meanwhile, the 65816-based SNES still gets support:
https://www.gamingnexus.com/News/65074/The-SNES-version-of-Doom-is-returning-via-Limited-Run-Games-with-all-new-features/

A 65___-based Amiga in 1990 should have added a VIC-III to the chipset to do chunky graphics. Yes, 2 gpus. That would have been great. However that shiny 030 cost a pretty penny.

PS,
Here's a real C128 doing VIC-IIe interlace:
https://www.youtube.com/watch?v=iDMV3HsYIUE
sadly interlace is not well captured.
Here's interlaced mode on the VDC...
https://www.youtube.com/watch?v=un_P6Ptd2bs

So again, the C128 did offer many enhancements over the C64 but like usual, the lowest common denominator got the software support. That's why you still run A500 games on your A1200.

Last edited by Lou on 09-Aug-2024 at 04:31 PM.
Last edited by Lou on 09-Aug-2024 at 04:26 PM.
Last edited by Lou on 09-Aug-2024 at 04:24 PM.

@Lou

Quote:

Lou wrote: First, I am not a fan of the 65816 as that was an 8/16 design for APPLE.

Well, it's YOU that have reported it here several times. On the other end, it's the only 16-bit member of the 65xx family, right?
Quote:

The 65CE02 for Commodore is a better 8/16bit design though they didn't do the trick to access 16MB of memory, only 1MB.

That's an 8 (EIGHT!) bit architecture and NOT a 16-bit one.

Where on Earth have you seen 16-bit on this processor, besides the PC?!?
Quote:

What is the path forward ... well when your licenses dry up what is the path forward? What is the path forward of the 680X0 line? Oh that's right it's dead. The difference is you can obtain a license from WDC and can customize it.

You continue to talk of things that you clearly don't know.

NXP can license the 680x0 cores as well. In fact, it did it. For example: https://www.analog.com/en/products/fido1100.html

So, you CAN get a licence, if you want (and PAY!).
Quote:

WDC have a 32 bit design but by then the brainwashing was in full effect.

Have you took a look the its architecture (ISA)? I don't think so.

Well, I STRONGLY suggest to studied and then come back here and show me how "good" it could have been for MODERN computations...
Quote:

Most of the things holding back the 65XXX line is pin compatibility. Most 65XXX chips are drop-in accelerators.

Good. And?
Quote:

Google 65F02.

Google Apollo 68080 core or PiStorm...
Quote:

Sanyo was able to re-implement the 65816 to 12+Mhz because WDC's design was flawed...but having a license let's you do that.

OK, and?
Quote:

It was WDC's bad design that essentially launched ARM.

Wasn't Commodore which owned the 65xx family?

Anyway, what you still don't get is that it wasn't the bad (?) WDC 65816 architecture implementation (AKA microarchitecture), rather the architecture itself that was old / obsolete / NOT future proof for MODERN computational needs.
Quote:

MIPS/MHz is a bad metric?

Absolutely.
Quote:

Are you insane?

It's insane or a complete ignorant about performance measurements who can think about using such metric.
Quote:

Commodore had an 8Mhz 8/16bit cpu in 1988 that cost $6 compared to a 7.14Mhz 68000.

Guess what: NINE year AFTER that the 68000 was introduced.
Quote:

Even at the C65's downclocked 3.57Mhz it could outperform the then-current Amigas.

Then I want to see some games (not stupid ones) ported from Amiga to C65, and after that we can evaluate.

I'm preparing the popcorns...
Quote:

The Amiga 3000 came out in 1990 and no one could afford it.

It was HIGH-END!
Quote:

All Commodore would have to do is ask for a 65CE02 variation with a 32bit memory bus

MUHAHAHAHAH SUPER-MEGA-LOL!

An EIGHT bit processor connected to a 32-bit bus. Oh my GOSH... I can't believe what I'm reading here...
Quote:

that didn't have to be pin-compatible with the 6502 and you have your problem solved.

Why not pin-compatible? You've already stated a big load of b@lls, you can continue.
Quote:

A 32bit design already existed but with no licenses, it was never proto-typed.

Then it's NOT a 64CE02, right?

How can you so easily mix things is... well... no words, really.
Quote:

I swear you guys are drones with no vision.

ROFL I prefer to have no vision rather than the hallucinations that you've (without drugs, I assume).
Quote:

You just regurgitate 'google' search info.

Where? Care to prove it?

And... what about you, dear googler?
Quote:

.43/.175 = 2.457142 ... This means at the same clock speed a mere 6502 is 2.457142 times more efficient. So a 2Mhz C128 can do 45% more instructions than a 7.14Mhz 68000. The 65C02 and 65816 we even more efficient...almost 3x and widely available at 4Mhz in the mid-80's.

As above: complete crap way of "measuring" (!) processors performances.
Quote:

So the A1000 could have had almost double the performance it launched with if it used a 4Mhz 65816.

Sure, sure: I believe you.

https://en.wikipedia.org/wiki/WDC_65C816
Launched: 1985

Since the Amiga project started in 1982, you need a time machine to bring such processor to the Amiga developers and ask them to use it instead of the 68000.

MUHAHAHAHAHAH
Quote:

Heck it could have been 3.57Mhz matched directly to the bus-speed/chip speed and still been WAY ahead of the 7.14Mhz 68000.

And very nice performance I assume, right?
Quote:

Out of the box, Amiga didn't exceed that performance until the A3000 in 1990 which no one could afford.

I reveal you a secret: even the Amiga 1000 had accelerators available way before that the Amiga 3000 was produced.

Care to... study a little bit the history of the Amiga before rolling out so many loads of b@lls?
Quote:

By then we had the 65CE02 and 12-14 Mhz 65816s...

Where I can buy your time machine?
Quote:

Where's the Amiga market today?

It's here. It's "only" that you don't see it...
Quote:

Meanwhile, the 65816-based SNES still gets support: https://www.gamingnexus.com/News/65074/The-SNES-version-of-Doom-is-returning-via-Limited-Run-Games-with-all-new-features/

Nice, and?
Quote:

A 65___-based Amiga in 1990

Sure. Then throwing away all software, rewriting the entire 32-bit OS to run on a crappy 8 or 16 bit processor. I trust you!
Quote:

should have added a VIC-III to the chipset to do chunky graphics.

Again?!? What's not clear to you that it had PLANAR, NOT packed/chunky graphics?!?!?

Where have you see this packed/chunky graphics? After having abused of the Peyote?

VIC-III used planar graphics to make it even worse programming it AND killing its performances. Great decision of the wonderful Commorore's engineers!
Quote:

Yes, 2 gpus.

Even? No comment, really... MUHAHHAHAHAHA
Quote:

That would have been great.

Totally crazy, NOT great.
Quote:

However that shiny 030 cost a pretty penny.

You don't need it. A 020 was very good and cost effective.

Whereas, please help me: where is the 32-bit 65xx?
Quote:

PS, Here's a real C128 doing VIC-IIe interlace: https://www.youtube.com/watch?v=iDMV3HsYIUE sadly interlace is not well captured. Here's interlaced mode on the VDC... https://www.youtube.com/watch?v=un_P6Ptd2bs

Again: IRRELEVANT.
Quote:

So again, the C128 did offer many enhancements over the C64

Which ones? Why don't you list here?
Quote:

but like usual, the lowest common denominator got the software support. That's why you still run A500 games on your A1200.

Totally wrong comparison. The A1200 allowed WAY BETTER games compared to the A500. Something which the C128 will NOT allow, since most of the important hardware is exactly the same compared to the C64.

You continue to talk of things that you've no clue at all...

Lou Quote:

YEAR CPU MIPS/MHz 1975 6502 .430 1983 65C02 .516 1988 65CE02 .645 1979 68000 .175 1984 68020 .303 1987 68030 .360 1990 68040 1.1 1994 68060 1.33 It took the 68K line 15 years to surpass the 6502 line in MIPS/Mhz

Do you have a source for the 6502 family CPU "MIPS/MHz" results? Are you sure the 6502 family MIPS are Dhrystone 2.1 DMIPS and not VAX MIPS? Most of the 68k results use Dhrystone 2.1 benchmark code written in C which requires the int datatype to be a minimum of 16 bit. It is cheating to use a non-standard 8 bit int to improve performance for 8 bit CPUs. Is DRAM or SRAM memory used for the benchmark?

The April 18, 1994 Microprocessor Report gives 90 Dhrystone MIPS at 50MHz for the 68060 which is 1.80 DMIPS/MHz.

https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/080502.pdf Quote:

Eighteen months after describing the architecture, Motorola has formally introduced its line of processors based on the 68060. The new core achieves 90 Dhrystone MIPS at 50 MHz, making it the highest-performance CPU in the 68000 family. It is a superscalar device with some RISC-like implementation techniques, but it maintains binary compatibility with the 68000 family of CISC processors. Although not a drop-in replacement for the 68040, the 68060’s pinout and bus are compatible with its predecessor’s, making the faster chip attractive both in new designs and as an upgrade to existing machines.

The 2005 ARM Cortex-A8 2.0 DMIPS/MHz finally surpassed the 68060 with a much deeper 13-stage pipeline while the more practical and comparable 2011 ARM Cortex-A7, also with superscalar in-order 8-stage pipeline like the 68060, finally achieved 1.9 DMIPS/MHz.

year | CPU | pipeline | chip process | DMIPS/MHz
1994 68060 8-stage 500nm 1.8
2011 Cortex-A7 8-stage 40-28nm 1.9

ARM needed 17 years to reach 68060 DMIPS/MHz with an equivalent CPU, other than a huge advantage in chip process and transistor budget. Should they have thrown in the towel because of weak single core performance?

Lou Quote:

What is the path forward ... well when your licenses dry up what is the path forward? What is the path forward of the 680X0 line? Oh that's right it's dead.

The 68k patents are expired. There are likely multiple unlicensed 68k CPUs. The Fido was already mentioned but there are others like the TK68020.

https://www.tekmos.com/products/microprocessors/tk68020-microprocessor Quote:

Minimum Order Quantity We will continue to sell the TK68020 parts with a MOQ of 100 units as long as we have inventory in stock. Once that inventory is gone, then minimum order quantities will increase to 3000 parts per order.

The Natami guys contacted Freescale and they didn't have any problem with designing a new 68k core. HDL for multiple 68k cores can likely be licensed from Freescale or others. There are free open hardware 68k cores that are used in FPGA and an ASIC could be made although minimal pipelining would limit clock speeds to hundreds of MHz. The AC68080 core is likely pipelined enough for an ASIC to achieve GHz clock speeds. A 68060 ASIC could likely reach 1GHz using embedded chip processes if the 68060 was licensed. Most ColdFire cores are licensable from Silvaco including the "500 DMIPS" ColdFire V4 core.

https://silvaco.com/design-ip/embedded-processors/
https://silvaco.com/wp-content/uploads/product/ip/pdf/70012_ColdFireV4Core_Brief.pdf

The scalar ColdFire V4 core has a similar design to the 68060 but only one execution pipeline instead of two. It has very good performance for a scalar CPU.

year | CPU | pipeline | chip process | DMIPS/MHz
1994 68060 8-stage 500nm 1.8
2000 ColdFireV4 9-stage 220nm 1.54 (only scalar)
2002 ColdFire V5 9-stage 130nm 1.83

2003 ARM1176JZF-S 8-stage 350-40nm 1.25 (only scalar, RPi)
2011 Cortex-A7 8-stage 40-28nm 1.9

The ColdFire ISA simplified the 68k ISA to scale lower which reduced performance. The reduced performance ColdFire scalar and superscalar CPUs still provided stronger single core performance than ARM equivalents. The ARM Thumb-2 ISA was introduced in 2003 as part of ARM11. This gave ARM 68k like code density for improved cache efficiency but still not 68k like performance. The first major reason why ARM is still behind in performance is the Thumb ISAs increase the number of instructions to execute.

https://www2.cs.arizona.edu/~arvind/papers/lctes02.pdf Quote:

While the use of Thumb instructions generally gives smaller code size and lower instruction cache energy, there are certain problems with using the Thumb mode. In many cases the reductions in code size are obtained at the expense of a significant increase in the number of instructions executed by the program. In our experiments this increase ranged from 9% to 41%. In fact in case of one of the benchmarks, the increase in dynamic instruction count was so high that instead of obtaining reductions in cache energy used, we observed an increase in the total amount of energy expended by the instruction cache.

Most Thumb 16-bit encodings can only address 8 GP registers. More 68k 16-bit instructions encode 16 GP registers. Thumb has very limited immediates and displacements where the 68k has more variable length encoding sizes for them. Thumb encodings are simpler to decode with fewer sizes but there are many more instruction encoding formats than is typical for RISC. ColdFire has one more encoding size than Thumb-2 and the number of encoding formats should be close, especially if considering original ARM, Thumb-1 and Thumb-2 ISA encodings. Also, RISC load/store requires more instructions than CISC reg-mem.

The 2nd major reason why the 68k family was outperforming ARM is the pipeline design, especially load-to-use stalls. The Cortex-A7 made the following improvements.

https://community.arm.com/cfs-file/__key/telligent-evolution-components-attachments/01-2142-00-00-00-00-45-56/Enabling_5F00_Mobile_5F00_Innovation_5F00_with_5F00_the_5F00_Cortex_2D00_A7_5F00_Processor.pdf Quote:

Memory System Tuned to Minimize memory latency There are several performance optimizing features in the memory system. The address generation unit is shifted one stage back in the pipeline to enable a single cycle load-use penalty. The design team increased TLB size to 256 entries, up from 128 entries for the Cortex-A5 and Cortex-A9; this reduces page walks saving power and significantly improves performance for large workloads like web browsing with large data sets that span a large number of pages. Also, page tables entries can be cached in L1, improving the speed of page table walks on TLB misses. The bus interface unit has support for multiple outstanding read and write transactions. Finally, the physically indexed caches enable efficient OS Context switching.

The address generation performed one stage earlier reduced the load-to-use penalty from 2 to 1 cycle. The 68060 design eliminates the load-to-use penalty and performs the AG/EA calc two stages earlier. This requires more hardware for two ALUs but ALUs were relatively cheap already back in the early 1990s. The 68060 even includes an ALU with barrel shifter in each of two execution pipelines. This not only allows to execute instructions early and late to avoid stalls but it allows to execute powerful CISC instructions with powerful addressing modes that are the equivalent of two RISC instructions.

Don't underestimate the performance gained by reducing load-to-use stalls. ARM forgot when they designed the popular Cortex-A53 which returned to a 3 cycle load-to-use penalty. Intel knows the secret as x86 designs avoid the load-to-use stall (and take advantage of executing more powerful CISC instructions) like the 68k. How did the x86 ISA with practically 7 GP registers outperform 32 GP register RISC?

https://ftp.cs.wisc.edu/sohi/papers/1995/micro.zcl.pdf Quote:

Next, we considered 8 register designs with limited and full support for zero-cycle loads. The limited support design only provides cycle zero latency to global and stack pointer accesses. Implementing this support is less costly than full support for zero-cycle loads. (This design is essentially the one in Figure 2 without a BRIC.) This design should perform well considering the predominance of stack and global accesses in the 8 register executions. The speedups in the column labeled Cycle(32reg)/Cycle(8reg+GPSP) show this implementation’s performance with respect to an architecture with 32 registers and no support for zero-cycle loads. For most programs, limited support for zero-cycle loads more than compensates for the lack of registers in the architecture. In most cases, the performance of the register limited architecture is better than its 32 register counterpart. Not only does the zero-cycle load support perform well on the extra accesses due to spills and reloads, but it also performs well on the stack and global pointer accesses that both processors must execute. For a few of the floating point codes, e.g., Tomcatv, the improvements rendered still do not approach the performance of the 32 register architecture. These codes suffer from an excessive number of dynamic loads and stores, which saturate available data cache bandwidth and limit overall performance improvements.

The paper proposes changes to the classic 5 stage pipeline design with 2 cycle load-to-use penalty to moves the AG/EA calc earlier by one stage and predicting the load location which is only 80% effective. This only provides ~80% of the benefit of CISC zero cycle loads yet the performance of 8 GP registers with partial zero cycle loads is already better than 32 GP registers without.

https://ftp.cs.wisc.edu/sohi/papers/1995/micro.zcl.pdf Quote:

The rightmost two columns of Table 5 compare the performance of an in-order issue processor with and without zero-cycle load support to an out-of-order issue processor without zero-cycle load support. The column labeled Cycle(In)/Cycle(Out) gives the runtime (in cycles) of programs on the in-order issue processor divided by the run-time on the out-of-order issue processor (neither with zero-cycle load support). This metric quantifies the cycle count advantage when running on an out-of-order issue processor. Clearly, the programs take fewer cycles to run on the out-of-order issue processor than on the in-order issue processor. The column labeled Cycle(In+ZCL)/Cycle(Out) repeats the experiments, except the in-order issue processor has support for zero-cycle loads. For the integer codes, the performance of the two processors is now much closer – both out performing each other in some cases, with slightly better performance on the out-of-order issue processor. This result is striking when one considers the clock cycle and design time advantages typically afforded to in-order issue processors. It may be the case that for workloads where untolerated latency is dominated by data cache access latencies (as in the case of the integer benchmarks), an in-order issue design with support for zero-cycle loads may consistently out perform an out-of-order issue processor.

This supports what I have been saying before. RISC OoO CPUs waste much of their resources on removing load-to-use stalls. The simulation from the paper was actually for an aggressive OoO RISC design which could only partially remove the load-to-use stalls demonstrated by the in-order CPU design with partial zero-cycle loads outperforming the OoO design in some cases. In-order CISC designs like the 68060 with zero cycle loads can match the performance of limited OoO CPU designs and maybe even more aggressive OoO designs. This is one of the reasons why the 68060 integer performance/MHz was better than the PPC 603 and roughly matched the PPC 601 and PPC 603(e) while using less caches. Most PPC shallow pipeline designs only had 1-2 cycle load-use-penalties and the limited OoO likely helped some but instruction scheduling was still very important. As I recall, the PPC 970 G5 only had a 2 cycle load-to-use penalty and more aggressive OoO design but the in-order RISC-V SiFive U74 core with 68060 CISC like design had better performance/MHz in the 7-zip benchmarks. The SiFive U74 core is using a somewhat newer process but is using a tiny fraction of the resources of a G5 core and is in many ways less sophisticated than a 68060. It's like a new tiny sloop taking down an older flagship war galleon that is many times the size and several times the number of cannons. The thing is, the sloop technology is not new but old mostly abandoned technology that was often ignored by RISC architects. Even in this old paper, the authors seemed to ignore or are ignorant of the fact that CISC designs already had true zero cycle loads and they could too if they would just move the AG/EA calc back one more stage and add another ALU but the simple short weak RISC pipelines were much loved for reasons other than performance.

Lou Quote:

The difference is you can obtain a license from WDC and can customize it. WDC have a 32 bit design but by then the brainwashing was in full effect. Most of the things holding back the 65XXX line is pin compatibility. Most 65XXX chips are drop-in accelerators. Google 65F02. Sanyo was able to re-implement the 65816 to 12+Mhz because WDC's design was flawed...but having a license let's you do that. It was WDC's bad design that essentially launched ARM.

No. The 6502 family ISA was too limited and had poor performance metrics. The 6502 CPU cores could be clocked up but the close optimized coupling between memory and the pipleline needs to be separated as memory doesn't keep up with CPU clock speeds. Using a limited amount of SRAM solves the problem for a limited but fairly fast system as some 6502 family MCUs use and is a cool option for retro hardware too. This is incomparable to the large flat address space of the 68k which is capable of surprisingly modern computing even with emulation at a fraction of the performance of what even scalar 68k ASIC CPU cores would achieve and lacking SMP. Motorola/Freescale could have developed the 68k but they were too busy pushing PPC which had better performance than ARM too. ARM performance was poor for decades and they switched ISAs multiple times before they found success with an ISA that resembles an improved PPC ISA.

Lou Quote:

MIPS/MHz is a bad metric? Are you insane? Commodore had an 8Mhz 8/16bit cpu in 1988 that cost $6 compared to a 7.14Mhz 68000. Even at the C65's downclocked 3.57Mhz it could outperform the then-current Amigas. The Amiga 3000 came out in 1990 and no one could afford it. All Commodore would have to do is ask for a 65CE02 variation with a 32bit memory bus that didn't have to be pin-compatible with the 6502 and you have your problem solved. A 32bit design already existed but with no licenses, it was never proto-typed.

You do have a point about the 6502 cost. The 6502 could be produced for pretty much as cheap as is possible for a MPU because it practically uses as few of transistors as possible and CBM owned the IP. Jay Miner likely had plenty of pressure to produce another 6502 family PC but he fortunately stood his ground for the 68000. The 68000 uses a lot more transistors but economies of scale made the 68000 cheap enough by the Amiga introduction that using anything else would have been a mistake. The 68k prices were rarely the cheapest but Motorola/Freescale had mostly competitive prices and performance with good features and quality. They were late too often, including very late with the 68040 which was also mediocre at best.

Lou Quote:

I swear you guys are drones with no vision. You just regurgitate 'google' search info. .43/.175 = 2.457142 ... This means at the same clock speed a mere 6502 is 2.457142 times more efficient. So a 2Mhz C128 can do 45% more instructions than a 7.14Mhz 68000. The 65C02 and 65816 we even more efficient...almost 3x and widely available at 4Mhz in the mid-80's. So the A1000 could have had almost double the performance it launched with if it used a 4Mhz 65816. Heck it could have been 3.57Mhz matched directly to the bus-speed/chip speed and still been WAY ahead of the 7.14Mhz 68000. Out of the box, Amiga didn't exceed that performance until the A3000 in 1990 which no one could afford. By then we had the 65CE02 and 12-14 Mhz 65816s...

For supposedly being an experienced computer guy, you really don't understand much about CPUs, ISAs or performance. Cesare and I have at least half a clue even though we are nowhere near hardware gods like Gunnar. If you learned a little about CPU technology then maybe you would understand where are points come from and they wouldn't seem like random Google searches. That would be closer to Hammer's walls of miscellaneous info but his info is on topic and valid sometimes showing a varied level of computer understanding depending on the topic.

Lou Quote:

Where's the Amiga market today?

THEA500 Mini sold well enough despite higher prices than RGL originally planned, weak ARM Cortex-A53 based emulation, no AmigaOS, limited I/O and expansion possibilities, etc. Other than that, we have Frankenstein's monster hardware and Amiga IP squatters that will never give up blocking anything better.

Last edited by matthey on 11-Aug-2024 at 02:50 AM.
Last edited by matthey on 11-Aug-2024 at 02:29 AM.

@Lou

Commodore wasted 2 microns fabs for C65-related chips instead of investing 1.5 microns fab for AA chipsets.

SNES's main graphics power comes from the custom graphics chipset, not the CPU. 65K CPU was displaced by a 16-bit RISC SuperFX CPU-DSP with a higher clock speed.

In 1990, Commodore was promoting C65 among 3rd party developers while the rest of the industry was wowed by Wing Commander's 1990 release.


Both ARC (Argonaut RISC Core) and ARM (Advanced RISC Machines and originally Acorn RISC Machine) addressed the slow R&D road maps of the 65K CPu family.

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

matthey wrote: Lou Quote: YEAR CPU MIPS/MHz 1975 6502 .430 1983 65C02 .516 1988 65CE02 .645 1979 68000 .175 1984 68020 .303 1987 68030 .360 1990 68040 1.1 1994 68060 1.33 It took the 68K line 15 years to surpass the 6502 line in MIPS/Mhz Do you have a source for the 6502 family CPU "MIPS/MHz" results? Are you sure the 6502 family MIPS are Dhrystone 2.1 DMIPS and not VAX MIPS? Most of the 68k results use Dhrystone 2.1 benchmark code written in C which requires the int datatype to be a minimum of 16 bit. It is cheating to use a non-standard 8 bit int to improve performance for 8 bit CPUs. Is DRAM or SRAM memory used for the benchmark?

There's A LOT to be clarified here, because the 6502 is an 8 bit processor and with regular software 16-bit integers is the bare minimum (which this architecture cannot clearly sustain).

The 6502 is good for embedded systems and very cheap, but general-purpose computing is a completely different thing.

I've proposed Lou a very very simple exercise with a linked list of strings to be implemented with such 6500 processors, and he's systematically ignoring it.
Guess why: because even such super easy stuff have shown how weak are those processors at GP computing.

Or maybe he could only conceive benchmarks made up of a single instruction like ADD, and anything more complicated is out of his capabilities...

TLDR, he's clearly and only a blind 65xx zealot which has no clue about GP computing and history (since he mixes stuff & different technologies like someone having a time machine. In this case, he's similar to Hammer which isn't able to contextualize many times, putting together different things).

@cdimauro

Quote:

TLDR, he's clearly and only a blind 65xx zealot which has no clue about GP computing and history (since he mixes stuff & different technologies like someone having a time machine. In this case, he's similar to Hammer which isn't able to contextualize many times, putting together different things).

BULLSHIT. FUKC YOU!!!@!!

_________________
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

@cdimauro

Quote:

Again?!? What's not clear to you that it had PLANAR, NOT packed/chunky graphics?!?!?

What!? A VIC-IIII/VIC-IV?

That makes no sense! The C=/VIC chipset wasn't a planar design. It was based on Commodore chunky. A C16/Plus 4 which used VIC style bitmaps would have been more compatible.

By Commodore chunky I mean the character based chunky used in MCM. Which unlike even common linear chunky had pixel width to match bit pack width. The only mode compatible to planar would be standard bitmap mode but so are all 1 bpp framebuffers.

The subjects of this thread like using engineered 6502 over 68000 remind me of ideas like putting dual SIDs in the Amiga. But the Amiga wasn't a C64. In fact before it was bought out the Amiga wasn't a Commodore at all. So while I can see why people make those suggestions, they don't make sense for the Amiga. The Commodore logo on an Amiga case doesn't make it a direct follow up to the C64.

In fact, being completely different to the C64, could have killed the Amiga off. The C16/Plus 4 confused the market, even though the C64 was incompatible with the VIC20 in similar ways. But by the time of the C64 it had established itself as the Commodore standard. This was demonstrated in the C128 which was unable to become an own machine and a superior follow up, but was somewhat crippled with being forced to be compatible with the C64, with the efforts the designers went to doing so proving this. The only main feature was a hires mode, but it had no sprites, and without even the superior Plus 4 palette would not have survived on its own. The C64 became like the IBM PC as it became like the Commodore ISA (Industry Standard Architecture). Except as the Commodore Standard Architecture (CSA). But unlike the PC, which was able to be expanded even to this day, the C64 managed to be positioned in such a way that the hardware couldn't be expanded in a compatible way. Perhaps the C65 would have challenged that. (Despite oddly named model). To do so it really would have needed be around when the C128 came out IMHO. But without the shadow growing from the Amiga.

@cdimauro
I don't know which is more absurd, to compare the 6502 and 68000 features and say the 6502 is better or to compare the 6502 and 68000 performance and say the 6502 is better. The comparison gets worse with later 6502 family CPUs vs 68k CPUs and worse yet with unreleased CPUs like the 32-bit W65T32 vs 68060+. The 6502 combo of an accumulator architecture with few registers and poor code density creates a large memory bottleneck without a good way to upgrade without major ISA changes. The good code density x86 ISA with only 7 GP registers was bad enough as I talked about from one of the papers above.

https://ftp.cs.wisc.edu/sohi/papers/1995/micro.zcl.pdf Quote:

The left side of Table 6 shows how a program is affected by reducing the number of architected registers in each register file from 32 to 8. The total number of loads increased by as much as 177%, primarily the result of extra accesses needed to spill and reload temporary variables. The increases are notably larger for programs with larger basic blocks, e.g., the floating point codes, since they typically use more temporary space. Also shown (in the column labeled Distribution of Extra Loads) is the breakdown of howmuch (as a percent of total extra loads) each form of addressing contributes to the overhead.

Reducing from 32 down to 8 GP registers increased integer benchmark loads 31% and fp loads 84% on average yet 8 GP registers with zero cycle loads (no load-to-use penalty) had better integer performance on average than 32 GP registers with a load-to-use penalty of 2 cycles (Amiga base emulation standard uses Cortex-A53 with 3 cycle load-to-use penalty and no instruction scheduling for 68k to ARM code so maximum performance degradation). This memory/cache traffic is only data loads and does not include data stores or instruction loads which we know is worse for RISC and accumulator architectures. The other ARM Thumb paper above shows only instruction cache traffic and misses between ARM and Thumb where Thumb 31% code size reduction on average decreases instruction traffic by 7% and cache misses by 7% on average but the instruction count increased by 22% on average. Few registers gives high instruction counts which is another performance problem for the 6502. Limited encoding space likely makes this worse. Then there is the claim that the 68k has a high decoding overhead when the 68k is more orthogonal than the 6502 which often is worse when adding registers. The AC68080 is less orthogonal than the 68k ISA after adding registers all over the place. Ironically, my FPU proposal to increase the 68k FPU registers to 16 in a highly orthogonal way was immediately derided as too few GP registers. The zero cycle loads paper above is evidence that more than 8 GP registers are likely needed for a FPU but the simulation was for RISC/MIPS where the 68k has CISC mem-reg instructions to reduce register needs. More than 16 FPU registers may be needed for a deeply pipelined 5 GHz AC68080 desktop/workstation CPU but a simpler 2 GHz CPU design that reduces latencies, minimizes stalls, has good orthogonality and has good code density is more practical and fun to program. The 68k should still scale up in performance better than x86 but being able to scale down is probably more important today, not that ColdFire level castration is or ever was necessary, except to avoid competing with PPC.

Hypex Quote:

The subjects of this thread like using engineered 6502 over 68000 remind me of ideas like putting dual SIDs in the Amiga. But the Amiga wasn't a C64. In fact before it was bought out the Amiga wasn't a Commodore at all. So while I can see why people make those suggestions, they don't make sense for the Amiga. The Commodore logo on an Amiga case doesn't make it a direct follow up to the C64.

More C64 compatibility would have been a good thing as CBM failed to upgrade the majority of C64 owners to the Amiga. A 6510 CPU and dual SIDs were small enough logic that they could have been integrated into the Amiga custom chips a couple of years after launch. The 6510 could be used for I/O and the SID chips may provide some features that Paula lacks. There were 12.5-17 million C64s sold so if the few percent increase in logic translated into a few million sales, the improved economies of scale could have paid for the increased design and production costs. It would have been easier if CBM had made sure an optimized C64 emulator was available shortly after launch although the 68000 likely has trouble emulating the C64 at full speed. A 68020 or 68030 was likely needed for full speed emulation. The Amiga keyboard has a MOS/CSG 6570 which is 6502 family. Maybe with a little more thought, the Amiga keyboard could have been used like the PiStorm to provide 65xx compatibility as well as keyboard duties. Just don't type fast while using emulation.

Hypex Quote:

In fact, being completely different to the C64, could have killed the Amiga off. The C16/Plus 4 confused the market, even though the C64 was incompatible with the VIC20 in similar ways. But by the time of the C64 it had established itself as the Commodore standard. This was demonstrated in the C128 which was unable to become an own machine and a superior follow up, but was somewhat crippled with being forced to be compatible with the C64, with the efforts the designers went to doing so proving this. The only main feature was a hires mode, but it had no sprites, and without even the superior Plus 4 palette would not have survived on its own. The C64 became like the IBM PC as it became like the Commodore ISA (Industry Standard Architecture). Except as the Commodore Standard Architecture (CSA). But unlike the PC, which was able to be expanded even to this day, the C64 managed to be positioned in such a way that the hardware couldn't be expanded in a compatible way. Perhaps the C65 would have challenged that. (Despite oddly named model). To do so it really would have needed be around when the C128 came out IMHO. But without the shadow growing from the Amiga.

CBM logic was replacing designs with new designs rather than incremental improvements to existing designs. The C64 could have had incremental upgrades but it stayed as is unlike the Apple II.

1977 Apple II 6502@1.023MHz 4kiB
1979 Apple II+ 6502@1.023MHz 16kiB
1983 Apple IIe 6502@1.023MHz 64kiB
1984 Apple IIc 65C02@1.023MHz 128kiB
1986 Apple IIGS 65C816@2.8MHz 256kiB

CBM provided the same treatment of minimal upgrades for the Amiga. Mac hardware started much inferior to the Amiga but incremental upgrades surpassed the Amiga with a high margin high end the Amiga lacked. The incremental upgrades eroded CBM hardware advantages until it needed to be replaced. CBM had non-Amiga plans including their PC clones before margins fell off a cliff in the early 1990s and Hombre. There were x86 and RISC replacements for the 68k, non-compatible chipset replacements and 3rd party AmigaOS replacements in the works although they kept their options open for continuation of the 68k Amiga with AmigaOS. The 68k Amiga was different than the C64 as it was more upgradeable and expandable than previous generations of computers which allowed to upgrade hardware while retaining the compatibility which was growing in importance. CBM didn't seem to comprehend or adapt to changing markets which is why they are dead now.

@matthey

Quote:

The 68k should still scale up in performance better than x86

Fiction.

68K lost the Mhz race e.g. 68060 3.3V at 600 nm process node lost against Pentium "P54C" 600 nm process node.

Pentium "P54C" 600 nm process node ranges from 75 Mhz to 100 Mhz.

Pentium 60/66 has an 800 nm process node.

40MHz 68040 was fabbed on a 650 nm process node.

IBM PowerPC 601 with 650 nm process node was able to reach 110 to 120 Mhz.

Cyrix Cx5x86-100GP with 650 nm process node was able to reach 100Mhz.

_________________
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

@Hypex

Quote:

Hypex wrote: What!? A VIC-IIII/VIC-IV? That makes no sense! The C=/VIC chipset wasn't a planar design. It was based on Commodore chunky. A C16/Plus 4 which used VIC style bitmaps would have been more compatible.

C65's VIC-III (CSG 4567 R5) has an 8 bitplanes for its 256 colors which is influenced by the Amiga. CSG invested in a 2-micron process node for the C65 project which was canceled in 1991.

In 1990, Commodore was promoting C65 among the U.S. 3rd party game developers while PC's Wing Commander's 1990 release was the nuke drop.

SNES's 1991 release made sure any Commodore's in-house gaming platforms were pushed out of the North American market.

C65's 8 bitplane 256-color capability is the closest analog to SNES's chunky pixels 256-color capability.

For about two years, Commodore left SNES unanswered in the North American marketplace.

Gaming PC's SVGA clones backed by higher CPU power were already prepositioned to counter SNES. Gaming PC's higher CPU power with fast VGA delivered a different gaming experience from SNES's strong 2D gaming experience.

The delivery of certain gaming experiences is linked to the platform's general market acceptance over the raw hardware specs debates. Most consumers are just users i.e. they don't give a damn about technical debates.

Quote:

By Commodore chunky I mean the character based chunky used in MCM. Which unlike even common linear chunky had pixel width to match bit pack width. The only mode compatible to planar would be standard bitmap mode but so are all 1 bpp framebuffers. The subjects of this thread like using engineered 6502 over 68000 remind me of ideas like putting dual SIDs in the Amiga. But the Amiga wasn't a C64. In fact before it was bought out the Amiga wasn't a Commodore at all. So while I can see why people make those suggestions, they don't make sense for the Amiga. The Commodore logo on an Amiga case doesn't make it a direct follow up to the C64. In fact, being completely different to the C64, could have killed the Amiga off. The C16/Plus 4 confused the market, even though the C64 was incompatible with the VIC20 in similar ways. But by the time of the C64 it had established itself as the Commodore standard. This was demonstrated in the C128 which was unable to become an own machine and a superior follow up, but was somewhat crippled with being forced to be compatible with the C64, with the efforts the designers went to doing so proving this.

C128 is just an "ECS job" i.e. C64 gaming mode via VIC-II E with a separate #metoo high-resolution text mode via MOS 8563 (80-column text, recycled from C900).

Denise's ECS has a separate 4 color registers and 64 color palette that is not common with 32 color registers and 4096 color palette.

The original intention with Denise ECS has 8 color registers and a common 4096-color (12-bit) palette and the Commodore LSI group rejected this plan due to complexity and they had enough of the stupid arguments between the time-wasting monochrome high-res Denise vs color high-res Denise debates.

Last edited by Hammer on 12-Aug-2024 at 08:58 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

source:
https://en.wikipedia.org/wiki/Instructions_per_second
Just as the 68010 was about a 10% improvement over the 68000 as you can see in this chart.
The 030 was a almost 100% improvement over the 68000...but still 25% less efficient than the original 6502.

My interpolations for the 65C02 and 65CE02 are based on their own declared improvements. 20% over the 6502 from the 65C02 and 65816 and another 25% for the 65CE02 over the 65C02.

The 65C02 fixed bugs in the 6502 (like the 68010 did over the 68000) and made many instructions execute in 1 cycle hence the overall '20%' improvement...added 29 instructions.

The 65CE02 is an 8/16 design that also increased memory access speed in a couple of ways - reducing clocks required to access it...and again made almost all but memory access instructions take 1 cycle... You can read about it here: https://en.wikipedia.org/wiki/CSG_65CE02

Also, having MUL and DIV commands doesn't mean they actually speed up math.
https://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timstandard.HTML
70 cyles for MUL and 152 for DIV? A waste. Most game-coding is done with a function call to a LUT. Nobody has time for that poop. Again, the 65XXX family does faster memory access. Not to mention the Overflow flag on the 65xxx line makes chaining math across many bytes a trivial affair.

This is why all the real math has been pushed to external chips. Get with the times. Also, math is a small part of what makes general code.


@cdimauro

the 65816 was available in 1984 at 4Mhz (as was the 65C02) before the A1000 launch...and much cheaper and has 16 bit instructions. Besides that the 6502 was doing 4Mhz in 1982. It's the video processor that limits even Amiga's bus clock to 3.57Mhz. Having a cpu that doesn't require 32 cycles to access memory on some instructions would have been quite an improvement, no? Oh but it was 'programmer-friendly' ... I leave compilers to the task of making coding programmer-friendly.

Most other 8bit platforms were running at 1.79Mhz only Commodore was running it slower pre-C128.
Most developers treated the C128 as a ~30% accelerator for the C64.
Example: Sonic The Hedgehog, Eye of the Beholder, Elite 128, Ultima 5 had a dedicated port...

The video processor speed is the limitation of many systems...hence your shackled bus outside of fast-memory expansions. Once Commodore added a DMA controller via REU, many doors opened there as well. This is why I generally ignore 'expansions' and deal with what was available and when and for how much. The Amiga was shackled to it's chipset and over-priced cpu. Let's not forget that Amiga's graphics were in 3 bit planes vs 1 ... you had to move about 3 times more data to get things done. So good for you for having a wider bus...you needed it! So congrats on your 16bit claim to fame! Congrats that the A3000 improved it to 32bits...but as I keep repeating - no one could afford it...and now we're in 1990....and again the lowest common denominator was the A500.

In 1988 the 65CE02 was doing 10Mhz. Again - much MUCH faster than a 1987 - 7.14 Mhz A500/A2000.
In 1990 when the UNAFFORDABLE A3000 launched with a 25Mhz '030 we already had Sanyo making 12+Mhz 65816s. The 65XXX family has always been ahead of the 68000 until the over-priced and late '040. Some would say the unaffordable A3000 and A4000 is what killed them.

The CD32 was the last gasp and it offered too little, too late for too much $$$.

Last edited by Lou on 12-Aug-2024 at 04:46 AM.

@Hypex

Perhaps there something I’m not seeing, when I was used C64, it was only used for games, I remember there was some programs for it, but my mom/dad never used it for that, perhaps 1 in 8 C64 was used for more than games. I can’t say the tools where unusable, because I never used these programs, I doubt there was a large base of C64 the in office. There was Commodore Electric typewriters. Sure, they should have pushed C64 into the office space more. Perhaps this was one more commodore failure. If they had established the professional, office book writer’s tools, at time, they can easily have got these users on to the Amiga later, this should have given the Amiga stronger market position. However, I think history go down as it did despite this. the lack of modularity, and too expensive A2000, it did offer much from a standard A500, except a bigger box and a higher price. As I understand it you need an upgrade card to get a hard drive controller. Selling computer on how many upgrades lots it has to public, who does know what they need upgrade slots for, he he does make much sense. Commodore also pushed, now your computer can be msdos compatible, they should have done the reverse, told everyone Commodore were standard, sold Amiga upgraded kits to PC market instead, bad marketing, bad marketing and bad marketing all the way to the grave.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Hammer Quote:

68K lost the Mhz race e.g. 68060 3.3V at 600 nm process node lost against Pentium "P54C" 600 nm process node. Pentium "P54C" 600 nm process node ranges from 75 Mhz to 100 Mhz. Pentium 60/66 has an 800 nm process node. 40MHz 68040 was fabbed on a 650 nm process node. IBM PowerPC 601 with 650 nm process node was able to reach 110 to 120 Mhz. Cyrix Cx5x86-100GP with 650 nm process node was able to reach 100Mhz.

Motorola lost the MHz race but not the 68k. It was never the 68060 vs Pentium but PPC vs Pentium.

1990 68040 6-stage
1994 68060 8-stage

1993 PPC601 4-stage
1994 PPC603 4-stage
1994 PPC604 6-stage
1995 PPC603e 4-stage
1996 PPC604e 6-stage

1993 P5 5-stage
1994 P54C 5-stage
1995 P6 14-stage
1997 P55C 6-stage

1995 5x86 6-stage
1995 6x86 7-stage

The PPC603e reached 300MHz which was one of the highest clock speeds for a desktop CPU but it was achieved with a more expensive 350nm processes and doubling the caches to improve poor performance required more transistors than the 68060. Doubling the caches again likely would have limited the clock speed as the PPC604e had a lower max clock speed than the PPC604. PPC needed deeper pipelines and more efficient caches to compete in the MHz race. The circa 1997 Exponential Technology x704 had a 6-stage pipeline and likely reached at least 400MHz which it did by shrinking the L1 caches (2kiB-I+2kiB-D) to improve access time and adding a small on chip 32kiB L2. The 2kiB instruction cache roughly has the performance of a 68k 512 byte cache like the 68020/68030 according to more recent RISC-V research. The x704 had competitive clock speeds with the DEC Alpha but predictably poor performance and used more power. Both suffered from the instruction cache bottleneck due to poor code density and on-chip L2 caches made CPUs more expensive (Alpha 21064 without L2 used 1,680,000 transistors while successor Alpha 21164 with on-chip L2 used 9,300,000 transistors). If you want to complain about the price of 68k CPUs, take a look at Alpha CPU prices which sometimes exceeded Amiga computer prices.

https://en.wikipedia.org/wiki/Alpha_21064#History Quote:

The 21064 was unveiled at the 39th International Solid-State Circuits Conference (ISSCC) in mid-February 1992. It was announced on 25 February 1992, with a 150 MHz sample introduced on the same day. It was priced at $3,375 in quantities of 100, $1,650 in quantities between 100 and 1,000, and $1,560 for quantities over 1,000. Volume shipments began in September 1992. In early February 1993, the price of the 150 MHz version was reduced to $1,096 from $1,559 in quantities greater than 1,000. On 25 February 1993, a 200 MHz was introduced, with sample kits available, priced at $3,495. In volume, it was priced at $1,231 per unit in quantities greater than 10,000. Volume orders were accepted in June 1993, with shipments in August 1993. The price of the 150 MHz version was reduced in response. The sample kit was reduced to $1,690 from $3,375, effective in April 1993; and in volume, it was reduced to $853 from $1,355 per unit in quantities greater than 10,000, effective in July 1993. With the introduction of the Alpha 21066 and the Alpha 21068 on 10 September 1993, Digital adjusted the positioning of the existing 21064s and introduced a 166 MHz version priced at $499 per unit in quantities of 5,000. The price of the 150 MHz version was reduced to $455 per unit in quantities of 5,000. On 6 June 1994, the price of the 200 MHz version was reduced by 31% to $544 to position it against the 60 MHz Pentium; and the 166 MHz version by 19% to $404 per unit in quantities of 5,000, effective on 3 July 1994.

The Alpha 21064 had a 7-stage pipeline and no L2 cache. The 68060 had an 8-stage pipeline but could only achieve 50MHz despite 66MHz testing and announcements.

https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/080502.pdf Quote:

Price & Availability The 50-MHz 68060, 68LC060, and 68EC060 are now sampling to selected beta sites. General samples will be available 3Q94, with production to follow late in that quarter. Prices are $263, $169, and $150, respectively, in 10,000-unit quantities. Production quantities of the 66-MHz 68060 will be available late in 4Q94, according to the company; no price has been announced. For further information, contact Motorola at 512.891.2917.

If there are any doubts that pipeline depth is the primary enabler of higher clock speeds then take IBM's word for it.

https://datasheets.chipdb.org/IBM/x86/6x86/6x86_ALL.pdf Quote:

The IBM 6x86 CPU is superscalar in that it contains two separate pipelines that allow multiple instructions to be processed at the same time. The use of advanced processing technology and the increased number of pipeline stages (superpipelining) allows the IBM 6x86 CPU to achieve clocks rates of 100 MHz and above.

The 68060 has one more pipeline stage than the Cyrix 6x86 that IBM licensed to produce. Just having a deeper pipeline doesn't guarantee higher clock speeds. The pipeline stages need to be balanced and critical timing logic optimized which requires work that was obviously minimized for the 68060 when it became an embedded CPU that was not allowed to compete with PPC.

Lou Quote:

source: https://en.wikipedia.org/wiki/Instructions_per_second

You can read the Wiki source.

https://web.archive.org/web/20200309132442/https://drolez.com/retro/ Quote:

I also tried to estimate to power in MIPS of these old processors using the theorical cycles needed for basic machine language instructions.

This is followed by a chart of instruction latencies in cycles. This is most likely VAX style MIPS or actual Millions of Instructions per Second executed based on the average cycle time per instruction. VAX MIPS and DMIPS are completely different benchmarks and comparing results is comparing apples to oranges. The DMIPS benchmark was created because it is better to measure how much time is required for a workload rather than how many instructions are executed in a second. The ARM Thumb benchmarks I mentioned above increased the instruction count from ARM to Thumb code by 22% on average. Much of the increase in instructions is caused by fewer registers and less encoding space for immediates and displacements which is a larger problem for the 6502 than Thumb while performance metrics show that the 68k with 16 GP registers has instruction counts and memory traffic that is competitive with RISC ISAs using 32 GP registers due to CISC memory accesses, powerful addressing modes and 16-bit VLE with variable sized immediates and displacements. You may think that Thumb with a 22% instruction count increase would be thrown away but ARM doesn't have 22% better performance than Thumb because of instruction cache misses. Modern CPUs are faster than memory so the CPU stalls doing nothing when the data is not available in cache. Even with caches, memory/cache traffic would be a major bottleneck for the 6502. The best way for the 6502 to get around this problem is with SRAM but memory needs to be kept small. This is why 6502 family MCUs are still used but there are no competitive high performance 6502 family CPUs.

Lou Quote:

Just as the 68010 was about a 10% improvement over the 68000 as you can see in this chart. The 030 was a almost 100% improvement over the 68000...but still 25% less efficient than the original 6502. My interpolations for the 65C02 and 65CE02 are based on their own declared improvements. 20% over the 6502 from the 65C02 and 65816 and another 25% for the 65CE02 over the 65C02. The 65C02 fixed bugs in the 6502 (like the 68010 did over the 68000) and made many instructions execute in 1 cycle hence the overall '20%' improvement...added 29 instructions. The 65CE02 is an 8/16 design that also increased memory access speed in a couple of ways - reducing clocks required to access it...and again made almost all but memory access instructions take 1 cycle... You can read about it here: https://en.wikipedia.org/wiki/CSG_65CE02

More transistors and better silicon can improve most if not all 6502 instructions down to 1 cycle latency. This improves the performance when instructions are available to execute but does not solve the 6502 memory/cache bottleneck when caches are involved and the instructions are relatively weak increasing instruction counts. MIPS using SRAM memory may be acceptable performance but DMIPS using caches would likely be weaker performance than RISC.

architecture | I-cache traffic | D-cache traffic | total memory/cache traffic
accumulator poor poor bad
RISC poor good mediocre
CISC good good excellent

Accumulator architectures were popular because they are tiny and tiny cores are still an advantage in some cases. The 6502 packs a surprising punch for the size, especially with SRAM, but don't expect it to scale to modern high performance.

Lou Quote:

Also, having MUL and DIV commands doesn't mean they actually speed up math. https://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timstandard.HTML 70 cyles for MUL and 152 for DIV? A waste. Most game-coding is done with a function call to a LUT. Nobody has time for that poop. Again, the 65XXX family does faster memory access. Not to mention the Overflow flag on the 65xxx line makes chaining math across many bytes a trivial affair. This is why all the real math has been pushed to external chips. Get with the times. Also, math is a small part of what makes general code.

It is true that many games used low precision lookup tables for integer MUL and DIV which the 68000 continued to do as well. While the 68000 MUL and DIV instructions were too slow for many game uses, the higher precision MUL and DIV instructions were savers where needed since lookup tables grow large and take valuable memory. MUL 16x16=32 is good for 16x16=16, 16x16=32+32 MAC uses for DSP algorithms, greatly simplifies 32x32=32 and allows some division by a constant to be converted to multiplication which is far from useless. Software division algorithms are large and costly when less commonly needed. Hardware MUL and DIV are expensive in resources, especially when optimized for performance, which is why the 68000 instructions have poor performance. They were probably a better option than a barrel shifter which they also wanted to add. The 68020 added a 32-bit barrel shifter and 32/64 bit MUL and DIV which didn't leave enough resources for better optimized MUL and DIV. Engineering is the art of compromise. It's amazing what the computer pioneers created with so few transistors and so many limitations. Today, the CPU logic is limited more by development time as the vast majority of transistors are used for caches. This is the reason why the 68k is still viable and the 6502 is not.

Last edited by matthey on 12-Aug-2024 at 09:38 PM.

@matthey

I knew you'd know MUL and DIV weren't the godsend that these 68k zealots whine about...

16 bit math isn't hard on an 8 bit chip, that said the 65816 can do 16bit add and sub...

Here's a nice video on some of the 6502 family describing how math was done and how even Bill Mensch had a 32 bit design but simply recommend ARM to his customers at that point:

https://www.youtube.com/watch?v=acUH4lWe2NQ

This video specifically shows a graph of relative power of the cpus of the time. Even shows an 8 Mhz 65C02 Doom demo on the Commander X16.

Basically so the zealots don't have to take my word for it.

Last edited by Lou on 12-Aug-2024 at 11:05 PM.