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

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

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

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

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

Who's Online
22 crawler(s) on-line.
 95 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 erik:  6 mins ago
 matthey:  32 mins ago
 zErec:  35 mins ago
 amigakit:  1 hr 1 min ago
 Hammer:  1 hr 35 mins ago
 agami:  1 hr 48 mins ago
 MagicSN:  2 hrs 29 mins ago
 Rob:  2 hrs 35 mins ago
 Karlos:  3 hrs 27 mins ago
 Yssing:  4 hrs 22 mins ago

/  Forum Index
   /  Classic Amiga Hardware
      /  DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 Next Page )
PosterThread
Hammer 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 26-Jul-2024 8:26:11
#281 ]
Elite Member
Joined: 9-Mar-2003
Posts: 6161
From: Australia

@bhabbott

Quote:

Gaming and creativity - most users weren't using Deluxe Paint to create game assets, they were painting with pixels.

DPaint wasn't Mac's Adobe Illustrator or Photoshop i.e. published marketing graphics. Mac's DTP strength has spread into published marketing graphics.

Our visual art class's A2000 fleet was replaced by 256 color Macs fleet i.e. A3000 didn't replace A2000.

Amiga has the video presentation niche, but it's a smaller small market.

Before the social media video revolution, DTP was the social media medium.

Quote:

I agree. Many Amiga fans don't though, and get upset when their precious Amiga is derided as being 'just a games machine' by snotty PC and Mac users.

In modern times, AMD and Intel are aiming for the next Xbox i.e. a gaming machine.

https://www.tomshardware.com/pc-components/cpus/sony-playstation-4-chip-helped-amd-avoid-bankruptcy-exec-recounts-how-jaguar-chips-fueled-companys-historic-turnaround
Quote:

Sony Playstation 4 chip helped AMD avoid bankruptcy — exec recounts how 'Jaguar' chips fueled company's historic turnaround

AMD’s Senior Director of Consumer and Gaming Client Business, Renato Fragale, recalls “helping AMD avoid bankruptcy” when he managed the team that developed the PlayStation 4 processor. The PS4 was launched by Sony in early 2013, and the success of the custom ‘Jaguar’ processor behind it (and in Microsoft’s Xbox One) was instrumental to AMD’s survival during a very difficult time for the company.



https://www.statista.com/forecasts/1463122/gaming-pcs-laptops-market-size-worldwide
"Gaming PC" hardware is big business i.e. $57.14 billon USD in 2023.


Quote:

I'm no expert on modern games, but this sounds wrong to me. You saying modern gaming PCs have console chips in them?

PC hardware with comparable hardware power as PS4 and PS5 usually has similar graphics quality results.

For the PC, low level Direct3D12 and Vulkan APIs helps to close the gap.


Last edited by Hammer on 26-Jul-2024 at 08:28 AM.

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

 Status: Offline
Profile     Report this post  
Lou 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 26-Jul-2024 12:29:14
#282 ]
Elite Member
Joined: 2-Nov-2004
Posts: 4229
From: Rhode Island

@cdimauro

Why do you deny reality? The IPC of the 6502 to the 68000 is all you need to look at.
If you want to start throwing in more 680X0 processors into the mix, it doesn't get much better.
For instance, the 8502 was never fully utilized. It wasn't a simple doubling of the clock speed. It's relocatable stack and zero-page mean memory access was much faster. Zero-Page means it can access that 256byte page faster more like registers...so 'lack of registers' isn't a problem. And this is real3D, not Wolfenstein fake 3D.
https://www.youtube.com/watch?v=1tDflgqJlTw

The QUICKEST instruction on 68000 was 2 clocks. The average was 8....EIGHT! That means for general purpose work they weren't that far off from a 2Mhz 6502 .... which is exactly why the PC Engine/TurboGrafx outperformed the SNES and Megedrive/Genesis in many cross-platform games. More sprites, less flicker, smoother animation. It was only extra chips that gave the SNES a 3D advantage and a gpu that gave the megagrive multiple scrolling backgrounds. This was solved with the SuperGrafx which added a 2nd gpu chip so you could render a separate background and foreground layer ... the CPU was never the problem.

The IPC of the 68K line was crap until the 68040 and when was that released? 1990 ...and at what cost? By then, the Motorola line was lagging. The 65CE02, in 1988, improved IPC another 25% over the 65C02. It was used in Amiga serial cards and for the C65. The 65CE02 could do 10Mhz out of the box in 1988 for a few dollars and was an 8/16 bit chip and had a 20bit address bus. Not as good as the 65816's 24bit but that doesn't matter much thanks to cheap MMU's like in the 128.
If CMOS had 1/8th the R&D budget of Motorola...well it doesn't matter ARM won.

Women play games on phones...
Consoles are PCs but the Switch and it's coming successor are ARM-based and has the most sales. There are ARM laptops out now. Mac's are now ARM.

Read the writing on the wall: ARM won.

 Status: Offline
Profile     Report this post  
Lou 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 26-Jul-2024 12:31:20
#283 ]
Elite Member
Joined: 2-Nov-2004
Posts: 4229
From: Rhode Island

The only thing that would have saved the CD32 would have been a built-in FMV module and an API for developers to be able to take advantage of the extra cpu and DSP.

Alas that was not to be.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 27-Jul-2024 5:19:22
#284 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4127
From: Germany

@Lou

Quote:

Lou wrote:
@cdimauro

Why do you deny reality?

Which reality? You're talking about ABSTRACT things which are very different from what you find in real code. See below.
Quote:
The IPC of the 6502 to the 68000 is all you need to look at.

First abstract concept: IPC. Which is even less meaningful compared to MIPS.

Why? Because it only measure how many instructions you can execute per cycle, as per its definition, but you don't know which TYPE of instructions are executed and HOW MANY of them are required to complete a task. IPC, alone, is PURE CRAP.
Quote:
If you want to start throwing in more 680X0 processors into the mix, it doesn't get much better.

I don't want, because it's not needed.
Quote:
For instance, the 8502 was never fully utilized. It wasn't a simple doubling of the clock speed.

You can't double clock it using the VIC-II, as you should already know.

Unless you want to use the high-res extra video chip (thanks Commodore engineers for reinventing the wheel instead of giving us a VIC-III!), which I doubt since it's severely crippled (e.g.: accessing its video ram is a PITA).
Quote:
It's relocatable stack and zero-page mean memory access was much faster.

They aren't much faster: the number of cycles for accessing the memory is exactly the same.
Quote:
Zero-Page means it can access that 256byte page faster more like registers...

See above: it's not faster. The speed is the same of the good, old 6502.

And registers can be accessed MUCH QUICKER than zero-page.
Quote:
so 'lack of registers' isn't a problem.

Absolutely no: you don't know of what you're talking about!

Zero-page can be used as a quicker temporary storage for data, but they can NOT replace registers. Quicker -> compared to the absolute addressing mode: you're saving a single clock cycles, if I recall it correctly.

Registers are completely different things. Try to emulate an ADC ($40),Y instruction, for example, by using the zero-page for replacing the accumulator and the Y register and show me the list of instructionS (plural!) to achieve the same.
Quote:
And this is real3D, not Wolfenstein fake 3D.
https://www.youtube.com/watch?v=1tDflgqJlTw

This is just a joke: have you ever seen Doom? I mean on a PC running at 320x200 in 256 colours. It's a LITTLE BIT different, right?.

Now, I can understand that you've problems having only 16 colours (well, not exactly, but you know what I mean) at 160x200, but you can port Doom as it is (and optimized as much as you want, even rewriting it in assembly. But it should work our EXACTLY as the original Doom) and just use the time demo to benchmark the system (so, without outputting the screen to video).

That would be way to show IF such systems are enough general-purpose.
Quote:
The QUICKEST instruction on 68000 was 2 clocks. The average was 8....EIGHT! That means for general purpose work they weren't that far off from a 2Mhz 6502 ....

Again, those are ABSTRACT numbers: nothing about real-world code.

What about decoding a small JPEG picture? The standard codec should be small enough to fit & work on a 6502 with 64kB of memory.

There's picoJPEG which is part of the Embench benchmark suite: https://github.com/embench/embench-iot/tree/master/src

Those are benchmarks selected for the embedded market and are small enough to be ported on 8-bit systems. It can be a good starting point for have more realistic comparisons instead of completely abstract concepts.
Quote:
which is exactly why the PC Engine/TurboGrafx outperformed the SNES and Megedrive/Genesis in many cross-platform games. More sprites, less flicker, smoother animation. It was only extra chips that gave the SNES a 3D advantage and a gpu that gave the megagrive multiple scrolling backgrounds. This was solved with the SuperGrafx which added a 2nd gpu chip so you could render a separate background and foreground layer ...

Now you're comparing completely different systems. It's a no-go.
Quote:
the CPU was never the problem.

For consoles? What a news: the CPUs were just slaves of the custom chips...
Quote:
The IPC of the 68K line was crap until the 68040 and when was that released? 1990 ...and at what cost? By then, the Motorola line was lagging.

Are you serious? Do you know that the 68020 was released on 1984 and got a HUGE performance boost? The 68030 a few years after added a small data cache which could give another boost if properly used, plus it introduced the burst mode.

You talk of things that you've no clue of...
Quote:
The 65CE02, in 1988, improved IPC another 25% over the 65C02. It was used in Amiga serial cards and for the C65.

See above: compare it to the 68020 or 68030.
Quote:
The 65CE02 could do 10Mhz out of the box in 1988 for a few dollars

10Mhz? Sources for this?
Quote:
and was an 8/16 bit chip and had a 20bit address bus. Not as good as the 65816's 24bit but that doesn't matter much thanks to cheap MMU's like in the 128.

LOL. Have you EVER programmed an 8-bit system like the 8502 with its MMU? It's a nightmare! You've to carefully write your code to reduce to the maximum the number of times to (re)program the MMU.

Even an 8088 is WAY better, because you can load a segment register each time that you want to accesa an ARBITRARY location in the 1MB address space.

This talking about general-purpose computing.
Quote:
If CMOS had 1/8th the R&D budget of Motorola...well it doesn't matter ARM won.

Doesn't matter: the 65xx CPUs line is NOT enough general-purpose. It was doomed to stay on niches.
Quote:
Women play games on phones...

?!?
Quote:
Consoles are PCs

Technically (hardware) they are very close, but they aren't PC = Personal COMPUTERS.
Quote:
but the Switch and it's coming successor are ARM-based and has the most sales. There are ARM laptops out now. Mac's are now ARM.

Read the writing on the wall: ARM won.

Again, knock my door when PCs have > 50% of the market. Actually, they are FAR AWAY.
Quote:
The only thing that would have saved the CD32 would have been a built-in FMV module and an API for developers to be able to take advantage of the extra cpu and DSP.

Alas that was not to be.

CD32 was already much more expensive than the good profitable 1200 and you want to add such expensive component? Then you really want to kill such console, eh!

 Status: Offline
Profile     Report this post  
cdimauro 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 27-Jul-2024 5:59:49
#285 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4127
From: Germany

@Hammer

Quote:

Hammer wrote:
Quote:

@cdimauro
The context was: consoles of the time (1990-1993).

Both Dr Ed Helper and Ken Kutaragi arrived at 1 million transistor budget for the game console's main compute, visual and audio components.

https://segaretro.org/History_of_the_Sega_Saturn/Development
For the Saturn project, Sega has considered 68030 CPU which could indicate the price range.

OK, but consider that 1993 is year were the CD32 was introduced. Now you're talking about next generation consoles (e.g. the "16-bit" Age was over).
Quote:
For 1993, 68EC030's and 68030's price ranges are known from DataQuest reports.

Actual BOM costs are behind NDA.

The 68EC030 was too much expensive for what it gives: the EC20 has a much better price / performance ratio.
Quote:
Quote:

@cdimauro
Yes, but the 1200 had 2MB of RAM and it was a good amount for such time & market.

I recall, A1200's 2MB Chip RAM has a $52 price range.

Which was A LOT, consider the entire BOM cost.
Quote:
During CD32's development, Psygnosis warned Mehdi Ali of the competition.

Quote:


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

CD32

As Commodore’s engineers designed the basic specifications of the CD324 – which appeared to be, for the first time ever, the subject of a well-planned and considered product launch – we managed, under strict non-disclosure agreements, to seed CD32 development
machines into most of the major games software development houses. They had begun writing games especially designed to utilise the full capabilities and features this 32-bit CD-based machine had to offer so that at the planned launch – scheduled to be in late
spring/early summer of 1994 – there would be a plethora of fantastic games launched at the same time.

As a result of this, I was asked by Ian Hetherington (cofounder, with Jonathan Ellis, of Psygnosis) to arrange a meeting with Mehdi Ali at their studios in Liverpool.

Mehdi was not very happy with the idea, but I ignored his moaning and drove him there.
Ian explained to Mehdi that with a few seemingly quite modest design changes, the CD32 could have an incredible boost in performance at very marginal additional cost.


He also pointed out the benefits it would give developers like Psygnosis and other major players in the industry, who would find it easier to produce even better-quality products and enhance the reputation of the CD32 and the games publishers – a genuine ‘win-win’. Ian
had not requested any financial reward for this – it seemed he simply wanted to offer considerably improved games performance and to be credited for his
contribution.

Well, it went exactly as expected. Mehdi was rude and ignorant, and clearly had no idea what Ian was talking about. But instead of just admitting that, he more or less turned on Ian, as though he ‘must be crazy telling us how to design our computers!’ I ushered Mehdi out of the
building feeling very ashamed, and it was quite a while before I plucked up the courage to talk to Ian again.

Luckily for me, Ian had realised what kind of a person Mehdi Ali was and held no bad feelings towards me.

The real sting to this story is that Psygnosis subsequently sold their company to Sony Computer Entertainment Europe, with Ian Hetherington being made head of Sony PlayStation Europe – and I often wonder to myself: ‘If Mehdi Ali had not been such an obnoxious prick, would Commodore have had that technology?’

Yeah, I know this story.

However, it's not reported which "quite modest design changes" could have had "an incredible boost in performance at very marginal additional cost".

I'm also reporting modest design changes on my new articles, so maybe they were similar. But it's difficult to judge without more clear information.
Quote:

@cdimauro

The CD32 deserved a bit more to address 3D games, but they came & exploded only when Doom was introduced. And without crystal balls, it wasn't possible to figure out this big market change.

Commodore is made aware of chunky pixel since 1990's Wing Commander which made an impact in COMMODORE - The Final Years by Brian Bagnall.

Yes, and that's why packed/chunky graphics is the minimum addition to the chipset which should have been introduced with the next AGA (it was too late / not that much required with ECS / 1990).
Quote:
Quote:

From COMMODORE - The Final Years by Brian Bagnall,

The Gail Problem

Jeff Porter had laid the groundwork for the C65 marketing push, including a plan to attract a large number of launch titles. “That’s marketing 101 on how to make the C65 successful,” he says. “Get the third party software developers on your side. And how do you do that? By getting the people who work for Commodore on your side to talk to the third party developers.”

Porter needed to attract some of the top C64 developers in the US over to the C65 platform. At the time there were many software houses who had made their name on the C64, including EA, Activision, Broderbund, Epyx, Origin, and Access Software. In the latter part of 1990, these companies started embracing the PC world as new video and sound cards made games more exciting. Games such as Wing Commander came out that turned the heads of video gamers.


Note why Wing Commander was selected as part of the game bundle for CD32.

That's OK: CD32 = 1993. The right time to have a PROPER packed/chunky implementation.
Quote:
C65's "mooooore colors" is a distraction.

Yes, but they did not moved all R&D resources there. According to Eggebrecht, at least.
Quote:
Doom wasn't the only chunky pixel game from the PC's 1992-1993.

OK, but and as I've already said, that should have been introduce with the AGA.

It was a big failure for Commodore engineers not having considered it. However, we know that they don't know how to properly evolve the platform (see also the next article of my series, which is coming in short time).
Quote:
The warning signs for gaming PC's rise was in 1990 and SNES has chunky pixel Mode 7 since 1990.

Sure, but it was the only console of the time having it. That was still the 2D gaming Age (e.g.: "16-bit" consoles).

With AGA, it should have been different.
Quote:
Gaming PC's flood of texture-mapped 3D game releases in 1994 would have been developed in the 1991 to 1993 time period.

See above.
Quote:
Communicating with major game developers would help.

Exactly. They (Commodore engineers) clearly had no clue on how to properly evolve the platform.
Quote:
If your viewpoint is based on retail release, it's too late. You haven't factored industrial espionage and industrial intelligence gathering.

Like many Amiga gamers, my 1st gaming PC was in Xmas Q4 1992. I have noticed Wing Commander since 1990.

And that's ok, we know that AGA should have added packed/chunky. Engineers were too much blind.

 Status: Offline
Profile     Report this post  
bhabbott 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 27-Jul-2024 6:28:17
#286 ]
Cult Member
Joined: 6-Jun-2018
Posts: 509
From: Aotearoa

@Hammer

Quote:

Hammer wrote:

DPaint wasn't Mac's Adobe Illustrator or Photoshop i.e. published marketing graphics. Mac's DTP strength has spread into published marketing graphics.

Marketing graphics, not painting. Business orientated, not personal creativity.

Quote:
Our visual art class's A2000 fleet was replaced by 256 color Macs fleet i.e. A3000 didn't replace A2000.

How wonderful for you that your school could afford a fleet of color Macs. Most homes couldn't even afford a single Mac, let alone the software to go with it.

Quote:
Before the social media video revolution, DTP was the social media medium.

No, it wasn't.

Quote:
In modern times, AMD and Intel are aiming for the next Xbox i.e. a gaming machine.

The Xbox is a gaming machine, not a personal computer.

Quote:
PC hardware with comparable hardware power as PS4 and PS5 usually has similar graphics quality results.

But it doesn't mean gaming PCs are built around console hardware.

 Status: Offline
Profile     Report this post  
bhabbott 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 27-Jul-2024 6:50:10
#287 ]
Cult Member
Joined: 6-Jun-2018
Posts: 509
From: Aotearoa

@Lou

Quote:

Lou wrote:
The only thing that would have saved the CD32 would have been a built-in FMV module and an API for developers to be able to take advantage of the extra cpu and DSP.

Alas that was not to be.

The FMV module was a mistake. It was designed for a use case that would not appear. And it was too expensive.

Developers didn't want to deal with a strange CPU and DSP chip.

What would have 'saved' the CD32 was Commodore being in better financial health. Then they would have produced more and we would have more to play with today.

 Status: Offline
Profile     Report this post  
Lou 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 27-Jul-2024 17:43:47
#288 ]
Elite Member
Joined: 2-Nov-2004
Posts: 4229
From: Rhode Island

@cdimauro

Quote:

cdimauro wrote:
@Lou

Quote:

Lou wrote:
@cdimauro

Why do you deny reality?

Which reality? You're talking about ABSTRACT things which are very different from what you find in real code. See below.
Quote:
The IPC of the 6502 to the 68000 is all you need to look at.

First abstract concept: IPC. Which is even less meaningful compared to MIPS.

Why? Because it only measure how many instructions you can execute per cycle, as per its definition, but you don't know which TYPE of instructions are executed and HOW MANY of them are required to complete a task. IPC, alone, is PURE CRAP.

That's ridiculous. IPC is what 'we' have gained by going multicore. It is infact the definitive measure of performance because all that has to happen to gain performance is to increase the clock speed. When Commodore moved to a new manufacturing process, they chose to lower the power usage to 1/20th rather than turning up the clockspeed. In 1988 they could have had a 40Mhz 65CE02.

Quote:

Quote:
If you want to start throwing in more 680X0 processors into the mix, it doesn't get much better.

I don't want, because it's not needed.
Quote:
For instance, the 8502 was never fully utilized. It wasn't a simple doubling of the clock speed.

You can't double clock it using the VIC-II, as you should already know.

Unless you want to use the high-res extra video chip (thanks Commodore engineers for reinventing the wheel instead of giving us a VIC-III!), which I doubt since it's severely crippled (e.g.: accessing its video ram is a PITA).

A VIC-III was developed for the C65 and had graphics capabilities above the A1000 ..
Quote:

Graphics in the C65 (also known as the C64DX) were to be provided by the VIC-III (designated the CSG 4567, and named as the "Bill" chip for designer Bill Gardei). Its features are:

Support of standard C64 video modes.
Textmode with 40/80 × 25 characters (featuring blink, bold, and underline).
True bitplane VGA-style graphics:
320x200x256
640x200x256
640x400x16
1280x200x16
1280x400x4
Palette of 4096 colours.
Special facility for address resolution (Display Address Translator [DAT]) of the C64 pixel coordinate system.
PAL only, no NTSC (but the RGB output works just fine with the 1084S).
Synchronizable with external video source (Genlock).
Integrated DMA-Controller (Bit blit).
Reportedly can display Amiga OCS IFF.

....but why are we dicussing machines as a whole when we are talking about cpus?

Quote:

Quote:
It's relocatable stack and zero-page mean memory access was much faster.

They aren't much faster: the number of cycles for accessing the memory is exactly the same.
Quote:
Zero-Page means it can access that 256byte page faster more like registers...

See above: it's not faster. The speed is the same of the good, old 6502.

And registers can be accessed MUCH QUICKER than zero-page.
Quote:
so 'lack of registers' isn't a problem.

Absolutely no: you don't know of what you're talking about!

Zero-page can be used as a quicker temporary storage for data, but they can NOT replace registers. Quicker -> compared to the absolute addressing mode: you're saving a single clock cycles, if I recall it correctly.

Registers are completely different things. Try to emulate an ADC ($40),Y instruction, for example, by using the zero-page for replacing the accumulator and the Y register and show me the list of instructionS (plural!) to achieve the same.

Well I suppose you'd feel that way if memory access took as many cycles as on a 68000 ... but as you've continued to fail to see the improvements Commodore made to the 65___ family over time, Zero-Page takes 1 cycles and regular access when down from 3 to 2.

Quote:

Quote:
And this is real3D, not Wolfenstein fake 3D.
https://www.youtube.com/watch?v=1tDflgqJlTw

This is just a joke: have you ever seen Doom? I mean on a PC running at 320x200 in 256 colours. It's a LITTLE BIT different, right?.

Now, I can understand that you've problems having only 16 colours (well, not exactly, but you know what I mean) at 160x200, but you can port Doom as it is (and optimized as much as you want, even rewriting it in assembly. But it should work our EXACTLY as the original Doom) and just use the time demo to benchmark the system (so, without outputting the screen to video).

That would be way to show IF such systems are enough general-purpose.

Again are we comparing systems/machines as a whole or cpus? The RAD-DOOM port looks amazing and plays smoothly considering the VIC-II...
Actually looks way better than any Amiga version I've seen. This is what more processing power can get you despite other visual limitations...
https://www.youtube.com/watch?v=5iAkO6WY9z8

Quote:

Quote:
The QUICKEST instruction on 68000 was 2 clocks. The average was 8....EIGHT! That means for general purpose work they weren't that far off from a 2Mhz 6502 ....

Again, those are ABSTRACT numbers: nothing about real-world code.

What about decoding a small JPEG picture? The standard codec should be small enough to fit & work on a 6502 with 64kB of memory.

There's picoJPEG which is part of the Embench benchmark suite: https://github.com/embench/embench-iot/tree/master/src

Those are benchmarks selected for the embedded market and are small enough to be ported on 8-bit systems. It can be a good starting point for have more realistic comparisons instead of completely abstract concepts.

I love your strawman arguments. Once again you are comparing a C64 to some unicorn machine.
As I said above, a 65CE02 could do 40+Mhz in 1988 but was marketed at 2-10Mhz. You can watch C65 videos on youtube where it easily displays classic Amiga images.
https://www.youtube.com/watch?v=kP46zIzbLpI
https://www.youtube.com/watch?v=_8uX1ZEUHAg
Amazing what a mere 3.57Mhz 65CE02 can do - isn't it?

Quote:

Quote:
which is exactly why the PC Engine/TurboGrafx outperformed the SNES and Megedrive/Genesis in many cross-platform games. More sprites, less flicker, smoother animation. It was only extra chips that gave the SNES a 3D advantage and a gpu that gave the megagrive multiple scrolling backgrounds. This was solved with the SuperGrafx which added a 2nd gpu chip so you could render a separate background and foreground layer ...

Now you're comparing completely different systems. It's a no-go.
Quote:
the CPU was never the problem.

For consoles? What a news: the CPUs were just slaves of the custom chips...
Quote:
The IPC of the 68K line was crap until the 68040 and when was that released? 1990 ...and at what cost? By then, the Motorola line was lagging.

Are you serious? Do you know that the 68020 was released on 1984 and got a HUGE performance boost? The 68030 a few years after added a small data cache which could give another boost if properly used, plus it introduced the burst mode.

You talk of things that you've no clue of...

Yes, I state the limitations of the systems. You don't understand that keeping track of objects/sprites is a cpu function not a gpu. Sure the gpu needs to draw them but the calculations of where and when are done on the cpu - which is why in many cross-platform games, the PCEngine always had more sprites and less flickering and slow-down.
The PCEngine is merely 65C02-based competing against an 8/16 and a 16/32 system. So again, was the cpu the problem?

Quote:

Quote:
The 65CE02, in 1988, improved IPC another 25% over the 65C02. It was used in Amiga serial cards and for the C65.

See above: compare it to the 68020 or 68030.
Quote:
The 65CE02 could do 10Mhz out of the box in 1988 for a few dollars

10Mhz? Sources for this?

Google must be hard...
https://en.wikipedia.org/wiki/CSG_65CE02
Once again, even the 65816 could do 10Mhz in 1983 and was pushed to 20Mhz in the CMD SuperCPU expansion ... do you need a source for this as well?

Quote:

Quote:
and was an 8/16 bit chip and had a 20bit address bus. Not as good as the 65816's 24bit but that doesn't matter much thanks to cheap MMU's like in the 128.

LOL. Have you EVER programmed an 8-bit system like the 8502 with its MMU? It's a nightmare! You've to carefully write your code to reduce to the maximum the number of times to (re)program the MMU.

Even an 8088 is WAY better, because you can load a segment register each time that you want to accesa an ARBITRARY location in the 1MB address space.

This talking about general-purpose computing.

I took 8088 assembly in college during my Computer Engineering years. I also taught myself 6502 assembly. Everything is a tradeoff. I do remember one 6502 instruction that required 2 8088 instructions but the exact one escapes me as I haven't looked at it in 30 years.
RISC has shown that executing simpler instructions in less cycles is better than having a large general purpose instruction set that takes many cycles to decode is not the better option. It increase cost and complexity. They throw more clockspeed at a pig ... which is why the 68000 was targeted for 8Mhz out of the gate. I don't know why you keep repeating that the 65__ line is not a general purpose cpu. For the record Hudson's version in the PCEngine included a MMU that allowed it to access 2MB of memory.

Quote:

Quote:
If CMOS had 1/8th the R&D budget of Motorola...well it doesn't matter ARM won.

Doesn't matter: the 65xx CPUs line is NOT enough general-purpose. It was doomed to stay on niches.

but at least it's still being produced today...
I guess they needed a lowly 65CE02 in 'fast' Amiga serials because handling that 68000 was 'below' the 68000 - huh? By the way, the Z-register was added to the 65CE02 now putting it on par with the Motorola 6809 (8/16 chip). The Z register was originally removed when developing 6800->6502 to lower cost and improve efficiency.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 27-Jul-2024 20:50:17
#289 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4127
From: Germany

@Lou

Quote:

Lou wrote:
@cdimauro

Quote:

cdimauro wrote:
@Lou

Which reality? You're talking about ABSTRACT things which are very different from what you find in real code. See below.
First abstract concept: IPC. Which is even less meaningful compared to MIPS.

Why? Because it only measure how many instructions you can execute per cycle, as per its definition, but you don't know which TYPE of instructions are executed and HOW MANY of them are required to complete a task. IPC, alone, is PURE CRAP.

That's ridiculous. IPC is what 'we' have gained by going multicore.

LOL. IPC doesn't stand for Instructions Per Core: it's Instructions per Cycle. Multicore has NOTHING to do with that.
Quote:
It is infact the definitive measure of performance because all that has to happen to gain performance is to increase the clock speed.

RI-LOL. So, now you also factor in the clock speed.

Since you want to measure the performance, then... why don't "just" (!) measure such performances instead of sticking to the IPC (and now to the clock speed)?

It's even simpler: performance = time taken to accomplish a task.
Quote:
When Commodore moved to a new manufacturing process, they chose to lower the power usage to 1/20th rather than turning up the clockspeed. In 1988 they could have had a 40Mhz 65CE02.

A single node advance can't give you such boost in frequencies: that's a dream.
Quote:
Quote:
You can't double clock it using the VIC-II, as you should already know.

Unless you want to use the high-res extra video chip (thanks Commodore engineers for reinventing the wheel instead of giving us a VIC-III!), which I doubt since it's severely crippled (e.g.: accessing its video ram is a PITA).

A VIC-III was developed for the C65 and had graphics capabilities above the A1000 ..

Weren't we discussing about the C128's 8502? You stated and it worked at 2Mhz, but that was NOT the case with the VIC-II.
Quote:
Quote:

Graphics in the C65 (also known as the C64DX) were to be provided by the VIC-III (designated the CSG 4567, and named as the "Bill" chip for designer Bill Gardei). Its features are:

Support of standard C64 video modes.
Textmode with 40/80 × 25 characters (featuring blink, bold, and underline).
True bitplane VGA-style graphics:
320x200x256
640x200x256
640x400x16
1280x200x16
1280x400x4
Palette of 4096 colours.
Special facility for address resolution (Display Address Translator [DAT]) of the C64 pixel coordinate system.
PAL only, no NTSC (but the RGB output works just fine with the 1084S).
Synchronizable with external video source (Genlock).
Integrated DMA-Controller (Bit blit).
Reportedly can display Amiga OCS IFF.

Irrelevant: see above.
Quote:
....but why are we dicussing machines as a whole when we are talking about cpus?

Yes, see above: it was the 8502 which was SUPPOSED to run at 2Mhz.
Quote:
Quote:

Absolutely no: you don't know of what you're talking about!

Zero-page can be used as a quicker temporary storage for data, but they can NOT replace registers. Quicker -> compared to the absolute addressing mode: you're saving a single clock cycles, if I recall it correctly.

Registers are completely different things. Try to emulate an ADC ($40),Y instruction, for example, by using the zero-page for replacing the accumulator and the Y register and show me the list of instructionS (plural!) to achieve the same.

Well I suppose you'd feel that way if memory access took as many cycles as on a 68000 ...

I don't, because... rolling drum... there were developed other processors from that glorious family.
Quote:
but as you've continued to fail to see the improvements Commodore made to the 65___ family over time, Zero-Page takes 1 cycles and regular access when down from 3 to 2.

Zero page takes the same time. You're confusing it with the improvements made with 1-byte instructions. From your (below) link:
https://en.wikipedia.org/wiki/CSG_65CE02#Pipeline_improvements

A major oddity of the original 6502 was that one-byte instructions like INX still took two cycles to complete. This allowed for simplifications in the pipeline system; the next byte from memory was fetched while the operation was being decoded, meaning the next byte was fetched no matter what. For most instructions, this byte would be part (or whole) of an operand, which could then be immediately fed into the now-decoded instruction.[2]

If the instruction required only one byte, the processor still read the following byte as it decoded the first. In this case the next byte was the following instruction, but it had no way to feed that back into the first stage of the pipeline to decode it. The fetched instruction was instead discarded and re-read to feed it into the decoder. This wastes a cycle. Although this led to a number of instructions being slower than they could have been, this "feature" was retained in the 65C02, although whether this was in order to retain its pipeline's simplicity or its cycle timing is not explained in available sources.[2]

Maintaining cycle compatibility was not a requirement for the 65CE02, and new fabrication processes made the extra circuitry in the pipeline a non-issue, so the pipeline was re-arranged to correctly handle one-byte instructions in a single cycle.[2] These improvements allow the 65CE02 to execute code up to 25% faster than previous 65xx models.[1]

A further improvement addresses an issue involving addressing instructions that add values to produce a final address. Examples include "indexed indirect" where the value in one of the index registers is added to a base address, and then applies the instruction to the resulting address. In the original 6502, if the addition of the two values crossed a page boundary, every 256 locations, an extra cycle was needed to produce the final address value. The 65CE02 removed this limitation, thereby improving the performance of these commonly used modes.[


No improvements on Zero-page instructions execution...
Quote:
Quote:

This is just a joke: have you ever seen Doom? I mean on a PC running at 320x200 in 256 colours. It's a LITTLE BIT different, right?.

Now, I can understand that you've problems having only 16 colours (well, not exactly, but you know what I mean) at 160x200, but you can port Doom as it is (and optimized as much as you want, even rewriting it in assembly. But it should work our EXACTLY as the original Doom) and just use the time demo to benchmark the system (so, without outputting the screen to video).

That would be way to show IF such systems are enough general-purpose.

Again are we comparing systems/machines as a whole or cpus?

CPUs, as I've already stated before:

just use the time demo to benchmark the system (so, without outputting the screen to video)

Time demo = CPU's number-crunching.
Quote:
The RAD-DOOM port looks amazing and plays smoothly considering the VIC-II...
Actually looks way better than any Amiga version I've seen. This is what more processing power can get you despite other visual limitations...
https://www.youtube.com/watch?v=5iAkO6WY9z8

STRA-LOL. From official page ( https://github.com/frntc/RAD-Doom ) of such project:

In this tech-demo the RAD replaces the MOS6510/8500/8502-CPU of your C64/C128 and natively runs DOOM on the ARM CPU.

Have you tried an Amiga 500 with PiStorm? I bet that it's A LITTLE BIT (!) better.
Quote:
Quote:
Again, those are ABSTRACT numbers: nothing about real-world code.

What about decoding a small JPEG picture? The standard codec should be small enough to fit & work on a 6502 with 64kB of memory.

There's picoJPEG which is part of the Embench benchmark suite: https://github.com/embench/embench-iot/tree/master/src

Those are benchmarks selected for the embedded market and are small enough to be ported on 8-bit systems. It can be a good starting point for have more realistic comparisons instead of completely abstract concepts.

I love your strawman arguments. Once again you are comparing a C64 to some unicorn machine.

MEGA-LOL. Here are YOUR words:

The QUICKEST instruction on 68000 was 2 clocks. The average was 8....EIGHT! That means for general purpose work they weren't that far off from a 2Mhz 6502 ....

YOU were comparing a 68000 with a 2Mhz 6502!
Quote:
As I said above, a 65CE02 could do 40+Mhz in 1988 but was marketed at 2-10Mhz.

ULTRA-LOL. Who was talking about unicorn machines?
Quote:
You can watch C65 videos on youtube where it easily displays classic Amiga images.
https://www.youtube.com/watch?v=kP46zIzbLpI
https://www.youtube.com/watch?v=_8uX1ZEUHAg
Amazing what a mere 3.57Mhz 65CE02 can do - isn't it?

Nothing amazing. Several Amiga 1000 demos were way better.
Quote:
Quote:
Are you serious? Do you know that the 68020 was released on 1984 and got a HUGE performance boost? The 68030 a few years after added a small data cache which could give another boost if properly used, plus it introduced the burst mode.

You talk of things that you've no clue of...

Yes, I state the limitations of the systems. You don't understand that keeping track of objects/sprites is a cpu function not a gpu.

And... from which of my writings have you "deducted" (!) that I haven't understood it?
Quote:
Sure the gpu needs to draw them but the calculations of where and when are done on the cpu - which is why in many cross-platform games, the PCEngine always had more sprites and less flickering and slow-down.
The PCEngine is merely 65C02-based competing against an 8/16 and a 16/32 system. So again, was the cpu the problem?

Again, you're comparing COMPLETE SYSTEMS which had DIFFERENT chipsets.

Do you understand that if you want to show that your beloved 65xx CPUs are better than others on doing some task then the only thing which should change on a system is the CPU?
Quote:
Quote:

See above: compare it to the 68020 or 68030.
10Mhz? Sources for this?

Google must be hard...
https://en.wikipedia.org/wiki/CSG_65CE02
Once again, even the 65816 could do 10Mhz in 1983 and was pushed to 20Mhz in the CMD SuperCPU expansion ... do you need a source for this as well?

No, but you need to search around for the 680x0 as well: faster processors were of this family were developed as well (up to 400Mhz with the last Coldfire).

There are even 68000 versions which run at much higher clock rates compared to the versions from Motorola:
https://www.analog.com/media/en/technical-documentation/data-sheets/fido1100.pdf
66-MHz operation

https://www.design-reuse.com/sip/synthesizable-68000-compatible-cpu-core-ip-1989/
The design goal for this version is operation at 80 to 100 Mhz in an Altera FPGA device.
Quote:
Quote:

LOL. Have you EVER programmed an 8-bit system like the 8502 with its MMU? It's a nightmare! You've to carefully write your code to reduce to the maximum the number of times to (re)program the MMU.

Even an 8088 is WAY better, because you can load a segment register each time that you want to accesa an ARBITRARY location in the 1MB address space.

This talking about general-purpose computing.

I took 8088 assembly in college during my Computer Engineering years. I also taught myself 6502 assembly. Everything is a tradeoff. I do remember one 6502 instruction that required 2 8088 instructions but the exact one escapes me as I haven't looked at it in 30 years.

Those should be the instructions with double-indirect memory access.

But the opposite is way more common: a 6502 required A LOT of instructions to emulate single 8088 instructions. I avoid MULs and DIVs to don't umiliate the 6502, but a REP MOVSB requires a SUBROUTINE to be written for such processor.
Quote:
RISC has shown that executing simpler instructions in less cycles is better than having a large general purpose instruction set that takes many cycles to decode is not the better option. It increase cost and complexity. They throw more clockspeed at a pig ...

RISC were a complete failure already a few years after that this concept was made widespread, because of those non-sense.

In fact, basically there's no CPU nowadays that can be classified as RISC. At most you can talk about L/S (Load/Store) architectures, but RISC, as concept, doesn't apply since 40 decades.
Quote:
which is why the 68000 was targeted for 8Mhz out of the gate.

That's only because Motorola hasn't developed faster versions.

AFAIK 68000s from some second-source supplier reached much higher frequencies. On Minimig it reached 56Mhz, AFAIR.
Quote:
I don't know why you keep repeating that the 65__ line is not a general purpose cpu.

Because... that's the case. Do you've a modern web browser on any 65xx system, for example?
Quote:
For the record Hudson's version in the PCEngine included a MMU that allowed it to access 2MB of memory.

Well, HOW it worked is the most important thing to see how much general is it. Here is it:
https://en.wikipedia.org/wiki/Hudson_Soft_HuC6280#Memory_mapping

The HuC6280 has a 64 KB logical address space, but a 2 MB physical address space. The HuC6280 uses a Memory Management Unit that splits the memory space into segments of 8 KB. Each logical 8 KB segment is associated with one of 256 physical 8 KB sized segments. This can be set up with an 8-bit register (MPR0-7) that contains the most significant eight bits of the address of the 8 KB segment in physical memory. Thus the logical 64 KB address space can be overlapping, continuous or scattered in physical address space, depending on the eight MPR registers.

Two special instructions are used to access these registers:

TAMi - transfer the content of the accumulator (A) into an MPR register (0-7).

TMAi - transfer an MPR register into the accumulator.


Now I give a simple homework. Imagine to implement a linked list where each node can be located at ANY address of such 2MB of memory space and contains a pointer to a string of arbitrary lenght (up to 2MB in size).
Could you please show me a program which traverses such list and givers back how many nodes have string which contains at least a "$" character.

After that, I can show you how a plain 68000 from year 1979 could do the same. And WAY better, of course.
Quote:
Quote:

Doesn't matter: the 65xx CPUs line is NOT enough general-purpose. It was doomed to stay on niches.

but at least it's still being produced today...

It doesn't matter: it's the same for many processors introduced on 70s.
Quote:
I guess they needed a lowly 65CE02 in 'fast' Amiga serials because handling that 68000 was 'below' the 68000 - huh?

Maybe because it was much cheaper? It was developed & produced in-house...
Quote:
By the way, the Z-register was added to the 65CE02 now putting it on par with the Motorola 6809 (8/16 chip). The Z register was originally removed when developing 6800->6502 to lower cost and improve efficiency.

OK, but... it still doesn't change the situation of such processor: its usage isn't enough general-purpose.

You can do many things, yes, but definitely it's not adeguate for many many other things.

 Status: Offline
Profile     Report this post  
matthey 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 28-Jul-2024 1:44:53
#290 ]
Elite Member
Joined: 14-Mar-2007
Posts: 2451
From: Kansas

Lou Quote:

I took 8088 assembly in college during my Computer Engineering years. I also taught myself 6502 assembly. Everything is a tradeoff. I do remember one 6502 instruction that required 2 8088 instructions but the exact one escapes me as I haven't looked at it in 30 years.
RISC has shown that executing simpler instructions in less cycles is better than having a large general purpose instruction set that takes many cycles to decode is not the better option. It increase cost and complexity. They throw more clockspeed at a pig ... which is why the 68000 was targeted for 8Mhz out of the gate. I don't know why you keep repeating that the 65__ line is not a general purpose cpu. For the record Hudson's version in the PCEngine included a MMU that allowed it to access 2MB of memory.


Please stop your history revisionism. If the 68000 was so bad, how bad was the 808x/x86 line that didn't catch up to the performance of the 68000 until the 80386? The 68000 was still outperforming the 8086, 80186 and 80286 in 1985 where it beat them all in 7 different benchmarks. See Micro Cornucopia, Number 24, June-July 1985 page 83 at the link below for the embarrassing benchmark results for x86.

http://bitsavers.trailing-edge.com/magazines/Micro_Cornucopia/Micro_Cornucopia_%2324_Jun85.pdf Quote:

Benchmarking The 68000 and 80X86
By Luis Bast

What's the fastest 16-bit chip around? It depends on whom you're listening to.

Intel has published reports comparing the speeds of its 80*86 family and Motorola's 68000. Their reports claim the iAPX286 is three to six times faster than the 8086 and three times faster than the 68000. Motorola decided to study Intel's benchmark results, and they found some inconsistencies in Intel's comparisons.

Here's food for thought:

1. Intel used the fastest iAPX286 they make (8MHz), but not the 12.5MHz Motorola 68000.

2. Intel used a record area of 64K for the linked list benchmark (which is the maximum memory all 80*86 chips can address without segment switching) and used a 16 Megabyte area for the 68000.

3. None of Intel's benchmarks handled the case of crossing a segment boundary. Obviously, many applications require more than 64K RAM. Crossing a segment boundary means more overhead (slower operation) for Intel's parts.

Intel Vrs. EDN Benchmarks

EDN published a list of benchmarks which the major chip manufacturers can use to compare parts. Figure 1 gives the results used in the Motorola report, using the fast chips.

From these results one concludes that the 286 can't be three to six times faster than the 8086. In fact, the 8086 beats the iAPX286 in the I/O Interrupts benchmark and finishes close behind in three others. In all cases, the 12.5MHz 68000 was faster than the iAPX286.

It's worth noting that the iAPX186 is slower than the 8086 in five of the seven benchmarks. Even if you extrapolate the iAPX186 to 10MHz, it's not much better than the older 8086. (What about the 8088? It's in their benchmark report for the Z80.)

EDN asked Intel to send in the code for their benchmarks, but Intel refused. Motorola interpreted Intel's refusal to mean that the code for the iAPX286 was so long and clumsy Intel would be embarrassed to see it in print.

Why The Discrepancy?

One explanation might be the segmented architecture of the 80*86 family. The maximum memory address in that case is 64K. Since the iAPX286 has an onboard MMU (memory management unit), the MMU takes over and updates the segment registers when the software addresses an out-of-boundary location. This creates a significant overhead when compilers operate on large data areas.

The 68000 can address anywhere in its 16 Megabyte address space without any overhead. Even when an external MMU was added to the system, the 68000 ran faster than the 80286 in five ot the seven benchmarks.

Benchmarks are, well, they're benchmarks, and obviously they're only one consideration for designers. But they're food for thought.

Editor's note: Of course, there's more to a microprocessor's success than benchmarks. The Intel-Motorola battle illustrates how marketing moxy can outweigh performance in the battle for industry's pocketbooks. In 1981, when the Motorola 68000 was gaining momentum, Intel president Andy Grove called in Regis McKenna, a public relations hotshot from Palo Alto, California.

Grove, McKenna, and six Intel managers met to develop a new marketing strategy for Intel. Their project was codenamed CRUSH. Very simply, its intention was to stop the movement of designers from the Intel chips to the newer 68000 series.

After surveying the market, they concluded that if customers compared the 8086 to the 68000, chip to chip, "Intel would have trouble." The 68000 was becoming more and more popular among software-oriented companies, while the 8086 was holding its own among hardware-oriented companies. (See "The Last Page" this issue for details.)

The CRUSH strategy was to play on customers' fears. They wanted people to worry about the consequences of committing themselves to Motorola. After all, the 68000 had very little software, no peripheral chips, and no development system. And Motorola hadn't clearly defined its future. Would customers get stuck with an orphan if they went 68000?

During the next quarter, Intel gave 50 half-day seminars to potential customers, and thereby won the positioning battle. Motorola is only now beginning to catch up in the home computer market, with new machines coming from Amiga, Atari, and Apple.



The 68000 was high performance in 1979 despite being a microcoded CPU. By 1985, it still had above average performance and the large flat address space with reduced price by then made it a bargain. It was as disruptive as Chuck Peddle's legendary $25 6502. The 6502 created the MPU PC and gaming/console markets. The 68000 created the MPU 16/32 bit embedded and workstation markets. Neither MPU achieved this with performance alone although good performance increased the value of both. They both achieved good performance with different philosophies that evolved over time. The 6502 performance came from some pipelining and maximizing the performance of memory. The pipelining was continued but changing the CPU to maximize memory performance did not. ARM and many RISC CPUs tried this too but it increased the cost of memory which is likely one of the contributing reasons why the Acorn Archimedes failed. The 68k Amiga was cheaper and one of the reasons was that it had good performance while using cheap memory, less memory, less memory bandwidth and smaller ROMs. The first ARM CPUs did not have caches but the 68k saved caches too when they were introduced. RISC was an improvement over accumulator architectures for performance metrics but overall, CISC continued to have the best performance metrics, especially good CISC ISAs like the 68k. A simpler ISA may allow higher CPU clock speeds but some of the gain is lost due to heat and the CPU waiting on slow memory. The answer is increased caches for the slow memory problem but this gives the performance advantage to good code density CISC like the 68k again.

 Status: Offline
Profile     Report this post  
Lou 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 28-Jul-2024 15:15:47
#291 ]
Elite Member
Joined: 2-Nov-2004
Posts: 4229
From: Rhode Island

@cdimauro

Everything you said is pretty much a bunch of bull.

Here you can see how relocating zero-page and stack on a C128 lets you cpu-copy 256 bytes in 3072 cycles vs 4096.
https://www.youtube.com/watch?v=u-ae8ZFZwaI

Adding an REU to a C64/128 let's you copy 4x faster because it essentially adds a 'blitter' to the C64/128 making what was thought impossible possible.
https://www.youtube.com/watch?v=wBefKdEDRpc

@matthey,
If the Amiga was Commodore's from the start, they probably would have used a 65816 and developed that further. 68000 was great in 1982 but it killed affordability -> mass-market appeal.
It didn't get affordable until the Genesis/Megadrive was released in 1988. By then it was already too slow @8Mhz for PCs as has been discussed.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 28-Jul-2024 15:27:50
#292 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4127
From: Germany

@Lou

Quote:

Lou wrote:
@cdimauro

Everything you said is pretty much a bunch of bull.

Sure. I trust only because you said it, without the need to prove it.
Quote:
Here you can see how relocating zero-page and stack on a C128 lets you cpu-copy 256 bytes in 3072 cycles vs 4096.
https://www.youtube.com/watch?v=u-ae8ZFZwaI

Which does NOT mean that zero page is faster (compared to the 6502/10).
Quote:
Adding an REU to a C64/128 let's you copy 4x faster because it essentially adds a 'blitter' to the C64/128 making what was thought impossible possible.
https://www.youtube.com/watch?v=wBefKdEDRpc

This is NOT part of the processor: you're adding an EXTERNAL component.

It's like the above project: it runs so fast because... it runs on an ARM processor. Which means: your beloved 65xx CANNOT run it.
Quote:
@matthey,
If the Amiga was Commodore's from the start, they probably would have used a 65816 and developed that further. 68000 was great in 1982 but it killed affordability -> mass-market appeal.
It didn't get affordable until the Genesis/Megadrive was released in 1988. By then it was already too slow @8Mhz for PCs as has been discussed.

You're rewriting the history here: the 68000 was an AWESOME processor LOVED by MILLIONS of people.

 Status: Offline
Profile     Report this post  
matthey 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 28-Jul-2024 16:54:59
#293 ]
Elite Member
Joined: 14-Mar-2007
Posts: 2451
From: Kansas

Lou Quote:

If the Amiga was Commodore's from the start, they probably would have used a 65816 and developed that further. 68000 was great in 1982 but it killed affordability -> mass-market appeal.
It didn't get affordable until the Genesis/Megadrive was released in 1988. By then it was already too slow @8Mhz for PCs as has been discussed.


You are doing the same as Intel by ignoring higher clocked 68000 chips by the time the Sega Genesis was released in 1988. Production of the low power HCMOS MC68HC000 started in 1986 with 8MHz, 10MHz, 12MHz, 16MHz and 20MHz rated chips produced with this process. Sega may have used the Hitachi and/or Toshiba produced 68000 chips which offered more options. A 68000@14MHz was possible for the Genesis and a possible upgrade for the Amiga but low cost is often prioritized for low end hardware. The eventual 68EC020@14MHz for the Amiga low end base was a much better upgrade due to a 256B instruction cache, 3-stage pipelining, barrel shifter and upgraded ISA with better performance and code density.

CBM chose the 16-bit Z8000 for their C900 workstation before it was cancelled due to the Amiga.

https://vintagecomputer.ca/commodore-900/

The Z8000 has 16 general purpose registers and separate user and stack pointers for better OS support but still has a segmented address space. The 68000 was a better choice.

https://en.wikipedia.org/wiki/Zilog_Z8000 Quote:

Although it saw some use in the early 1980s, it was never as popular as the Z80. It was released after the 16-bit Intel 8086 (April 1978) and the same time as the less-expensive Intel 8088, and only months before the Motorola 68000 (September 1979), which had a 32-bit instruction set architecture and was roughly twice as fast.

...

However, Faggin did concede that the segmented architecture of the Z8000 was a disadvantage for emerging "graphics-based applications", where systems such as the Apple Macintosh needed to readily access more than 64 KB of memory in a single address space. The longer than anticipated process of bringing the product to market was also acknowledged as having contributed to its lack of adoption, Faggin noting that "being first and having the strongest marketing and the strongest momentum", as Intel had found itself with the 8086, would have been the only remaining route to success for a product of this kind.

An examination of the choices available to designers in the early 1980s suggests there are several prosaic reasons the Z8000 was not more popular:

Comparing assembly language versions of the Byte Sieve, one sees that the 5.5 MHz Z8000's 1.1 seconds is impressive when compared to the 8-bit designs it replaced, including Zilog's 4 MHz Z80 at 6.8 seconds, and the popular 1 MHz MOS 6502 at 13.9. Even the newer 1 MHz Motorola 6809 was much slower, at 5.1 seconds. It also fares well against the 8 MHz Intel 8086 which turned in a time of 1.9 seconds, or the less expensive 5 MHz Intel 8088 at 4 seconds.

While the Intel processors were easily outperformed by the Z8001, they were packaged in 40-pin DIPs, which made them less expensive to implement than the 48-pin Z8001. The Z8002 also used a 40-pin package, but had a 16-bit address bus that could only access 64 KB of RAM, whereas the Intel processors had a 20-bit bus that could access 1 MB of RAM. Internally, the 23-bit addresses of the Z8000 were also more complex to process than Intel's simpler system using 16-bit base addresses and separate segment registers. For those looking for a low-cost option able to access (what was then) large amounts of memory, the Intel designs were competitive and available over a year earlier.

For those looking for pure performance, the Z8000 was the fastest CPU available in early 1979. But this was true only for a period of a few months. The 16/32-bit 8 MHz Motorola 68000 came to market later the same year and turns in a time of 0.49 seconds on the same Sieve test, over twice as fast as the Z8000. Although it used an even larger 64-pin DIP layout, for those willing to move to more than 40 pins this was a small price to pay for what was by far the fastest processor of its era. Its 32-bit instructions and registers, combined with a 24-bit address bus with flat 16 MB addressing, also made it much more attractive to designers, something Faggin admits to.


Even the Z8000 was more advanced than the 65816 but the 68000 provided the best OS support and good performance (NS32k was nice too but had bugs). The 65816 was useful to retain 6502 software compatibility while providing upgrades. It was not a good choice for a new advanced system like the Amiga. The 68000 was likely the best choice for the Amiga. Jay Miner never regretted pushing so hard for it but instead gave speeches about persevering to get it and the advantages it gave the Amiga. Even emulated, many of the 68k Amiga advantages remain that allow it to be surprisingly modern for an architecture introduced in 1979. Of course it is nowhere near competitive using old silicon, simulation or emulation but that could change as the performance metrics and code density are competitive today.

Last edited by matthey on 29-Jul-2024 at 05:52 AM.

 Status: Offline
Profile     Report this post  
bhabbott 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 29-Jul-2024 4:56:13
#294 ]
Cult Member
Joined: 6-Jun-2018
Posts: 509
From: Aotearoa

@Lou

Quote:

Lou wrote:

The QUICKEST instruction on 68000 was 2 clocks. The average was 8....EIGHT! That means for general purpose work they weren't that far off from a 2Mhz 6502 ....

That's not right - the minimum on 68000 is 4 clock cycles, which is one memory cycle. This means the memory cycle time of an 8 MHz 68000 and 2 MHz 6502 is the same, so you might assume the performance would be similar.

But this only applies to 8 bit operations. On an 8-bit machine the 6502 would actually be faster than a 68000. But the Amiga isn't 8-bit. Furthermore it has a 16-bit blitter to do the 'heavy lifting' on graphics operations, freeing the CPU for other stuff like math and logic. Here again the 6502 might match it if you limit everything to 8 bits, but when you exceed that the 68000 becomes much faster.

But the biggest advantage of the 68000 for developers is that it is easier to program. To get the best out of the 6502 you have to apply sneaky tricks like breaking operations up into 8 bit chunks and using self-modifying code. On the 68000 you just code it in the obvious way and get on with the job. Or if you don't like asm (even though 68k asm is a joy compared to other micros) you can use C without suffering the massive performance hit it has on 8-bit CPUs. Add in megabytes of memory and a multitasking environment and the 68000 streaks ahead.

Quote:
which is exactly why the PC Engine/TurboGrafx outperformed the SNES and Megedrive/Genesis in many cross-platform games. More sprites, less flicker, smoother animation.

This is more about console hardware than the CPU, not of much relevance to us.

Quote:
The IPC of the 68K line was crap until the 68040 and when was that released?

Nonsense, there was nothing wrong with it.

Quote:
The 65CE02, in 1988, improved IPC another 25% over the 65C02. It was used in Amiga serial cards and for the C65. The 65CE02 could do 10Mhz out of the box in 1988 for a few dollars and was an 8/16 bit chip and had a 20bit address bus.

Still an 8-bit CPU, with all that implies. 10MHz is no good when the memory can't keep up. You need RAM with cycle time significantly less than 100ns. In 1988 the fastest regular DRAM had a cycle time of 180ns, which might be good for 5 MHz if you're lucky. If you want to interleave CPU and video DMA etc. it gets worse - now you're limited to ~2.5MHz.

In 1988 there was a serious DRAM shortage. A machine that worked with slower RAM could be made much cheaper. This affected computers more than consoles because they needed a lot more RAM. Commodore managed to secure a large amount of cheap DRAM just before the shortage, while Atari didn't. This was the proximate reason for the Amiga pulling ahead of the ST at that time, as Atari had to raise their prices.

Quote:
If CMOS had 1/8th the R&D budget of Motorola...well it doesn't matter ARM won.

Nonsense. ARM didn't win, the PC clone industry won. Which meant Intel and AMD won. ARM was invisible in PCs, and didn't become big in the embedded world until much later.

Quote:
Women play games on phones...

And Microsoft (Windows) Solitaire is the most popular game of all time (also the game I have played most on the PC).

Quote:
Consoles are PCs

No, they aren't.

Quote:
but the Switch and it's coming successor are ARM-based

Never seen one, don't want one. And I don't know anyone else who has or wants one either.

Gaming is dead. I have a PS2 with lots of good games. Haven't turned it on in years. A few weeks ago someone gave me an Xbox. Tried the 2 games that came with it (including Halo) got bored and threw it in the corner. Maybe I will put it up on TradeMe for $50, or perhaps I will just rip out the hard drive and throw the rest away!

 Status: Offline
Profile     Report this post  
Lou 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 30-Jul-2024 21:17:10
#295 ]
Elite Member
Joined: 2-Nov-2004
Posts: 4229
From: Rhode Island

@cdimauro

Quote:

cdimauro wrote:
@Lou

Quote:

Lou wrote:
@cdimauro

Everything you said is pretty much a bunch of bull.

Sure. I trust only because you said it, without the need to prove it.
Quote:
Here you can see how relocating zero-page and stack on a C128 lets you cpu-copy 256 bytes in 3072 cycles vs 4096.
https://www.youtube.com/watch?v=u-ae8ZFZwaI

Which does NOT mean that zero page is faster (compared to the 6502/10).

Spoken like someone who makes stuff up and didn't watch the video.
The 8502 had 65C02 features without being labelled a 65C02...otherwise it could just be a 6510. Oh that's right you do 0 research.

Quote:

Quote:
Adding an REU to a C64/128 let's you copy 4x faster because it essentially adds a 'blitter' to the C64/128 making what was thought impossible possible.
https://www.youtube.com/watch?v=wBefKdEDRpc

This is NOT part of the processor: you're adding an EXTERNAL component.

You complain about graphics and DOOM ports before but now you want to whine when proven wrong... ALL 8bit chips come with some sort of MMU to access more than their 16bit addressable memory. What's the problem here? Modern chips have gone the SOC route...you know...like ARM... Back then they weren't in one 'package'. Take the blitter away from Amiga and what do you have? Nothing special. But adding a blitter to an older platform just isn't fair eh?

Quote:
It's like the above project: it runs so fast because... it runs on an ARM processor. Which means: your beloved 65xx CANNOT run it.

You're probably the same guy that upgraded to a PPC accelerator and now runs a PiStorm. The hypocrisy is real with this one.
The point is the 'port' is using STOCK VIC-II graphics and it looks amazing. It could perhaps have been ported to SuperCpu or even the Mega65's 40Mhz 65CE02 but it was on that hardware. Go cry and play Shogo on your PPC accelerator + Cybervision card.

Quote:

Quote:
@matthey,
If the Amiga was Commodore's from the start, they probably would have used a 65816 and developed that further. 68000 was great in 1982 but it killed affordability -> mass-market appeal.
It didn't get affordable until the Genesis/Megadrive was released in 1988. By then it was already too slow @8Mhz for PCs as has been discussed.

You're rewriting the history here: the 68000 was an AWESOME processor LOVED by MILLIONS of people.

6502 is love more by an order of magnitude or two.
A what-if scenario isn't a rewrite.

There's nothing special about a 68000 other than it was in your cherished machine. It was slutted around to other platforms and like those other platforms, what made it special was it's custom chips that defined the platform. As reality has shown, an 8bit PCEngine with a 16bit gpu did the job just as well...or even a 8/16 chip like in the SNES.
In fact the SNES is a shining example of how 'custom chips' is what defines a platform.
Sega couldn't keep up until it added the 'Virtua' chip in it's cartridges but it was too late and too expensive to keep up with the SuperFx chip. So was internal cpu what mattered?

So now I will bring it all back around:

What could have saved the CD32 was a built-in MIPS+DSP available to all developers...not just FMV cart owners...and perhas more than the 512k the FMV cart offered.
Too little, too late and too expensive.

 Status: Offline
Profile     Report this post  
bhabbott 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 30-Jul-2024 23:29:38
#296 ]
Cult Member
Joined: 6-Jun-2018
Posts: 509
From: Aotearoa

@Lou

Quote:

Lou wrote:

There's nothing special about a 68000 other than it was in your cherished machine.

Compared to the 6502? You must be joking.

Quote:
It was slutted around to other platforms

You mean the 6502 was 'slutted around', right?

Very few home computers used the 68000, and even fewer consoles.

Quote:
and like those other platforms, what made it special was it's custom chips that defined the platform.

Not just the 'custom' chips - the CPU also plays a role. 8-bit CPUs were fine when you had less than 64k RAM, but once you went beyond that they were a pain. The 68000 with its flat 16MB addressing range didn't have that problem. When combined with hardware that wasn't restricted to fixed memory locations it made life a lot easier for the programmer.

Quote:
As reality has shown, an 8bit PCEngine with a 16bit gpu did the job just as well...or even a 8/16 chip like in the SNES.

The reality was that consoles were very different from home computers.

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!

Quote:
In fact the SNES is a shining example of how 'custom chips' is what defines a platform.

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

Quote:
So now I will bring it all back around:

What could have saved the CD32 was a built-in MIPS+DSP available to all developers...not just FMV cart owners...and perhas more than the 512k the FMV cart offered.
Too little, too late and too expensive.

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.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 31-Jul-2024 4:36:14
#297 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4127
From: Germany

@Lou

Quote:

Lou wrote:
@cdimauro

Quote:

cdimauro wrote:
@Lou

Sure. I trust only because you said it, without the need to prove it.
Which does NOT mean that zero page is faster (compared to the 6502/10).

Spoken like someone who makes stuff up and didn't watch the video.

How did you realized that I haven't watched the video. You're clearly raving (as usual, in your case).
Quote:
The 8502 had 65C02 features without being labelled a 65C02...otherwise it could just be a 6510. Oh that's right you do 0 research.

What's no clear to you that I owned a C128? And that I've tinkered (A LOT) with it?

Of course I knew it. But the point here is that zero page is NOT faster on the 8502 neither on the 65EC02: that was the discussion about. Have you forget it? I haven't.

So, it's evident now that you do NOT read what people are writing neither you recall what was the discussion about...
Quote:
Quote:
This is NOT part of the processor: you're adding an EXTERNAL component.

You complain about graphics and DOOM ports before but now you want to whine when proven wrong... ALL 8bit chips come with some sort of MMU to access more than their 16bit addressable memory. What's the problem here?

That the RSU has an EXTERNAL chip which is NOT part of the MMU embedded on such processors.
Quote:
Modern chips have gone the SOC route...you know...like ARM... Back then they weren't in one 'package'. Take the blitter away from Amiga and what do you have? Nothing special. But adding a blitter to an older platform just isn't fair eh?

Now you're talking about COMPLETE SYSTEMS whereas the discussion was on the PROCESSORS (ALONE!).

You don't know which excuses to bring to exit from this discussion, and you're continuously changing the topic. Poor guy...
Quote:
Quote:
It's like the above project: it runs so fast because... it runs on an ARM processor. Which means: your beloved 65xx CANNOT run it.

You're probably the same guy that upgraded to a PPC accelerator and now runs a PiStorm. The hypocrisy is real with this one.

See as at the topic: you're INVENTING things on my side, only because you've a keyboard and you don't know how to continue this discussion, since you're clearly lost.

NO, I NEVER used any of such thing. Shocking, eh? Now you can go crying because you cannot invent anything else...
Quote:
The point is the 'port' is using STOCK VIC-II graphics and it looks amazing.

This is NOT a port, in fact.
Quote:
It could perhaps have been ported to SuperCpu or even the Mega65's 40Mhz 65CE02 but it was on that hardware.

THAT was the point of the discussion AND my request: was the discussion about how beautiful is the 65xx family? SHOW IT TO ME!
Quote:
Go cry and play Shogo on your PPC accelerator + Cybervision card.

Same as above: NEVER had neither used them!

You're an hopeless desperate...
Quote:
Quote:
You're rewriting the history here: the 68000 was an AWESOME processor LOVED by MILLIONS of people.

6502 is love more by an order of magnitude or two.
A what-if scenario isn't a rewrite.

There's no what-if here: the 68000 was loved because it opened the doors of the MODERN computing, with its beautiful architecture. Do you understand that even nowadays we have... 32 bit systems? Where are the 32-bit 65xx systems?
Quote:
There's nothing special about a 68000 other than it was in your cherished machine. It was slutted around to other platforms and like those other platforms, what made it special was it's custom chips that defined the platform.

Nothing special? Well, I've given you a very simple homework to show how a 65xx can do general purpose computing with a trivial (but realistic scenario on computing) exercise, and I'm still waiting your work.

As I've said, I can provide a 68000 version AFTER that, to show how a 68000 from 1979 can do the work like any MODERN processor.
Quote:
As reality has shown, an 8bit PCEngine with a 16bit gpu did the job just as well...or even a 8/16 chip like in the SNES.
In fact the SNES is a shining example of how 'custom chips' is what defines a platform.
Sega couldn't keep up until it added the 'Virtua' chip in it's cartridges but it was too late and too expensive to keep up with the SuperFx chip. So was internal cpu what mattered?

Again, you've switched the discussion to COMPLETE SYSTEMS.

When do you think to show how so beautiful are 65xx processors on GENERAL PURPOSE COMPUTING?
Quote:
So now I will bring it all back around:

What could have saved the CD32 was a built-in MIPS+DSP available to all developers...not just FMV cart owners...and perhas more than the 512k the FMV cart offered.
Too little, too late and too expensive.

CD32 was already expensive and you want to make it even more, so that it failed much more.

You're living on a dream world...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 31-Jul-2024 4:37:33
#298 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4127
From: Germany

@bhabbott

Quote:

bhabbott wrote:

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

That's pure crap baked with big lies.
Quote:
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!

How much costed the games on floppies?

 Status: Offline
Profile     Report this post  
Lou 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 8-Aug-2024 18:43:37
#299 ]
Elite Member
Joined: 2-Nov-2004
Posts: 4229
From: Rhode Island

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

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%. 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.
https://www.krsaborio.net/unix-scalability/research/1990/1126.html

Motorola: Too little, too late and WAY TOO expensive!

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. This is why the 8502 got relocatable stack pointer and relocatable ZeroPage...which eventually became part of the 65C02 formally.

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

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

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

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.

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.

In case you are still confused ... a C128 can multi-task:
https://www.youtube.com/watch?v=Zp4zonl4gQ0

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. Meanwhile Commodore have a VIC-III in 1988 that could compete with ECS but was chunky and offered fast tile-graphics.

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

Motorola held the Amiga back. Garbage IPC until the over-priced and late '040. If an Amiga cost [only] $100 more than a C64 in 1987, no one would be talking about any other system but Amiga.

Last edited by Lou on 08-Aug-2024 at 07:43 PM.
Last edited by Lou on 08-Aug-2024 at 07:09 PM.
Last edited by Lou on 08-Aug-2024 at 06:51 PM.

 Status: Offline
Profile     Report this post  
Lou 
Re: DoomAttack (Akiko C2P) on Amiga CD32 + Fast RAM (Wicher CD32)
Posted on 8-Aug-2024 20:14:48
#300 ]
Elite Member
Joined: 2-Nov-2004
Posts: 4229
From: Rhode Island

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.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 Next Page )

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