@matthey

Quote:

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

Fact: 68K lost the Mhz race.

I have 600 nm process node 68060 Rev1 on my TF1260 and its stable clock speed is about 62.5 Mhz. Semi-modern 68060 accelerators have software clock speed settings and a memory system designed for at least 100 Mhz operation i.e. 100 Mhz SDRAM with TF1260.

600 nm process node Pentium P54C has a 75 Mhz to 100 Mhz range in large-scale volume production.

68060 needs a 420 nm process node to reach 100 Mhz.

Against 486DX4 and 486 enhanced Am5x86, 68040 lost the clock speed race including the newer 68040V 3.3v variant.

Quote:

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

1. That's useless when the FPU also has its pipeline depth. Clock speed attainment is only as fast as the slowest part in the CPU.

2. Pentium FPU has a longer pipeline. Pentium FPU has 8 stage pipeline depth.

3. Your paper argument remains paperweight against real-world results.

Using a 350 nm process node, Am5x86 reached 150 Mhz via AMD-X5-150ADZ SKU, https://en.wikichip.org/wiki/amd/am5x86

Other 350 nm process node CPU designs have reached beyond the 200 Mhz range.
https://en.wikichip.org/wiki/350_nm_lithography_process


Quote:

@matthey The Alpha 21064 had a 7-stage pipeline and no L2 cache.

68060 also doesn't have an L2 cache.

DEC Alpha 21064A @ 300MHz has a 150 Mhz bus speed and is 64-bit wide. When the CPU is used as a graphics render device, memory bandwidth is important.

DEC Alpha 21064A @ 300 MHz uses a 500 nm process node.

Quote:

@matthey The 68060 had an 8-stage pipeline but could only achieve 50MHz despite 66MHz testing and announcements.

You omitted the FPU pipeline.

Alpha 21064's integer pipeline has 7 stages while the floating-point pipeline has 10 stages.

Clock speed attainment is only as fast as the slowest part in the CPU.

Reaching high clock speed is an art in itself, hence the importance of gaining ex-DEC Alpha engineers and knowledge for the X86 CPU vendors.

A real "big iron" workstation has ECC memory support.


Quote:

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

IBM 6x86 CPU is just Cyrix 6x86 clone. IBM and SGS-Thomson have a license cloned of Cyrix 6x86.

IBM 6x86 2V2P166GE using IBM's 650 nm process node reached 133 Mhz.

Cyrix PR266-MMX using IBM's 350 nm process node reached 208 Mhz.

AMD's K6 using a 350 nm process node reached 233 Mhz.

Intel Pentium II "Klamath" using a 350 nm process node reached 300 Mhz.

----------------------

For 250 nm process node,

IBM 6x86 Models CVAPR333GF reached 250 Mhz.

AMD K6-2 reached 550 Mhz. K6-III reached 450 MHz. K7 Athlon "Argon" reached 700 Mhz.

Intel Pentium II "Deschutes" reached 450 Mhz. Pentium III "Katmai" reached 600 Mhz.

By 250 nm and 180 mn process nodes, AMD and Intel engaged in a Ghz clock speed race leaving Alpha and PowerPC behind.


Quote:

@matthey 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.

Clock speed attainment is only as fast as the slowest part in the CPU.

Semi-modern 68060 accelerators have software clock speed settings and a memory system designed for at least 100 Mhz operation i.e. 100 Mhz SDRAM with TF1260.

Real-world result trumps paper arguments.

The X86 world didn't stay with P5 microarchitecture.

PS; X86 world's mobile SKUs doubles as embedded SKUs.

68060's 32-bit bus is already handicapped against a 64-bit external bus equipped with PowerPC.

Last edited by Hammer on 13-Aug-2024 at 04:46 AM.
Last edited by Hammer on 13-Aug-2024 at 04:43 AM.
Last edited by Hammer on 13-Aug-2024 at 04:39 AM.
Last edited by Hammer on 13-Aug-2024 at 04:33 AM.
Last edited by Hammer on 13-Aug-2024 at 04:04 AM.
Last edited by Hammer on 13-Aug-2024 at 03: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: @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.

It's not PC's "Doom". PC has FastDoom for slower 386SX CPUs.

For SNES Doom, 16-bit RISC CPU-DSP SuperFX2 @ 20 Mhz was used in place of 65816 for a reason. SuperFX's designers created the Argonaut RISC Core (ARC).

68020/68030 has reasonable ADD instructions, but the MIPS camp attacked its MUL instruction weakness.

Commodore X16 doesn't run a 32-bit desktop OS.

65xx CPU's slow R&D road map and weak supply at a certain clock speed are the major issues.

I agree with the Apple executive's shouting match against Bill Mensch's a bag of 65816 BS. WDC's 8 Mhz promise at sufficient yield was POS.

ARC's and ARM's existence was born from 65K's slow R&D map.

ARC-V has adopted RISC-V ISA.

Last edited by Hammer on 13-Aug-2024 at 05:32 AM.
Last edited by Hammer on 13-Aug-2024 at 05:21 AM.
Last edited by Hammer on 13-Aug-2024 at 05:03 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: @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.

Which means NOTHING since you continue to use MIPS/IPC as a measure, which is completely meaningless.

What count is PERFORMANCE: give the processor a CONCRETE task and let's see how long it takes to accomplish it.
Do it for very different applications code (e.g. SPEC? EEMBC?) and you can get an idea of how it goes.
Quote:

The 65CE02 is an 8/16 design

That's completely false: it's a 8 bit design, where a few 16-bit instructions were added.
Quote:

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

See above: meaningless.
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.

It depends on what you need to do. I've used a few times those instructions, and if I've used them it's because there was no chance to use shifts + adds/subs to replace them.

One example is calculating the square root of a 32-bit value which I needed for USA Racing (the racing car game which I was working on): I've created an algorithm that needed one DIV (32 / 16) which already gave a good appoximation, and with two DIVs it gave me an exact value.

Try to do it on your 65xx toys...
Quote:

Most game-coding is done with a function call to a LUT. Nobody has time for that poop.

You can't always use LUTs, especially on systems with very limited RAM.
Quote:

Again, the 65XXX family does faster memory access.

Irrelevant. As I've said, what's important is the time that they took to perform a task.
Quote:

Not to mention the Overflow flag on the 65xxx line makes chaining math across many bytes a trivial affair.

Irrelevant as well. Plus, many processors have this flag as well.
Quote:

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.

Basically you're admitting that the 65xx processors are weak processors because they required external chips for more complex computation.

I reveal you a secret: if companies were forced to add complex math on external chips it was because the 65xx sucked at that. And since this math was ESSENTIAL, they needed another solution.
Quote:

@cdimauro the 65816 was available in 1984 at 4Mhz (as was the 65C02)

Are you becoming a bot as well? It was already reported the problems that this chip had. Why don't you go and ask Apple why it hasn't used it...
Quote:

before the A1000 launch...

ROFL: again with your time machine.

The Amiga 1000 was built all around the 68000 STARTING FROM THE 1982! You CANNOT change a project in such advanced state only to add a CRAP processor which would have completely CRIPPLED its future.

The 68000 already had a 24-bit address space, which is MAXIMUM that ALL 65xx members family can get, and always using... rolling drum... BANK SWITCHING... which KILLS performances on such processors.

Do you know which basic data structure was used everywhere on the Amiga o.s.? I don't think so.
Well, it's a DOUBLE LINKED LIST. The one which I gave as homework, and you never completed. Guess why: it's too complicated for your crap processors...
Quote:

and much cheaper

Who cares? The 68000 was cheap enough at the time.
Quote:

and has 16 bit instructions.

Sure. And you can use only those, because if you've to read/write bytes then you've to SWITCH the processor mode and THEN you can use bytes (and NOT 16-bit for the same stuff).

I think that you've never opened the 65816 programmer's manual, right? But don't worry: if you open the 65832 is even worse when dealing with 32, 16, and 8-bits.
Quote:

Besides that the 6502 was doing 4Mhz in 1982.

Irrelevant e totally meaningless: it's even more crappier than the 65816 for being used on an Amiga.
Quote:

It's the video processor that limits even Amiga's bus clock to 3.57Mhz.

The same for all Commodore machines: you clearly don't know how they work...
Quote:

Having a cpu that doesn't require 32 cycles to access memory on some instructions would have been quite an improvement, no?

As I've said, it depends on the task. Any example?
Quote:

Oh but it was 'programmer-friendly' ...

Exactly!
Quote:

I leave compilers to the task of making coding programmer-friendly.

Which generates even worse code and kills more the performances of your beloved processors...
Quote:

Most other 8bit platforms were running at 1.79Mhz only Commodore was running it slower pre-C128.

Do you know when the C64 was DEVELOPED?
Quote:

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...

And?
Quote:

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.

This is another prove of how much sucked such processors, which required external hardware even for elementary and fundamental operations like copying memory...
Quote:

The Amiga was shackled to it's chipset and over-priced cpu.

With very good results.
Quote:

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.

I think that you've never programmed an Amiga, right?

But it's your statement: show me an example of what you've stated.
Quote:

So good for you for having a wider bus...you needed it!

Sure. And I've heavily used on my games (USA Racing and Fightin' Spirit). Something which would have been impossible with a crappy 65xx processor.
Quote:

So congrats on your 16bit claim to fame!

Thanks. I've liked a lot.
Quote:

Congrats that the A3000 improved it to 32bits...

I've already revealed you the secret: even the A1000 had 32 bits accelerators...
Quote:

but as I keep repeating - no one could afford it...

See above.
Quote:

and now we're in 1990....and again the lowest common denominator was the A500.

Whereas for the 65xx was?
Quote:

In 1988 the 65CE02 was doing 10Mhz. Again - much MUCH faster than a 1987 - 7.14 Mhz A500/A2000.

Nevertheless, you CANNOT use it to replace a 68000 for the above reasons.
Quote:

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.

And... who cares? I had an A1200 with a 68EC020 at 14Mhz, which was cheap and good for what it offered.
Quote:

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

Right, and?
Quote:

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

No, because we had much more to use. But at least MULs and DIVs were there when needed and they MADE THE DIFFERENCE.
Quote:

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

See above: yes, and that's fine only if you need to manipulate 16 bits: mixing code with 8 bits is a NIGHTMARE on such processors.
Quote:

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:

Good recommendation, because it's even worse than the 65816 to program.
Quote:

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.

That's a complete lie: it's NOT a Doom. It's a demo.
Quote:

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

I don't need to know how to program those toys and what are their limits, thanks.

Whereas you don't know even basic stuff of your beloved crappy processors...

@matthey: I agree on everything.

@Lou

Quote:

Lou wrote: https://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timstandard.HTML

Ah... good old times :)

https://oldwww.nvg.ntnu.no/nvg/maskinpark/daneel.html

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Modern Vintage Gamer has a 3 month old video on the thread topic.

Doom didn't kill the Amiga...Wolfenstein 3D did
https://www.youtube.com/watch?v=wsADJa-23Sg

It's just crazy that CBM released AGA without chunky support. Modern Vintage Gamer has ports of Out Run and Strife for the Amiga. An Amiga video can get 745,494 views in 3 months but Amiga peasants must eat expensive and very old PPC cake.

@matthey

Quote:

matthey wrote: Modern Vintage Gamer has a 3 month old video on the thread topic. Doom didn't kill the Amiga...Wolfenstein 3D did https://www.youtube.com/watch?v=wsADJa-23Sg It's just crazy that CBM released AGA without chunky support. Modern Vintage Gamer has ports of Out Run and Strife for the Amiga. An Amiga video can get 745,494 views in 3 months but Amiga peasants must eat expensive and very old PPC cake.

That YouTube is incomplete. The real killer of Commodore was the higher cost A300/A600 and the cancellation of high demand A500.

Commodore Germany wanted the AA500 and a hard disk.

Bill Sydnes and Jeff Franks combined Commodore UK's A300 request with Commodore Germany's hard disk mandate and anti-GVP PCMCIA.

In 1991, Jeff Franks advocated for Amiga for low-end and Commodore PC clones for the mid-to-high product stack.

Jeff Franks pushed for PCMCIA. Bill Sydnes replaced Jeff Porter with Jeff Franks.

From Feb 1992, Mehdi Ali had to override Bill Sydnes/Jeff Franks product stack plans with a specific A1200 directive. Jeff Franks spec'ed AA600 which adds two extra months for AA Gayle and Budgie. AA600 turned into A1200.

In the CDTV division, Jeff Porter didn't forget WIng Commander from 1990. CD32 initially has an 8 MB RAM configuration.

Last edited by Hammer on 14-Aug-2024 at 03:07 AM.

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

@Hammer

When I bought the A1200 in January 1994, the store still had lots of A500+ systems for sale as well (more so than A600s). So I don’t know about "cancellation�, a saturated market seems more likely.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @Hammer When I bought the A1200 in January 1994, the store still had lots of A500+ systems for sale as well (more so than A600s). So I don’t know about "cancellation�, a saturated market seems more likely.

I made my statement for the 1992 context based on David Pleasance's statements for the Commodore UK market.

1. A600 would have caused a perceived A500+ upgrade confusion. Commodore Germany advised AA500.

2. AA caused a "dead-end" situation for ECS.

Norway's market is a small market similar to New Zealand's. The entire Nordic group's market is equivalent to Australia. My point, Norway is tiny.

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

Quote:

Imagine our surprise when in May 1992 we took delivery of a large quantity of computers with the model number A600 and not A300! It transpired that after our Frankfurt meeting the German subsidiary – who had clearly missed the whole point of the need and demand for the A300 – had underhandedly told Mehdi Ali that they could not and would not sell any Amiga that did not have a hard drive included, thereby sabotaging the whole well-thought-out plan to entice C64 buyers into an affordable upgrade path. Mehdi Ali simply rolled over and conceded, but never had the balls to talk to me or any other GM about the change of plan. This A600 would become a catastrophic disaster for the following reasons: Though it was smaller and had fewer features than the A500, it cost more to manufacture. Being called the A600 gave consumers the impression it was a higher specification machine than the A500, resulting in sales of the A500 slowing down significantly, virtually destroying that existing (and profitable) market. We had prematurely killed off the A500 by introducing the A600 instead of the planned A300 – and on which we made considerably less money. Consumers who bought the A600 believing it to be a superior model to A500 were very upset, believing they had been misled (which of course they had). The press, with whom we had an excellent relationship, absolutely lambasted our misguided rationale, and justifiably so. AMIGA 500 PLUS Although it was officially introduced in the spring of 1992, at around the same time, Commodore had already sold out of the remaining stocks of Amiga 500s before the run up to the profitable Christmas sales period. So in order to meet the demand for A500s before Christmas, Commodore used stocks of the new 8A revision motherboards destined for the A500 Plus.

Last edited by Hammer on 14-Aug-2024 at 03:29 AM.
Last edited by Hammer on 14-Aug-2024 at 03:21 AM.
Last edited by Hammer on 14-Aug-2024 at 03:17 AM.
Last edited by Hammer on 14-Aug-2024 at 03:14 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

@cdimauro

You win the strawman award!

You reply to me on a sentence by sentence basis taking my context out.

It's pathetic really.

You want a source to 68000 instruction timings, how's about you google it instead of being a zealot in disbelief. DIV on a 68000 takes 140-152 cycles. Wow what a champion of a cpu!

Here's a review of an actual C65/64DX:
https://www.youtube.com/watch?v=OoHxDe3Gc9E

Even that guy says that the 3.57Mhz 65CE02 blows away the 7.14 Mhz Amiga and it gave you chunky graphics and 320×200×256; 640×200×16; 640×400×16; 1280×200×4; 1280×400×4; palette of 4096 colors. It also came with dual SIDs for 6 channel stereo, so again:

it outperformed your false-godly-worshipped Amiga in 1990.

In the end, the reviewer stipulated that too many Amiga owners would have been butt-hurt by it's release. I concur.

Last edited by Lou on 15-Aug-2024 at 12:39 AM.
Last edited by Lou on 15-Aug-2024 at 12:36 AM.

@Lou

Quote:

Lou wrote: @cdimauro You win the strawman award!

How childish can become a supposed man which is unable to sustain a discussion...
Quote:

You reply to me on a sentence by sentence basis

I've to correct you: even splitting a single sentence in multiple pieces, and get proper replies for each of them.
Quote:

taking my context out.

That was never the case, but I'm very happy to see you quoting me and prove it, eh!
Quote:

It's pathetic really.

Oh, yes: it's pathetic only because you say it. Sure, sure.

You need a truck of napkins to dry your tears...
Quote:

You want a source to 68000 instruction timings,

I NEVER wanted it. You don't understand what people write...
Quote:

how's about you google it instead of being a zealot in disbelief.

Sorry, disbelief of WHAT?!?
Quote:

DIV on a 68000 takes 140-152 cycles. Wow what a champion of a cpu!

Sure. And it was nice to have it. Imagine now to write a complete subroutine for your crappy 65xx to do the same and... time it.

That's the next homework for you, dear super-skilled low-level coder...
Quote:

Here's a review of an actual C65/64DX: https://www.youtube.com/watch?v=OoHxDe3Gc9E Even that guy says that the 3.57Mhz 65CE02 blows away the 7.14 Mhz Amiga

He can say whatever he wants -> it doesn't mean that it's true.

You should know me already: care to PROVE it?
Quote:

and it gave you chunky graphics and 320×200×256; 640×200×16; 640×400×16; 1280×200×4; 1280×400×4; palette of 4096 colors.

Again with this chunky graphics: it was PLANAR. PLA-NAR!
https://www.c64-wiki.com/wiki/C65#Video

True bitplane graphics:
320 x 200 x 256 (8-bitplane) non-interlaced.
640 x 200 x 16* (4-bitplane) non-interlaced (plus sprite and border colours).
1280 x 200 x 4* (2-bitplane) non-interlaced (plus sprite and border colours).
320 x 400 x 256 (8-bitplane) interlaced.
640 x 400 x 16* (4-bitplane) interlaced (plus sprite and border colours).
1280 x 400 x 4* (2-bitplane) interlaced (plus sprite and border colours).

Ignorant!
Quote:

It also came with dual SIDs for 6 channel stereo, so again:

Sure. 6 x FM channels on... 1991.
Quote:

it outperformed your false-godly-worshipped Amiga in 1990.

Where? Care to PROVE it?
Quote:

In the end, the reviewer stipulated that too many Amiga owners would have been butt-hurt by it's release. I concur.

Sure, I trust him only because HE said.

@Lou

From Commodore - The Final Years,
Quote:

The engineers wanted to allow the then-new Motorola 68040 processor to work with the next generation of Amigas. And of course, the architecture would work with the upcoming AAA chipset, as well as the more imminent AA. And because AAA was designed to work with different processor families, Haynie wanted his Acutiator motherboard to also handle different processors. Specifically, there were at least three major RISC processor families at that time and he wanted Acutiator to accept these RISC chips. Their architecture required three custom chips: EPIC, AMOS, and SAIL. In cost comparisons, Haynie calculated that the Acutiator architecture would add approximately $125 to a system (including the cost of a 68EC040 chip), resulting in a $300 retail price increase. This was a bargain, considering the user received a significant processor upgrade.

Without Acutiator's custom chips, a lower cost of 68EC040 would be out of reach from AA Amiga.

Last edited by Hammer on 15-Aug-2024 at 09:07 AM.

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

@Hammer

Quote:

Hammer wrote: @Lou From Commodore - The Final Years, Quote: The engineers wanted to allow the then-new Motorola 68040 processor to work with the next generation of Amigas. And of course, the architecture would work with the upcoming AAA chipset, as well as the more imminent AA. And because AAA was designed to work with different processor families, Haynie wanted his Acutiator motherboard to also handle different processors. Specifically, there were at least three major RISC processor families at that time and he wanted Acutiator to accept these RISC chips. Their architecture required three custom chips: EPIC, AMOS, and SAIL. In cost comparisons, Haynie calculated that the Acutiator architecture would add approximately $125 to a system (including the cost of a 68EC040 chip), resulting in a $300 retail price increase. This was a bargain, considering the user received a significant processor upgrade. Without Acutiator's custom chips, a lower cost of 68EC040 would be out of reach from AA Amiga.

My complaint has always been:
too little, too late, too expensive.

@cdimauro

The more you post, the more you expose your lack of knowledge. Can you explain how 8 bit-planes generates 256 programmable colors? The C64 had 2 types of graphics modes, both using a color LUT. Tiled-bitmap, still considered chunky but arranged in 8x8 pixel tiles and tiles-text graphics with the bits coming from a character-set LUT. Can you explain how that is bit-plane? Why wouldn't the VIC-III not offer a programmable color LUT and 8bit/1byte/256 color-map-LUT for that while maintaining C64 compatibility? How does a palette of 4096 colors come down to 256?

I suppose in your twisted brain, you believe the C64 (and NES)'s tile graphics are considered bit-plane because the pixel data is separate from the color data...and somehow you process that as 2 bit/byte-planes - but you are wrong...as usual.

Do you even know what a LUT is?

You depend on a wiki, what a joke.

Even in C64 mode, a C65 can use the extra color LUT just like a C128 in C64 mode could use extra features of the 128 .... Can you explain how a C64 now has bit-planes with a mere 64k of memory and in 1Mhz mode? If it's doing this in 1Mhz mode and is bit-planed, then it makes the Amiga look even worse... It's a lose-lose reality for you.
https://www.youtube.com/watch?v=kP46zIzbLpI

You attempted to insult the 128's VDC as if it's an insult coming from the C900. You again display your ignorance.
In the C900, it's blitter was programmed easier and it displayed 1024x800 graphics. It offered true bit-mapped graphics superior to what the lowly A1000 could display. No need for wiki - here you go:
https://www.youtube.com/watch?v=PbVjNInzrw8

In the C128, it runs on it's own 16mhz clock and requires a slower communication method to transfer ram from main memory to VDC ram.

Regardless of the slower communication vs direct access, the VDC can do impressive things in a 128: https://www.youtube.com/watch?v=NbFbQo_yB9I

"Because he said"...you still deny facts and common knowledge. I've played my share of A500 games, it's rare they hit 30fps. Bit-plane animation is inherently slow. The fancy fading effects don't justify it. They were cool in 1985 for a minute... The C128's VDC has EGA-like colors but offered up to SVGA-like resolutions without the Amiga-slowdown once the resolution goes up because the cpu and gpu were on different buses.

Troll.

Last edited by Lou on 15-Aug-2024 at 03:40 PM.
Last edited by Lou on 15-Aug-2024 at 03:33 PM.
Last edited by Lou on 15-Aug-2024 at 03:31 PM.
Last edited by Lou on 15-Aug-2024 at 03:14 PM.

@Lou

Quote:

Lou wrote: @cdimauro The more you post, the more you expose your lack of knowledge. Can you explain how 8 bit-planes generates 256 programmable colors?

I'm not the one which explains it, rather it's "just" elementary math which does it: 2^8 = 256...
Quote:

The C64 had 2 types of graphics modes, both using a color LUT. Tiled-bitmap, still considered chunky but arranged in 8x8 pixel tiles and tiles-text graphics with the bits coming from a character-set LUT. Can you explain how that is bit-plane? Why wouldn't the VIC-III not offer a programmable color LUT and 8bit/1byte/256 color-map-LUT for that while maintaining C64 compatibility? How does a palette of 4096 colors come down to 256? I suppose in your twisted brain, you believe the C64 (and NES)'s tile graphics are considered bit-plane because the pixel data is separate from the color data...and somehow you process that as 2 bit/byte-planes - but you are wrong...as usual. Do you even know what a LUT is? You depend on a wiki, what a joke. Even in C64 mode, a C65 can use the extra color LUT just like a C128 in C64 mode could use extra features of the 128 .... Can you explain how a C64 now has bit-planes with a mere 64k of memory and in 1Mhz mode? If it's doing this in 1Mhz mode and is bit-planed, then it makes the Amiga look even worse... It's a lose-lose reality for you. https://www.youtube.com/watch?v=kP46zIzbLpI

Well, it's very simple: it's enough for an average brain to read the Commodore's C65 documentation: https://www.devili.iki.fi/Computers/Commodore/C65/System_Specification/page1.html
C64DX SYSTEM SPECIFICATION
March, 1991
Commodore®

https://www.devili.iki.fi/Computers/Commodore/C65/System_Specification/Chapter_2/page81.html#2.4
A new "bitplane" video mode was added to allow the displaying of true bitplane type video, with-up to eight bitplanes in.320 pixel mode and up to four in 640 pixel mode. The 4567-can also time-multiplex the bitplanes to give a true four-color 1280 pixel picture. Vertical resolution is maintained at 200 lines as standard, but can be doubled to 400 with interlace.

https://www.devili.iki.fi/Computers/Commodore/C65/System_Specification/Chapter_2/page97.html
In BitPlane mode, the C4567R6 does not use the Video Bank select bits, like the old VIC chip did. Instead, You can specify which 8k block (in 320 mode), or which 16k block (in 640 mode) of memory you want a bitplane to come out of. Specify where you want the bitplanes to be fetched from, using Bitplane Address registers 0 through 7.

https://www.devili.iki.fi/Computers/Commodore/C65/System_Specification/Chapter_2/page98.html
The C4567R6, allows the programmer to use the sixteen standard "C64" colors, or define up to 256 custom colors and/or use the palette to perform boolean operations on the bitplane data. The C4567R6 incorporates a 16 word palette ROM and a has a 256 word palette RAM.
[...]
The first 16 locations of the palette default to the C64 colors in ROM. The remaining 240 locations are programmable RAM. The first 16 locations can also be replaced with RAM, however, by setting the PAL bit in control register "B".
[...]
To set the color palette, the user must simply write to the color palette RAM. Addresses D100-DlFF (hex) program the 256 Red values, addresses D200-D2FF (hex) program the 256 Green values, and addresses D300-D3FF (hex) program the 256 Blue values. All 256 locations of both the blue and green palettes are only 4 bits wide, so the upper four data bits do nothing.

The last answers your questions about the CLUT (because that's how LUT's Colour palette are called in the jargon, dear ignorant).

Now, if you don't like it, you're free to show me the C65's documentation which reports that it's using packed/chunky graphics, eh!
In the meanwhile I prepare the popcorns, ignorant!
Quote:

You attempted to insult the 128's VDC as if it's an insult coming from the C900.

Oh, and what's the problem here? Isn't the C900 another crappy system? Yes!
Quote:

You again display your ignorance. In the C900, it's blitter was programmed easier and it displayed 1024x800 graphics. It offered true bit-mapped graphics superior to what the lowly A1000 could display. No need for wiki - here you go: https://www.youtube.com/watch?v=PbVjNInzrw8

Have you ever seen this video?

The supposed Blitter was working so good and so "fast" that it was nice to see how soooooo "fast" the text was being written on the screen.
Quote:

In the C128, it runs on it's own 16mhz clock and requires a slower communication method to transfer ram from main memory to VDC ram. Regardless of the slower communication vs direct access, the VDC can do impressive things in a 128: https://www.youtube.com/watch?v=NbFbQo_yB9I

Sure, I see. Besides the vertical bars which are very fast to draw, in all other cases the animations were using... CHARACTERS for the moving parts.
Quote:

"Because he said"...you still deny facts and common knowledge.

What I've denied? Care to PROVE it?
Quote:

I've played my share of A500 games, it's rare they hit 30fps.

ROFL. Games on Amiga were usually 60 or 30 FPS (50 or 25 FPS on PAL systems), and you find that it was rare to have them running 30FPS?

Here's a clear proof that you've very serious problems.

BTW, the game which I've worked on, Fightin' Spirit, ran at 25FPS with occasional 17FPS hits, and it's moving A LOT of stuff in 64 colours: https://www.youtube.com/watch?v=K4jdNPsbdow

Try to do the same with your crappy C65...
Quote:

Bit-plane animation is inherently slow.

Imagine how it can be slow with the particular C65's bitplanes arrangements.
Quote:

The fancy fading effects don't justify it.

Fading are for demos, mostly. I prefer the games, and here the Amiga's hardware simply crashes your beloved C65.
Quote:

They were cool in 1985 for a minute...

Only for demos: games last much more.
Quote:

The C128's VDC has EGA-like colors but offered up to SVGA-like resolutions without the Amiga-slowdown once the resolution goes up because the cpu and gpu were on different buses.

ROFL You don't know what you talk about.

ON PAPER they are independent buses, but the VDC had very little space and the CPU has to COPY data from its memory to the VDC one, which is a SUPER SLOW OPERATION.

That's why you can only see some crappy demos like the ones that you've shown, and no game for it. If I'd to develop a game for the C128, I wouldn't used the VDC for sure, rather used the VIC-II, which at least had 8 sprites which I can also multiplex.
Quote:

Troll.

Ah, yes. Only because YOU've said it.

But after the pearls that you've reported on this comment, I leave other people to judge.

@cdimauro

Once again you prove your ignorance.
There is a sequential burst copy to the VDC ram of 255 bytes where a memory location can be written in sequence. The VDC has it's own internal 255 byte-copy function to move memory withing it's 64k. How do I know? I've written C128 software that I occasionally uploaded to BBS' back in the day.

You continue to prove your ignorance.
The C64 uses 1 BITPLANE for the pixels to show either a background or foreground color. The color is separated into 2 sets of 4 bits to set the foreground and background color for an 8x8 tile
... from the same palette of 16 colors for either. The pixel map simply displays 1 or the other.
Color is defined as 1000 bytes for a 40x25 tiled-screen. 4 bits define the background and for foreground from all 16 (4bit) colors. That's why in 640x200 mode that PIXEL bit-plane uses 16k instead of 8K. 320x200/8 = 8000bytes of graphic memory. Doubling = 16000, you 16k... This is not an increase in 'bit'planes. It's 1 chunky-mapped as they get set 8 bits at a time. The rest of what you described for how the colors get set don't change anything and is exactly how I said it - a color LUT. This again is not Bit-plane graphics, but again you keep looking silly. I mean who knew that 4x4x4 bit RGB definitions for programmable color would generate 4096 colors...like OMG - who knew MATH? I mean who knew programmable color was defined by red, green and blue values? Wow you are soooooo smart!

Changing how the color LUT works in different modes doesn't make this slow bit-planed graphics like the Amiga has. Having each pixel use 8bits for color would mean a 320x200 screen would use all 64k of memory. How much sense does that make in a mode where the machine only has 64k of memory?

Oh and that fancy BOING demo that 'only Amiga makes possible' LOL
https://www.youtube.com/watch?v=W9QEeGqrZGY

Last edited by Lou on 15-Aug-2024 at 08:55 PM.
Last edited by Lou on 15-Aug-2024 at 08:51 PM.
Last edited by Lou on 15-Aug-2024 at 08:49 PM.

@Lou

Quote:

Lou wrote: @cdimauro Once again you prove your ignorance. There is a sequential burst copy to the VDC ram of 255 bytes where a memory location can be written in sequence.

Which does NOT use any DMA, since the CPU has to load each byte to transferred and gently asking to the VDC to write it, with a ridiculously slow synchronization operation (as you should know. IN THEORY), which cripples the already scarse performance.
Quote:

The VDC has it's own internal 255 byte-copy function to move memory withing it's 64k.

Which was NOT about the CPU vs VDC RAM communication.
Quote:

How do I know? I've written C128 software that I occasionally uploaded to BBS' back in the day.

And you don't know how to write a simple exercise which I gave you?

Sure, I trust you, I trust you.
Quote:

You continue to prove your ignorance.

Really? Let's see...
Quote:

The C64 uses 1 BITPLANE for the pixels to show either a background or foreground color. The color is separated into 2 sets of 4 bits to set the foreground and background color for an 8x8 tile ... from the same palette of 16 colors for either. The pixel map simply displays 1 or the other. Color is defined as 1000 bytes for a 40x25 tiled-screen. 4 bits define the background and for foreground from all 16 (4bit) colors. That's why in 640x200 mode that PIXEL bit-plane uses 16k instead of 8K. 320x200/8 = 8000bytes of graphic memory. Doubling = 16000, you 16k... This is not an increase in 'bit'planes. It's 1 chunky-mapped as they get set 8 bits at a time.

That's how the C64 worked, not how it worked the NEW bitmap mode of the VIC-III.

Care to show its documentation? I've already shared it, and it's really strange that you continue to talk, talk, talk, but you're not giving not even a single link to the supposed 256 colours chunky mode. Guess what: because you have no clue at all of how it works, dear ignorant.
Quote:

The rest of what you described for how the colors get set don't change anything and is exactly how I said it - a color LUT. This again is not Bit-plane graphics, but again you keep looking silly. I mean who knew that 4x4x4 bit RGB definitions for programmable color would generate 4096 colors...like OMG - who knew MATH? I mean who knew programmable color was defined by red, green and blue values? Wow you are soooooo smart!

I've just replied to what YOU have said:

Why wouldn't the VIC-III not offer a programmable color LUT and 8bit/1byte/256 color-map-LUT for that while maintaining C64 compatibility? How does a palette of 4096 colors come down to 256?

do you recall it, or are you affected by the red fish syndrome?
Quote:

Changing how the color LUT works in different modes doesn't make this slow bit-planed graphics like the Amiga has.

Right, because C65 has a much worse bitplane implementation.

IF you've read how it works, which is clearly NOT the case.
Quote:

Having each pixel use 8bits for color would mean a 320x200 screen would use all 64k of memory. How much sense does that make in a mode where the machine only has 64k of memory?

You don't know even the basics: the C65 has 128kB of memory. NOT 64kB. Ignorant!
Quote:

Oh and that fancy BOING demo that 'only Amiga makes possible' LOL https://www.youtube.com/watch?v=W9QEeGqrZGY

Which is using the RSU, since it's incapable without it.

However, what is really nice to see is how doggy slow is it, especially compared with the original one:https://www.youtube.com/watch?v=mibhCb6t3HU

Wasn't a 2Mhz 65xx soooooo fast?

@Lou

Quote:

Lou wrote: My complaint has always been: too little, too late, too expensive.

The market's accepted asking price is dependent on the delivered gaming experience i.e. texture mapped 3D gaming from a gaming PC is different from budget-priced SNES's strong 2D gaming.

If the intended 68EC040 added price were delivered on top of A1200's price, it would have blown away the comparably priced Am386DX-40-based PC.

Commodore has access to low-cost 8 MB FP DRAM as shown by the original CD32's specifications.

In the end, Motorola couldn't convert 68000's success for 68040.

https://www.youtube.com/watch?v=CI3kXyz2OuY
Amiga's Flyin High texture mapped racing game with minimum 68030 CPU example i.e. 68040 class CPU or greater.

Last edited by Hammer on 15-Aug-2024 at 11:51 PM.
Last edited by Hammer on 15-Aug-2024 at 11:46 PM.
Last edited by Hammer on 15-Aug-2024 at 11:39 PM.
Last edited by Hammer on 15-Aug-2024 at 11:35 PM.
Last edited by Hammer on 15-Aug-2024 at 11:32 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

@matthey

Quote:

matthey wrote: Modern Vintage Gamer has a 3 month old video on the thread topic. Doom didn't kill the Amiga...Wolfenstein 3D did https://www.youtube.com/watch?v=wsADJa-23Sg It's just crazy that CBM released AGA without chunky support. Modern Vintage Gamer has ports of Out Run and Strife for the Amiga. An Amiga video can get 745,494 views in 3 months but Amiga peasants must eat expensive and very old PPC cake.

From Commodore - The Final Years
Quote:

Sydnes Canned After the Europeans rejected his A2200, Bill Sydnes’ position within Commodore became increasingly tenuous. Mehdi Ali had begun taking over product development decisions since February. Once the A600 hit the shelves and sales began bombing, it became increasingly clear to everyone that Sydnes had been a dud. “They should have just said, ‘Can it, thank you very much,’ and focus on the A1200,� says Gerard Bucas. “There were other factors in there but the bottom line is that the A600 should never have seen the light of day. They spent a fortune on it, built too much inventory, and eventually had no cash.� Commodore would now only concentrate on machines with the AA chipset going forward. The engineers were excited by this prospect, but also disappointed with how late AA was, with most feeling that it should have been out in 1990 in order to make a splash in the marketplace. Sydnes had wasted almost six months of development time with the ECS A2200 and now the engineers would have to race to catch up. The other big mistake that occurred under Sydnes was the overproduction of low-end PC clones, which resulted in the company having to write off inventory.

_________________
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 Once again you prove your ignorance. There is a sequential burst copy to the VDC ram of 255 bytes where a memory location can be written in sequence. The VDC has it's own internal 255 byte-copy function to move memory withing it's 64k. How do I know? I've written C128 software that I occasionally uploaded to BBS' back in the day. You continue to prove your ignorance. The C64 uses 1 BITPLANE for the pixels to show either a background or foreground color. The color is separated into 2 sets of 4 bits to set the foreground and background color for an 8x8 tile ... from the same palette of 16 colors for either. The pixel map simply displays 1 or the other. Color is defined as 1000 bytes for a 40x25 tiled-screen. 4 bits define the background and for foreground from all 16 (4bit) colors. That's why in 640x200 mode that PIXEL bit-plane uses 16k instead of 8K. 320x200/8 = 8000bytes of graphic memory. Doubling = 16000, you 16k... This is not an increase in 'bit'planes. It's 1 chunky-mapped as they get set 8 bits at a time. The rest of what you described for how the colors get set don't change anything and is exactly how I said it - a color LUT. This again is not Bit-plane graphics, but again you keep looking silly. I mean who knew that 4x4x4 bit RGB definitions for programmable color would generate 4096 colors...like OMG - who knew MATH? I mean who knew programmable color was defined by red, green and blue values? Wow you are soooooo smart! Changing how the color LUT works in different modes doesn't make this slow bit-planed graphics like the Amiga has. Having each pixel use 8bits for color would mean a 320x200 screen would use all 64k of memory. How much sense does that make in a mode where the machine only has 64k of memory? Oh and that fancy BOING demo that 'only Amiga makes possible' LOL https://www.youtube.com/watch?v=W9QEeGqrZGY

C65's 256 colors are done in 8 bitplane mode.

Commodore’s LSI group who rejected hi-res Denise's 8 colors with existing 4096 palette design would design the new graphics and microprocessor chips for C55 instead!


From Commodore - The Final Years,
Quote:

Commodore’s LSI group would now attempt to create new graphics and microprocessor chips in CMOS to complement the 4502. “Ted authorized work on the C65 chipset,� says Gardei. Although Ted Lenthe gave the project an official go ahead, it did not appear on any official project schedule yet. In fact, it would remain under wraps until it was more developed and Lenthe could build up support from management. Not even Gerard Bucas or Henri Rubin would be aware of it until later. For the first time in years, a new Commodore computer would emerge from the semiconductor group, rather than the system engineering group. (skip) on October 14, the C65 entered the official “Current Project List� at Commodore, along with the Amiga Game Machine. (skip) The new cross assembler would run on VAX and IBM PC computers and then upload the compiled code to the C65 prototype for execution. (skip) With testing of the complicated 4567 chip still ongoing, it was now clear to the team they would not be able to demonstrate the prototype to Rubin any time soon, nor display it at the upcoming CES show. By the end of 1988, Commodore was holding the line on game machines with its aging stalwarts, the A500 and C64. In addition, three new game machines were in development: C64G (in Germany), C65, and A250. (skip) It was a lot of activity for one small company, compared to Nintendo which focused itself on one game machine at a time. Were Commodore’s efforts spread too thin to result in even one video game product making it to the marketplace? (skip) And then it happened. Two weeks before CeBIT was set to commence, on February 20, 1989, Gardei finally received his long awaited 4510 and 4567 chips.

_________________
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

Wow, the VDC doesn't have direct access to it's own memory .... Wow you taught me something new!

I mean I can totally see the magical-fairy memory controller between the VDC and it's ram chips!

https://idoregesz.hu/wp-content/uploads/2019/09/idoregesz_c128_vdc_ram_01.jpg

I mean as if the wire layout on the board plainly visible going straight from the ram to the chip weren't evidence enough...I guess you have to be a special kind of rocket scientist to make trollish claims on the internet, provide no proof but demanding the other side prove everything your pathetic mind disagrees with...

Apparently the documentation calling it burst fill/copy wasn't enough of a clue ...but why look at that when you can just troll?

Yes the VDC is so slow that no action games exist for it...huh?
https://www.youtube.com/watch?v=SnNRyj7aChU
https://www.youtube.com/watch?v=ZaCQk4MKV54

You're still in denial of the Risen From Oblivion VDC demo. Poor little troll..

That's all the evidence I need to show what a pathetic troll you are.

Let me know when you get over the butt-hurt of a 2.47Mhz 6502-family cpu outperforming your precious 68000... On second thought - don't bother, you're a waste of my time.

Last edited by Lou on 17-Aug-2024 at 01:05 AM.