Would you think the games would've been better or worse?  I think games would be a little better, because "more familiar hardware" = "faster development" = "more time to push the limits of the system."

Standardize how? The SNES IS as standard as it gets if you know why they used everything. The SPC is the biggest change. The PPU was beefed up a ton, and so was stuff like DMA. But the CPU pretty much the same, it would take less than an hour to learn all it's extras and start using them if you know how the 6502 works. Using a 68000 or something in it's place might have gotten you better arcade ports from Konami and stuff, but it would have ruined all the comfot the NES programmers had, especially the Nintendo ones who programmed the NES every day for 5+ years.

I think it'd of been terrible for them to choose another processor, even if the 68K is a absolute beast of a processor. It still isn't as efficient, different endian, different addressing modes...nah, bad idea.

My question was, what if the SNES used a more standardized video and audio chipset, but kept the same 65816 CPU. Not the other way around.

Well what would be more standard? Those Yamaha PSG's? It has a set of PSG's too. It doesn't really matter though honestly, they had teams just to program them alone.

And SNES's PPU is pretty darn like the NES's, can't get more standard on that either really.

DP :/

I think the OP means "off-the-shelf", opposite of Nintendo's habit of using 100% proprietary hardware in their consoles, including the SNES. The S-PPU is a special one-off graphic processor, made only for the SNES and any derivative hardware.

There was no quality "standard" AV system at the time. Things that became standards like SoundBlaster16 were years after SNES.

Pretty much.  It doesn't have to be 100% off the shelves, but similar to off-the-shelf-chips or chips used from competiting companies.  It seems like Nintendo went out of their way to be different from Sega.
The near backwards compatibilty with the NES's PPU is what ruined it.

On the NES, sprite attributes tables use 4 bytes per sprite entry, with 8-bit X and Y coordinates.  This wasn't a big problem for the NES because sprites were only 8x8, so "popping" wasn't that noticeable.  The SNES also uses 4 bytes per sprite entry, and 8-bit X and Y coordinates, but there's a problem with that.  In the last minute, Nintendo decided to add support for larger sprite sizes, and because larger sprites would have more noticeable "popping" artifacts, they needed an extra 9th bit for X coordinates.  So what they did was add an extra 32 bytes to the end of the sprite attributes table, just to fit in the 2 extra bits.

They should've just used 16-bit X and Y coordinates from the start.

Even the Genesis VDP is not "off the shelf". It was customized. Both the SNES and Genesis have standard CPUs. The SNES has a Sound chip made by Sony only used in the SNES. The Genesis has a PSG and a YM chip that were used in some other devices. But none of this exactly would have helped the SNES be "better". Or the games for it.

What helped to bring about better SNES games was experience and the cost of ROM memory coming down. The one thing that I think might have been nice for SNES would have been if they had a faster CPU. But that could cause other issues and they were concerned about cost already. In the end it obviously worked out alright. The same can be said for the Genesis. Both were very successful systems.

SNES isn't backwards compatible, they scrapped that. We only know because some of the memory map is set up the same way. I'm sure it did not affect the final product in any way really.

As for the coords, that's not that huge of a deal. Update your sprites natrually, and then before finishing it off for an object have it bulk write the needed bits for the extra coord. IMO,  they did it that way because it saves RAM, not because of any other reason. Even the unused sprite bits on NES don't work. It'd cost more to add them in to do nothing, so why add them at all?

ETA: Check out the SNES OAM layout:

First 4 bytes: 

OAMObject*4+0:xxxx.xxxx
OAMObject*4+1:yyyy.yyyy
OAMObject*4+2:cccc.cccc
OAMObject*4+3:vhoo.pppn

They have every bit used. They have two extra bits for X and S the the size and X coord of the screen. They didn't have the bits available anywhere. Making it count by 5 bytes per each entry (to store the extra 2 bits needed for OAM) involve adding more circuity that wasn't cheaper than adding 32 bytes and having a seperate counter/lookup for that data. It might not be the best for the programmer, but it makes perfect sense if you can understand what they were trying to do. Make it cheaper to make.

Does it need extra silicon for unused bits?

Not if they don't add it, but changing OAM to 5 bytes per sprite instead of 4 add a TON of silicon/design. Look at it in binary for each sprite:

Sprite 0 byte 1: %00000000
Sprite 0 byte 2: %00000001
Sprite 0 byte 3: %00000010
Sprite 0 byte 4: %00000011

Sprite 1 byte 1: %00000100
Sprite 1 byte 2: %00000101
Sprite 1 byte 3: %00000110
Sprite 1 byte 4: %00000111

Sprite 2 byte 1: %00001000
Sprite 2 byte 2: %00001001
Sprite 2 byte 3: %00001010
Sprite 2 byte 4: %00001011

See how each sprite just uses the lower 2 bites, and the top 6 all just happen to be the sprite number? (Top 6, although thats infintely expandable) You change that to 5 bytes, and the top bits don't turn in to the sprite number automatically, making it harder to decode inside the chip because you can't just shift some bits, you have to add a look up table, or a multiplication circuit. Multiply circuit would take a ton of gates, and a look up table probably more. That's why they did it that way. Not including bits is easy, while excluding tons of bytes from an array is hard. Making the second table is the only way to do it efficiently.

Okay, how about bringing the number of sprites down to 64, but having 8 bytes per sprite, set up like this:

sssh---x xxxxxxxx
sssv---y yyyyyyyy
cccppnnn nnnnnnnn
-------- --------

If it was done this way, a sprite could be any size between 8x8 and 64x64, and can be placed anywhere in the 64kB of vram.


Edit:  Just so you don't get confused, "C" is for "color" and "P" is for "priority."  I notice that you have a different lettering scheme.

The number of sprites doesn't matter, it's the features they have, including flipping, position, palette, and whatever else they added. No real way to create more bits outside of eliminate some features.

I'm a little bit confused to what your trying to say?

It'd be a waste to make them 8 bytes though, they have no reason to be 8 bytes. It'd be a better (in the sense of not having a 32 bytes table at the end) not to have some other feature like sprite priority to get the extra bits in that are NEEDED. But still, going from 4 to 8 bytes for sprites doesn't do much when 3 of those more than likely wouldn't have been be used. Especially sacrificing so many sprites to do that instead. It's perfect how it is honestly. I mean, it might be a little weird to program, but it's not that bad.

It's one of those things they could have done it that way and most people wouldn't care and it may be a tad easier to program, but then people who know hardware would just ask who designed such a piece of shit. Plus, no way in the world making it a tad easier to sort out is worth halving the ammount of sprites you have. No way.

When you have more available sprite sizes, it takes less sprites to build larger objects.

But when you have half the sprites to gain nothing but a nice and round OAM, it's not worth it. Plus, then you have less tiles to make characters out of then and have to make them bigger and waste graphics.

When you have the entire 64kB of vram to hold sprite patterns instead of only 16kB, (because Nintendo had to cut off 2 bits from the name table just to fit in the clusterphobic OAM) it is alright if sprites take up a couple extra tiles.

Have you programmed anything for NES or SNES even? I don't see why your so stuck up on something that has never and probably never will affect you. They need that 64KB of video memory for sprites and smaller sprites and bigger sprites both help programming and using them effectively. I know, I've rewritten a game to use 8x16 instead of 8x8 sprites for NES.

What does the OAM have to do with the nametable? It's separate, even if you're talking about the graphics tables.

You should take to luigimaster, you and him will get along great telling programmers/hardware guys how to make a better games/systems.

I do SNES programming, and building metasprites is a VERY TIME CONSUMING JOB for the programmer.  On the bottom is an old version of my homebrew game.  It is currently on haitus.

"They need that 64KB of video memory for sprites and smaller sprites and bigger sprites both help programming and using them effectively."

This is why using only 4 bytes per oam sprite entry is not enough.  In order to have 64KB you need to have 11 CHR-selection bits.  The SNES only has 9 CHR-selection bits, so your forced into 16kB.



"What does the OAM have to do with the nametable? It's separate, even if you're talking about the graphics tables."

Because "nametable" is another word for CHR-selection bits, and the number of "nametable" bits effect the size of the sprite pattern table, since you can only access 512 sprite patterns with 9 bit "nametables."

I don't see how the extra bytes don't help, because then you can upload 4 animation frames without modifying current VRAM, or some tiles just for the background/text layer, etc.

Damn it psychopathic! Didn't know that was you, I thought you were another person trying to act like they knew how to program and SNES. Oh well, this still makes sense to me hardware wise. Maybe just mess and try to do more tricks with it, I'm sure it's not that bad considering the games that were created on the system.

Makes sense now. It's too bad he wasn't around to help Nintendo design the SNES. Clearly they needed his help after only selling 49 million+ consoles.

Why do you complain about these old consoles and what you can or can't do on them? Is SNES not enough for you? Make your game for Playstation. Still not enough? Try DreamCast, PS2, PSP, the PC.

The SNES was clearly quite capable as it was. Tons of great games, business wise it did very well. It has a great legacy. We can discuss the hardware all day long, suggesting what they should and shouldn't have done, speculate on the impact changes might have had. But it's pretty apparent that the SNES design proved to work out ok. I have always thought it would have been nice if the processor was faster but that opens a can of worms. Faster CPU would need faster ROM or RAM. Faster ROM means more expensive game carts. Faster RAM in the system means more expensive system. And while there certainly is slowdown in various games, plenty of them don't really have that issue in any negatve way. In Gradius III the slowdown actually makes the game possible for human players to complete.

Speaking about off-the-shelf parts.

Graphics. In 1990 there was Yamaha V9958 - nothing comparable to SNES PPU. In 1992 there was V9990 - close to Genesis, but still far away from SNES capabilities.

Sound. SPC700 MCU itself is an off-the-shelf part, that is custom is the S-DSP. There were few ADPCM chips at the time (OKI, Yamaha), so they could probably make the whole sound system from standart parts, but with inferior capabilities. As far as I know, ADPCM chips of the time didn't have volume envelope support, not even reverb or stereo panning.


SNES hardware in general has few quirks, but overall the design is pretty powerful and nice, especially considering it was designed before 1990.

If you mean "extra bytes" as in the 32 bytes of hi-oam, I never said that they don't help.  My point was if you need more than 4 bytes per sprite entry, you might as well use 8 bytes per sprite entry and reimplement features that were cut.