CPC: Underpowered for 1984?

[St-BeidE(DE/GB)]

Sadly, the CPC was not powerful enough,
to control NORAD. That is, why WOPR was used.

[GUNHED]

imho all 8 (/16) bit cpus are 'risc'-like anyway.

No, not at all.
According to Federico Faggin even the Z80 already has some kind of microcode.

CISC is imo something like multi media commands and all that super complex stuff. Ok - if you want so - we can start with Multiply instructions. 

Or you can just call anything CISC which is more than a byte. On the other hand all the Z80 opcodes which need more than 1 us may be considered CISC too.

However just look at current PC CPUs and then a 8/16 Bit CPUs. 

[Prodatron]

The term CISC was introduced in 1970 and has nothing to do with multimedia extensions.
It also doesn't matter if a CPU is 8, 16, 32, 64bit or whatever.
Even the creator of the Z80 confirmed, that the Z80 falls in the category of CISC cpus due to its microcode.

Btw, even the 6502 is defined as a CISC cpu:

https://en.wikipedia.org/wiki/Complex_instruction_set_computer

Well known microprocessors and microcontrollers that have also been labeled CISC in many academic publications include the Motorola 6800, 6809 and 68000 families; the Intel 8080, iAPX 432 and x86 family; the Zilog Z80, Z8 and Z8000 families; the National Semiconductor NS320xx family; the MOS Technology 6502 family; the Intel 8051 family; and others.

Todays CPUs all don't use microcode anymore, internally they are all working like RISC cpus, even the Intel ones. This already happend during the 90ies.

It's fine for you, if you have your personal definition of CISC and RISC, but it has not much to do with the reality.

[GUNHED]

Well, as I published back the day in several issues of the SCUG magazine: No RISC more fun!

[zhulien]

I've never done any 6502 programming (yet) but I'm kind of curious to have a go at making something for the Vectrex sometime.

That has a 6809, which is a 6800 variant that failed in the market due to being six times the price of the 6502 and Z80. But it has some cool additional features like a relocatable zero page, two stacks, and it can multiply two 8 bit numbers in hardware.

Z80 can multiply some 8bit numbers in hardware.

[andycadley]

The 6502 follows more a RISC philosophy where the Z80 more CISC orientated is.

Honestly this gets spouted so often and it's utter rubbish. One of the key tenets of "RISC" was a large number of registers, which is about as far from 6502 as you can get.

It has a more orthogonal instruction set than Z80, but that's more a consequence of having very few registers, rather than a conscious design decision to make registers easily interchangable.

[HAL6128]

Yes, that's right. The 6510 is formally a CISC cpu. It's just about the wording "complex" & "reduced instruction" where the z80 has 252 commands and the 6510 works with 56.
But yes again, there's more than the number of instructions.

[WxAxNxDxExRxExR]

In short, no, it wasn't.

I believe I switched over from C64 to my trusty CPC6128 with a green monitor as late as 1988, or maybe even 1989... At the time, both Atari ST and Amiga were way, way out of my league price-wise. Actually, having then experienced CP/M (and its outstanding Turbo Pascal) only re-affirmed my craving for a decent PC, which were even more expensive than the ST and the Amiga in any variant.

I saw my CPC6128 for what it was -- the perfected 8-bit/gaming machine and a peek into more serious stuff I had already experienced through PC mainly at school, and neither ST or Amiga really attracted me too much; I saw these as further improved gaming machines and nothing more. 

True, the CPC had no sprites, but its BASIC was so much more advanced than both Speccy and C64. It represented the 8-bit era swan song, in my view.

[cwpab]

Thanks to this post, today I learned that x86 is CISC and ARM is RISC.

My dear PSX was RISC and that apparently helped it... I believe the 3DO was not RISC. I'm not sure how many consoles use(d) RISC, but a quick search revealed RISC was only used starting with the PSX (not sure if Saturn) and stopped at the PS3 era, as PS4 and other later consoles switched back to CISC with x86.

I have also learned that RISC uses more instructions to do the same, but it saves hardware space or transistors because these instructions use only one clock (cycle?) and this allows for pipelining.

A few weeks ago, I also read that a RISC processor was about 3x as fast as a CISC processor with the same speed (at least for consoles and games).

I wonder if the industry will move to the RISC ARM processors at some point.

[cwpab]

Back to the CPC Vs. C64 comparison, it looks like the CPC CPU is 4x faster when it comes to Mhz, but Z80 processors are said to be equivalent to half the speed compared directly to 6502 ones (see a link I pasted in the previous page). However, since the CPC CPU has 4x the Mhz, this means:

- CPC has a CPU twice as fast as the C64
- But the C64 compensates this by using the CPU much less thanks to the hardware sprites and other tricks
- Which aren't enough for the 3D games and this should techinically be noticeable in the CPC Vs. C64 game comparisons

[andycadley]

Thanks to this post, today I learned that x86 is CISC and ARM is RISC.

...

A few weeks ago, I also read that a RISC processor was about 3x as fast as a CISC processor with the same speed (at least for consoles and games).

I wonder if the industry will move to the RISC ARM processors at some point.

Well yes, but mostly no. 

CISC Vs RISC was, in the end, a complete non event. Modern x86 processors are RISC internally (at the microcode level) and CISC on the outside. And so are ARM processors.

That wasn't the way people expected it to go, but memory bandwidth didn't scale as fast as CPU internal speeds. And so all modern CPUs decide more "complex" instructions in microcode and turn each one into a sort of mini RISC program, gaining both the CISC benefits of being able to express operations in only a few instructions, and the RISC benefits of simplified internal operations.

[lightforce6128]

I've never done any 6502 programming (yet) but I'm kind of curious to have a go at making something for the Vectrex sometime.

That has a 6809, which is a 6800 variant that failed in the market due to being six times the price of the 6502 and Z80. But it has some cool additional features like a relocatable zero page, two stacks, and it can multiply two 8 bit numbers in hardware.

Z80 can multiply some 8bit numbers in hardware.

There is an extended version of the Z80 CPU (R800) that offers multiply commands. But the Z80 can - as far as I know - only use adding and shifting, what soon ends up in long command sequences.

[lightforce6128]

Back to the CPC Vs. C64 comparison, it looks like the CPC CPU is 4x faster when it comes to Mhz, but Z80 processors are said to be equivalent to half the speed compared directly to 6502 ones (see a link I pasted in the previous page). However, since the CPC CPU has 4x the Mhz, this means:

- CPC has a CPU twice as fast as the C64
- But the C64 compensates this by using the CPU much less thanks to the hardware sprites and other tricks
- Which aren't enough for the 3D games and this should techinically be noticeable in the CPC Vs. C64 game comparisons

Both CPUs, on CPC and C64 side, are slowed down to avoid memory access collisions with graphics hardware. With this, the Z80 looses up to 25% of its speed. From C64 side I heard things are much more complex there, because the slow down differs between text/graphics area and border. I consider a constant slow down as an advantage - it simplifies programming.

The C64 offers some text modes, what allows for a much faster screen update than one could achieve in a graphics mode. Although text characters are much chunkier than pixels, with clever programming this can be (and is) used for fast games and demos. In the CPC the CRTC also operates in some kind of text mode, but hardwired to the Gate Array only different graphic modes are possible.

[lightforce6128]

I wish the CPC would move as fast as the C64, but I also believe scrolling is overrated. ...

I'm not sure where this comes from, but the problem with the CPC is that it scrolls too fast, not too slow (see e.g. here). Some effort is necessary to make it scroll slow (e.g. here and here). That many games were badly ported from ZX Spectrum, where the poor CPC more or less had to run some kind of virtual machine for the ZX Spectrum graphics hardware, is another story.

About the C64 I heard that scrolling can only be done for eight pixels in each direction. After this, memory needs to be copied. This does not really sound like hardware scrolling.

I completely agree on that scrolling itself does not make up a good game and that some fresh colors aren't a bad thing.

[Anthony Flack]

This is true and the reason why many C64 games have only a 4 colour background; because there is time to rewrite the tile data but not the colour data. However much like with the CPC, coders have since found ways to glitch the machine and get around this.

[Prodatron]

From C64 side I heard things are much more complex there, because the slow down differs between text/graphics area and border.

This is called "bad lines". Every 8 lines (when a new "text" line starts), the C64s VIC2 has to grab additional data from the video ram, and here the CPU is slowed down a lot or even stopped (I don't remember exactly).
This "only" happens inside of the 40x25 char screen area, not in the borders. Outside of the bad lines the CPU isn't slowed down, as the 1MHz of the 6502 and the 1MHz of the VIC2 can perfectly share the 2MHz of the RAM.

[Neurox66]

In this discussion I have read some somewhat confusing statements.
I would put some fixed points:
RISC= reduced instruction set computer
CISC= complex instruction set computer
Already the acronym should be clear about the different architecture used within the CPUs.
The Motorola 6800, Intel 8080, Zilog Z80 (Mostek, Nec, Sharp, Toshiba Z80 Compatible), MOS 6502, processor families are CISCs.
ARM, MIPS, and Dec Alpha CPUs are RISC.
Handheld consoles such as GameBoy and GameBoy Color, Game Gear have a Z80 while the GameBoy Advance, Nintendo DS use an ARM.
In my opinion if I were to compare the CPC I would do it with the other 8Bit HomeComputers.
So I would not stop at just the C64 and the ZX Spectrum but also Apple II, TRS80, Atari (400/800/1200 ect), Thomson, SamCoupé and all those hundreds (if not thousands) of 8Bit computers that are part of the HomeComputers that came out between 1977 and 1994.

[cwpab]

The CISC Vs. RISC debate is perhaps not very related to the CPC CPU, but it's an interesting offtopic. And it's still related if you consider in the CPC Vs. C64 debate, one of the processor has been described here as having 5x less the number of instructions even if both are technically CISC.

[andycadley]

Both CPUs, on CPC and C64 side, are slowed down to avoid memory access collisions with graphics hardware. With this, the Z80 looses up to 25% of its speed. From C64 side I heard things are much more complex there, because the slow down differs between text/graphics area and border. I consider a constant slow down as an advantage - it simplifies programming.

Where the 6502 wins out over the Z80 in this regards, is how regularly it accesses the bus. On the Z80 it's a bit random and entirely dependent on the instructions being executed. On the 6502, however, the CPU will only ever access the bus on alternate cycles, leaving half the cycles available for a video controller to access RAM in a predictable pattern.

That not quite enough on the C64 because character based modes require more reads every so often (you have to read the line of characters plus the bytes that make up the current row) and that's what causes "bad lines" where the CPU suffers additional stalls.

The design of the CPC video hardware is such that this wouldn't have been an issue with a 6502 and it could very well have run at the full 2Mhz without any slowdown. Whether that would be better or not is hard to say, I'm not sure a 6502 is as efficient as a Z80 when it comes to block copying and the lack of registers may well have hurt things like masked sprite routines.

I'm not sure where this comes from, but the problem with the CPC is that it scrolls too fast, not too slow (see e.g. here). Some effort is necessary to make it scroll slow

I think that's a somewhat misleading way of describing it. The hardware scrolling in the CPC isn't too fast, it's too course. It's intended for text scrolling and thus the resolution is Mode 1 sized characters, you can write a game with scrolling like that (many MSX games did for example) but a lot of the time it'll look jerky.

About the C64 I heard that scrolling can only be done for eight pixels in each direction. After this, memory needs to be copied. This does not really sound like hardware scrolling.

The C64 can offset the start of the screen by up to 7 pixels. It can also move the character map around in memory to some extent, so you can get reasonably consistent scrolling without having to copy lots of data around (well at some point you do have to but it's not difficult). The only tricky bit is that the Colour RAM, which provides the attribute map that assigns colours/modes to individual characters is fixed in RAM. Hence a lot of games "cheating" by just never changing the colour area and keeping the background a consistent 4 colours.

The thing is, moving the screen by individual pixels is the hard bit as it requires a lot of bit level manipulation of memory, which is why the hardware assistance in the C64 makes such a big difference (coupled with sprites which avoid the need to redraw areas of the screen too).

[andycadley]

The CISC Vs. RISC debate is perhaps not very related to the CPC CPU, but it's an interesting offtopic. And it's still related if you consider in the CPC Vs. C64 debate, one of the processor has been described here as having 5x less the number of instructions even if both are technically CISC.

5x less instructions is also one of those slightly nonsensical comparisons though. Do all the different Z80 ADD instructions count? Are you counting addressing modes separately?

In real terms they have similar instructions, albeit with the Z80 having a bunch of block operations that the 6502 doesn't. But the instruction timings of core instructions, number of registers available and things like the Z80 having a full 16-bit stack are really where the biggest differences come into play. 

"Number of instructions" isn't really a useful metric. Even for RISC, the "reduced" bit meant "reduced in complexity" not "reduced in number" - most RISC chips at the time had as many, if not more, instructions.

[MaV]

The 3DO has an ARM RISC processor, the Saturn's SH-1 and SH-2 processors are also RISC.

And as Prodatron noted, all the current processors - even if they have a CISC instruction set - use a RISC core at its base. Intel and AMD for example just don't give you access to it.

A few weeks ago, I also read that a RISC processor was about 3x as fast as a CISC processor with the same speed (at least for consoles and games).

That statement is too general and as stated above all processors today have a RISC implementation.

I wonder if the industry will move to the RISC ARM processors at some point.

It already has. ARM is in all mobile and smart phones, in all the current Apple devices, in the Switch, the Raspberry PI and its clones, in all the modern calculators, etc, etc.
If you ask me, it's time that a new competitor takes hold in the market, RISC V hopefully which is an open source RISC instruction set. There are devices (prototype boards mostly) which use them already.

[MaV]

and here the CPU is slowed down a lot or even stopped (I don't remember exactly).

It's slowed down. You can't stop a 6502.

Here's a good thread about halting the 6502:
dma - For how long can you safely stop the clock on an NMOS 6502? - Retrocomputing Stack Exchange

[zhulien]

I've never done any 6502 programming (yet) but I'm kind of curious to have a go at making something for the Vectrex sometime.

That has a 6809, which is a 6800 variant that failed in the market due to being six times the price of the 6502 and Z80. But it has some cool additional features like a relocatable zero page, two stacks, and it can multiply two 8 bit numbers in hardware.

Z80 can multiply some 8bit numbers in hardware.

There is an extended version of the Z80 CPU (R800) that offers multiply commands. But the Z80 can - as far as I know - only use adding and shifting, what soon ends up in long command sequences.

I did say some numbers, such as those that thr add operation has the same outcome as a multiply would.

Like x 2.  Add a,a is also a x2

[andycadley]

and here the CPU is slowed down a lot or even stopped (I don't remember exactly).

It's slowed down. You can't stop a 6502.

Here's a good thread about halting the 6502:
dma - For how long can you safely stop the clock on an NMOS 6502? - Retrocomputing Stack Exchange

That's stopping the clock, which would be a weird way of trying to stop the CPU (I'd imagine a Z80 might also do strange things in that case too, such as upsetting refresh). The 6502 has a RDY line which external devices can use to halt the CPU temporarily (I'd guess that's what the C64 does but. I've never looked into it).

[asertus]

I agree with most of the comments. When talking about "underpowered" we must put in context the price. By that time, even Amigas were underpowered compared to much more expensive computers. As later were the PCs compared to SGI computers, until they were no more.

To me, by 1984-85 (6128), they were very well balanced.. by that time there were also some new 8bit Atari computers, XL (83), XE (85) that were no better than CPCs. But I see C64 was very good when launched.

Of course, plus series were disappointing for me.