Nobody ever had problems with the NES cpu?

[psycopathicteen]

Developers complained about the SNES's CPU so much back in the day, I wonder why nobody complained much about the NES's CPU, since the NES was even slower.

[Shiru]

Easy, NES CPU wasn't slower compared to contemporary game systems, and was faster compared to the previous generation (Atari 2600 etc).

[tepples]

The NES CPU runs at the same speed as that of the Atari 7800 and (assuming a 2:1 IPC ratio*) the Master System. The 65816 in the Super NES likewise runs about the same instructions per second as the 68000 in the Genesis (proof), and it has almost the same data bus bandwidth. One problem is the 65816's relative lack of certain C-friendly constructs present in the 68000, such as 32-bit registers, autoincrement addressing modes, abuse of the address generator as an ALU with the LEA instruction, and 16-bit multiplication and division. (The built-in multiplier and divider on the S-CPU are 8-bit.) Switching between operating on 8- and 16-bit values requires setting a mode (using REP or SEP), which takes programmer care to ensure that the mode is correct at subroutine entry and exit. The packed pixel format of the Genesis VDP is also more convenient for certain data compression methods.

It is, however, an improvement over the 6502, with new addressing modes that take some of the load off the X and Y registers: movable zero page is a frame pointer freeing X, zero page indirect without indexing frees Y, and stack-relative addressing modes free X. Dedicated instructions (JML, PHK, PLB, PHB) and addressing instructions perform bank switching with less pain. And the S-CPU has a DMA unit at $004300 that can perform both Blast Processing (hardware accelerated memcpy to video memory) and automatic raster effects.


* Let C64 fans who fought in the C64 vs. Speccy flame wars correct me.

[psycopathicteen]

Easy, NES CPU wasn't slower compared to contemporary game systems, and was faster compared to the previous generation (Atari 2600 etc).

Okay, that's a good point, but I still wonder why it seems like everyone totally forgot everything they knew about the 6502 when the SNES came out. There are some games that run smoother on the NES than their SNES counterpart, which doesn't make sense because they could've used practically the same code for both systems, and the SNES would've still ran a bit faster.

[rainwarrior]

The entire premise of this thread is wrong.

Everybody who works with any CPU has problems with it. Software engineering is difficult, and the CPU's architecture is a huge set of problems to deal with. You really haven't heard of anyone complaining about the NES CPU before? You aren't looking.

[tokumaru]

There are some games that run smoother on the NES than their SNES counterpart

I guess that by the time the SNES came out, programmers were already starting to abandon the practice of coding directly in ASM, favoring higher-level languages like C, so even when games weren't made in C, most programmers weren't experienced enough with the CPU to get the most out of it.

The previous generation of consoles used mostly the 6502 and the Z80, which were also present in a multitude of personal computers which people used when learning to code, so there were many more 6502 and Z80 experts than 65816 or 68000. Programmers that stayed in the industry for longer periods probably made better use of the 65816.

I'm just guessing, of course.

[tepples]

There are some games that run smoother on the NES than their SNES counterpart, which doesn't make sense because they could've used practically the same code for both systems

Not if Nintendo required a developer to make conspicuous use of the Super NES features on which Nintendo was spending loads of marketing money.

• NES doesn't have to stream sound effect samples to the SPC700; instead, it can bankswitch PRG ROM at $C000-$DFFF.
• NES doesn't have to memcpy huge tile data every frame for tile animation; instead, it can bankswitch CHR ROM.
• NES palette updates are smaller.
• NES doesn't have to update three layers of nametables, though the more orthogonal attribute system probably balances this out.
• NES doesn't have to update the size and high X flags to keep sprites from popping up at far left.

As for computers, the Apple IIGS was using the 65816, and the Mac, Amiga, and Atari ST were using the 68000. How many Genesis game developers came from the Amiga and ST scenes?

[psycopathicteen]

There are some games that run smoother on the NES than their SNES counterpart

I guess that by the time the SNES came out, programmers were already starting to abandon the practice of coding directly in ASM, favoring higher-level languages like C, so even when games weren't made in C, most programmers weren't experienced enough with the CPU to get the most out of it.

The previous generation of consoles used mostly the 6502 and the Z80, which were also present in a multitude of personal computers which people used when learning to code, so there were many more 6502 and Z80 experts than 65816 or 68000. Programmers that stayed in the industry for longer periods probably made better use of the 65816.

I'm just guessing, of course.

There were a lot of people who were experts with the 68000 because it was widely used in arcade games. I have always questioned if SNES games were actually written in asm, because of it being so time consuming, and the amount of slowdown in some games.

[tepples]

Viewpoint for Genesis is a port of an arcade game, and it runs on a 68K based console, but it still becomes molasses whenever more than one enemy is on the screen.

[Bregalad]

To answer the original question, I think nobody really had much of a problem with the SNES CPU exept Sega fanboys. The CPU was the only part of the Megadrive's hardware which was not clearly much more worse than the SNES' (they are about of equal processing power, as shown by tepples). However, being clocked about 2x faster, Sega used it as a marketing argument into tricking people to think the CPU was faster with so-called "Blast processing". Back then, nobody really knew anything about processor architecture exept professionals, and the general public was under the wrong assumption that the clock frequency was the only way to measure a CPU performance.
Unfortunately it only measures performance between two processors of the same architecture.

Switching between operating on 8- and 16-bit values requires setting a mode (using REP or SEP), which takes programmer care to ensure that the mode is correct at subroutine entry and exit.

On a related note, is there any use for register smaller than 16-bit, other than writing to 8-bit memory mapped I/O ? Or is the point to reduce the code or data size ? Considering how large SNES carts and it's RAM can be I think it's much less of an issue than on the NES.

[tepples]

On a related note, is there any use for register smaller than 16-bit, other than writing to 8-bit memory mapped I/O ? Or is the point to reduce the code or data size ?

Or when another IC on the bus expects 8-bit data, such as a row of tile data in a proportional font engine or a software sprite occlusion engine, or the entries in a display list to be copied to OAM.

Considering how large SNES carts and it's RAM can be I think it's much less of an issue than on the NES.

A lot of games have so much tile data, so much map data, or (especially in RPGs) so much text that even 8 bits are too much, and they need to compress the data. A lot of RPGs use digram coding (also called BPE or DTE), which allocates half of the 8-bit space to a binary tree representing common combinations of characters that appear together. For example, $80 could represent "qu" and $81 could represent $80 followed by "e", squeezing "que" into one byte. Others use Huffman coding, assigning short bit strings either to individual characters or to entire words. Star Ocean and Street Fighter Alpha 2 use so much compression on their tile data that it takes a separate IC in the cart to undo it.

[MottZilla]

There were a lot of people who were experts with the 68000 because it was widely used in arcade games. I have always questioned if SNES games were actually written in asm, because of it being so time consuming, and the amount of slowdown in some games.

Lots of SNES games and I'm sure Genesis games were programmed in Assembly. Some were also programmed in C. At the end of the day their performance is what matters. Just because a game suffers slowdowns isn't because it was programmed in C. It's entirely possible that a game is programmed quite efficiently but it just has too large of a workload to avoid slowdown due to the design of the game or the exact situation occurring.

I do recall hearing that Capcom CPS2 arcade games were programmed in C. It's era was from 1993 onward. And it ofcourse used the 68000. I imagine alot less console games prior to the 32bit generation were programmed in C than in ASM. ASM may be more time consuming but we are talking about people for whom this was their job. It's different than being a hobbyist.

[tepples]

It's entirely possible that a game is programmed quite efficiently but it just has too large of a workload to avoid slowdown due to the design of the game or the exact situation occurring.

The question was why a Super NES game would have a substantially larger workload than the NES version of the same game.

[psycopathicteen]

Tepples mentioned the NES not having to update CHR tiles every frame. I don't think many early SNES games had elaborate animation schemes. I think most early SNES games used DMA just for player and bosses, everything else just remained in VRAM.

[ccovell]

I wonder why nobody complained much about the NES's CPU, since the NES was even slower.

Well, I did put this poetry in the silent version of Solar Wars, in lieu of music:

Code: Select all

Ode to the NES

When I first touched you, it was love at first sight.
Your games were so fun, and your graphics so bright.
The years have gone by, and you're great all the same,
So I learnt of your hardware and coded a game.

I studied your specs as I programmed about,
But I certainly didn't like what I had found out:
That your memory was minuscule, and your processor slow,
And your PPU limited, and your resolution low.
And your timing so finicky, it made my head spin,
And your carts that didn't work when they were pushed in.
Not to mention a palette so daft that it hurt,
But your composite display was by far the worst.

So, I'm leaving you, dear NES, maybe even for good,
I'd come back if you improved, but I don't think you would.
In your time you were a most spectacular machine,
But you haven't got shit on the Turbografx-16.
              Oct 10, 1999