65816 really 16 bit or just a 6502 with 16 bit registers

[TOUKO]

Lol ramsis,you got me

[Sik]

Just gonna say: the biggest bottleneck with the SNES is not the CPU per-se, it's how setting up the hardware to do something is ridiculously complex (in terms of what operations the CPU has to do). Yeah, talking about where bits go arranged or how memory is laid out and such. It definitely makes things harder to do than they could have been.

If I were to "redesign the SNES" as Espozo suggest, I'd add NES backwards compatibility, and add accessible NES pAPU audio channels to SNES games, so it could sound similar to a GBA Even if this means scarifying one or two sound channels for the SPC700.

Honestly, I imagine the main reason NES compatibility is not in the SNES (despite being traces of it in the design) is that games rely so absurdly much in every single timing detail of the NES that it would be completely unfeasible to pull it off with modified hardware short of having two separate PPUs (EDIT: yeah I know the S-PPU is already split in two, I mean adding the NES one alongside those as well). I don't think I need to explain that was never going to be worth the cost.

On the other hand it would be interesting to see how it'd have been if the SNES was some sort of improved NES instead of its own new thing. Even if they had to ditch backwards compatibility due to different timings.

[TOUKO]

I agree sik,the limited cycles available would not have been a problem if the hardware was clean .

[AWJ]

How about the SA-1 ??, it's simply a 65816 core or an improved/custom one ?? (i don't speak of DMA, and all others feature embedded, but only the CPU core) .

It's a totally standard 65816, with a custom memory system wrapped around it to let it run at 10MHz without needing excessively fast (for 1996) external ROM and RAM. Specifically, it's got separate busses to ROM and to RAM, the ROM bus is 16-bit with a prefetch queue for instructions, the RAM bus has a write buffer, and there's 2KB of fast internal RAM that can be used for direct page and the stack.

[Nicole]

I think any debates about which console is more powerful have ceased to be relevant decades ago. Do you know which console is even more powerful than the SNES or Genesis? The N64, PS1, Saturn, Dreamcast, PS2, GameCube, Xbox, PS3, Wii, Xbox 360, PS4, Wii U, Xbox One, and so on.

Let's face it, we aren't programming for these things because they're the best thing on the market. It's probably at least 70% nostalgia, and 30% interest in working with limited, old hardware. At that point, it doesn't matter which is more powerful, it's just a matter of personal taste when it comes to which constraints you want to deal with.

Which is more powerful, the NES or SNES? Obviously the SNES, but somehow these are still called the nesdev forums. Why? Because console power is irrelevant here.

It's like that myth about a goldfish that grows to meet the size of its bowl.

While we're derailing endlessly... for the most part this isn't a myth; given the proper environment, goldfish grow to be more than a foot long, and can live for more than ten years.

[TOUKO]

How about the SA-1 ??, it's simply a 65816 core or an improved/custom one ?? (i don't speak of DMA, and all others feature embedded, but only the CPU core) .

It's a totally standard 65816, with a custom memory system wrapped around it to let it run at 10MHz without needing excessively fast (for 1996) external ROM and RAM. Specifically, it's got separate busses to ROM and to RAM, the ROM bus is 16-bit with a prefetch queue for instructions, the RAM bus has a write buffer, and there's 2KB of fast internal RAM that can be used for direct page and the stack.

Thanks for the infos
But what do you mean by "not excessively fast" ??,it adds some wait states when accesing rom or external RAM ??

@nicole:The topic here has derailed,it was more about the wrong infos about the snes cpu than console war.

[rainwarrior]

It's like that myth about a goldfish that grows to meet the size of its bowl.

While we're derailing endlessly... for the most part this isn't a myth; given the proper environment, goldfish grow to be more than a foot long, and can live for more than ten years.

The myth is that it's the size of the tank, which is not really the limiting factor, though related.

My point was that the complaints that "if it only had more memory" were about the size of your goals. When I was working on PS3, devs constantly complained about "only" having 256 MB of system memory, even though this is 8 times as much as the previous generation had. In another time, someone managed to make a complex 3D space shooter like Star Raiders with only 128 bytes of RAM.

Nowadays you can just have recorded music, or even complex mixed music with relatively modest memory and CPU requirements (compared to what tends to be available). Game audio just doesn't typically have needs that are constrained by the modern environment, and it had been a tremendously free situation. Eventually you can escape!

Indie games got to escape from practical constraints like that a lot earlier than AAA games, since they're not competing to use everything they can to make their game look better than others in a technical way. Modern AAA games are still a struggle, but the pace of expansion is slowing down, and the sub-AAA market is growing tremendously. There's a light at the end of this tunnel.


Anyhow, you could have twice as much music memory on the SNES, and it would make the thing you were struggling to do in 64k easy, but if you'd started with 128k as your constraint you would have filled that up quickly and be complaining that it's not 256k. Audio memory constraints became easy at ~20 megabytes, not 128k. If you want to have a better time working with 64k, maybe practice with only 32k for a while.

[tepples]

Do you know which console is even more powerful than the SNES or Genesis? The N64, PS1, Saturn, Dreamcast, PS2, GameCube, Xbox, PS3, Wii, Xbox 360, PS4, Wii U, Xbox One, and so on.

Then which unpatented and fully cracked console is more powerful than the Super NES or Genesis? Everything newer than N64 is still patented, which leaves developers open to suit over claims of the form "program storage medium for the computing machine of claim 1". I'm not sure whether the N64's CIC is cloned. Saturn disc protection was just recently figured out, and even then the details aren't public, nor can burners replicate the PS1 wobble track. And opening the Xbox One and Wii U to individual developers is also a very recent development (as in earlier this month).

Let's face it, we aren't programming for these things because they're the best thing on the market. It's probably at least 70% nostalgia, and 30% interest in working with limited, old hardware.

Part of that 30% is that that the graphics architecture is qualitatively different enough from OpenGL to be interesting. Otherwise, you could just stick with PC, which has lower entry cost. The other is they're cracked deeply enough for hobbyists to make original software and sell copies that work on unmodded systems.

Nowadays you can just have recorded music

That's been true even on handhelds since the Game Boy Advance.

If you want to have a better time working with 64k, maybe practice with only 32k for a while.

Case in point: the entire soundtrack of Haunted: Halloween '85 fits in 16K. At least on SPC700, you get to load in new samples and song data before each track.

[AWJ]

How about the SA-1 ??, it's simply a 65816 core or an improved/custom one ?? (i don't speak of DMA, and all others feature embedded, but only the CPU core) .

It's a totally standard 65816, with a custom memory system wrapped around it to let it run at 10MHz without needing excessively fast (for 1996) external ROM and RAM. Specifically, it's got separate busses to ROM and to RAM, the ROM bus is 16-bit with a prefetch queue for instructions, the RAM bus has a write buffer, and there's 2KB of fast internal RAM that can be used for direct page and the stack.

Thanks for infos
But what do you mean by "not excessively fast" ??,it adds some wait states when accesing rom or external RAM ??

Nobody's done hardware tests to suss out all the details, but the external memories apparently run at half the speed of the CPU (i.e. 5MHz) According to the manual, the following operations incur a wait state:

-When the SA-1 and the S-CPU both access ROM at the same time
-Reading data from external RAM or ROM
-Writing to external RAM "when the write buffer is full" (no explanation given as to what conditions can cause that state)
-Jumping/branching to an unaligned (odd) ROM address

Also, unlike the S-CPU, the SA-1 can execute instructions and DMA at the same time, but one or the other has to stall if both are accessing the same memory (there's a register bit that controls whether the CPU or DMA has priority)

No SNES emulator to my knowledge even attempts to emulate SA-1 memory contention. bsnes always runs it at the full 10MHz and lets DMA occur instantaneously.

[TOUKO]

Nobody's done hardware tests to suss out all the details, but the external memories apparently run at half the speed of the CPU (i.e. 5MHz) According to the manual, the following operations incur a wait state:

-When the SA-1 and the S-CPU both access ROM at the same time
-Reading data from external RAM or ROM
-Writing to external RAM "when the write buffer is full" (no explanation given as to what conditions can cause that state)
-Jumping/branching to an unaligned (odd) ROM address

Also, unlike the S-CPU, the SA-1 can execute instructions and DMA at the same time, but one or the other has to stall if both are accessing the same memory (there's a register bit that controls whether the CPU or DMA has priority)

No SNES emulator to my knowledge even attempts to emulate SA-1 memory contention. bsnes always runs it at the full 10MHz and lets DMA occur instantaneously.

Thanks,that are precious informations,it is surprising that nintendo can did that kind of stuffs,and take that ricoh version of the 816.

[Nicole]

My point was that the complaints that "if it only had more memory" were about the size of your goals.

Yeah, I certainly don't disagree with your point.

Then which unpatented and fully cracked console is more powerful than the Super NES or Genesis?

Well, PC, more or less, in any way that really matters to an indie dev. People don't develop for the SNES because it's the newest unencumbered thing out there.

[Sik]

When I was working on PS3, devs constantly complained about "only" having 256 MB of system memory, even though this is 8 times as much as the previous generation had.

To be fair, that has a lot to do with comparing it to the 360. More specifically: the 360 has 512MB of unified RAM (i.e. for both CPU and GPU), while the PS3 had 256MB of RAM and 256MB of VRAM. This was already annoying as the PS3 imposed a limit on how memory could be used, but to top it off streaming became way more commonplace in that generation: in the case of the 360 you just streamed into memory and the GPU could use it directly, while on the PS3 you had to stream it into RAM, then copy it into VRAM, and that temporary copy is effectively lost memory.

Reminds me of how people complain that the SNES can only use 16KB for sprites even though there's 64KB worth of video memory =O)

[93143]

This makes streaming harder (you need HDMA)

You don't need HDMA. Lots of people have done streaming engines where the S-CPU pokes in data manually.

In my personal opinion, you need HDMA to get good bandwidth on demand without crippling everything else that needs the S-CPU. But my definition of "good bandwidth" may differ from others'...

the external memories apparently run at half the speed of the CPU (i.e. 5MHz)

Does this imply that the bank byte is demuxed from the data lines, allowing the effective memory speed to double? I mean, on top of the doubling from it being 16-bit; 5.37 MHz is still pretty fast for a SNES cartridge, and the SA-1 seems to have been a little too popular in Japan for it to have required extra fast memory on top of the cost of the chip...

And how much would it have cost to put this sort of memory controller (without the fancy collision control, presumably) in the actual Super Famicom in 1990?

I'm just kinda wondering if Nintendo passed up a legitimate opportunity to nearly quadruple the speed of the S-CPU without changing the memory response time spec...

[AWJ]

the external memories apparently run at half the speed of the CPU (i.e. 5MHz)

Does this imply that the bank byte is demuxed from the data lines, allowing the effective memory speed to double?

No, it implies the SA-1 slows down to 5MHz whenever accessing external memory directly (not through the instruction prefetch queue or the RAM write buffer)

The S-CPU's external bus does demux the address and data lines (and has individual /RD and /WR strobes), but internally it still seems to use the standard 2-phase 65xx bus. I expect that would have required almost total redesign of the 65816 core to change.

ETA: Oh wait, I see what you're asking. Yeah, I expect "phi1" on the SA-1 is always half a 10MHz cycle and "phi2" is stretched to 3 half-cycles. That corresponds to how the S-CPU works (where phi1 is always 3 master clocks and phi2 is 3 or 5 clocks for fast/slow address ranges) If I'm right, SA-1 would have exactly the same memory speed requirements as a normal "fast" (3.58MHz) SNES cart.

[rainwarrior]

When I was working on PS3, devs constantly complained about "only" having 256 MB of system memory, even though this is 8 times as much as the previous generation had.

To be fair, that has a lot to do with comparing it to the 360.

It did, yes, if you were cross developing with it. I intentionally left that out because I was trying to avoid drawing out a 360 vs PS3 comparison in this thread, but you'd hear the same complaints if you were making an exclusive PS3 game (or if you were making an exclusive 360 game, or a Wii game, etc.). Nobody was ever satisfied with how much RAM they got. It's always full, no matter what you're doing. ;P 256 MB is a ridiculously large amount of memory for a game, but there's always a way to fill it.