Assuming this existed would be you buy it?

[Morphv2]

Seriously, the Super Nintendo had a 3 MHz 16-bit upgrade of an 8-bit CPU but the system successfully competed with the Genesis' powerful Motorola 68k (a 32bit CPU clocked at 8 MHz). Former NES developers had a decent amount of knowledge of the 6502, and the system's design with its focus on the more powerful GPU allowed to make up for the difference

You are half right and half wrong. Yes, the Motorola 68000 was a 32-bit CPU INTERNALLY, but all of its bus interfaces and external access registers are 16-bit. Not only that, but the 68k only has '22-bit' capable cache displacement, so it really isn't a 32-bit chip. The 68020 was a full 32-bit chip because it increased the cache layout and reorganized it, and it was full 32-bit bus compliant.

The SNES CPU isn't as weak as you think. Although it is indeed just a 16-bit update (as such is the 68k compared to the 6800), Nintendo stressed powerful integer arithmatic to compensate for lacking feature set. Besides, what the SNES could do at 3.58MHz, the Genesis was struggling to do at 7.61MHz. The 68k was a more all around chip, but relied on clockspeed to compensate for lack of raw arithmatic performance, which the Ricoh 5A22 could do but at half the clock rate.


Also, funny thing, the Xbox CPU is really a Pentium III with half the cache disabled. It still has the same associativity and bus speed, but half of the cache is just like 'lurr lurr lurr' and either isn't working (on early models) or isn't even there (on the later ones).

[Ex-Cyber]

I believe the clock ceiling for SuperH's SH4's is 400MHz (300 by Hitachi), so at 500MHz you'd be looking at SH5's

As far as I know, SH5 never actually went to mass production, unless it was specifically for certain customers. I've heard of eval boards (the SuperH Linux guys evidently got one), but I've never seen info on actually ordering an SH-5 in any way. Renesas is however working on the "SH-4A" which is a retooled SH-4 core that is slated to run at up to 600MHz.

Yes, the Motorola 68000 was a 32-bit CPU INTERNALLY, but all of its bus interfaces and external access registers are 16-bit.

Much the same is true of the "16-bit" 65816 (8-bit data bus), so it's only fair to call the 68K "32-bit" in that context.

the 68k only has '22-bit' capable cache displacement

The 68000 doesn't even have cache, so I have no idea what you're talking about. Where is this described in the manual?

The SNES CPU isn't as weak as you think. Although it is indeed just a 16-bit update (as such is the 68k compared to the 6800)

68000 has a mode to access 6800-compatible peripheral chips, but apart from that the architecture is extremely different. The 6502/65816 relationship is much, much closer than 6800/68000. Actually, the 6800 more closely resembles the 6502.

Nintendo stressed powerful integer arithmatic to compensate for lacking feature set. Besides, what the SNES could do at 3.58MHz, the Genesis was struggling to do at 7.61MHz.

65xx takes fewer cycles to fetch from memory - that's the only solid performance advantage I know of, and that was counteracted to a degree by the use of 200ns ROM on many (if not most) SNES games. For anything other than very basic operations on 8-bit values, 68K is effectively stronger - it can fetch 16 bits at once and has way more registers so it doesn't have to be done as often in a complex operation. It should tell you something that there's a bunch of SNES games that use on-cart DSPs to do heavy math (Pilotwings, Super Mario Kart, Top Gear 3000, Ballz, et. al.), while Genesis games don't use similar chips.

[Morphv2]

*strikes himself*

I was referring to the 68k arithmatic units, not cache (and it's actually 20-bit ALU's, not 22). I was reading on the 603e a few hours before so I had cache on the mind. The 68k actually supports off-die cache, but I don't think it was ever used outside of high end Amigas.

Last I heard, the SH5 was 'in-silicon' a long time ago. Although (now that you mention it) I cannot seem to find any particular hardware running off of the platform, I am nearly of absolute certainty that the SH5 is in production/use. Perhaps under a new name, I do not know. The SH4A is a new design, and wasn't around before 2005~, so it would not have applied either way (although I did not know that they scaled that high). Would I buy a 500MHz SH4A? Depends on how much data it can crunch.

Also, not entirely. The Genesis utilizes it's 68k in 8-bit data bus configuration. Maximum, it had a 16-bit bus, but on the Genesis it ran in 8-bit in order to achieve compatibility with the onboard Z80 (restricted to 8-bit) and the memory. Therefore, both chips are limited to 8-bit prefetch.

[Ex-Cyber]

I was referring to the 68k arithmatic units, not cache (and it's actually 20-bit ALU's, not 22). I was reading on the 603e a few hours before so I had cache on the mind. The 68k actually supports off-die cache, but I don't think it was ever used outside of high end Amigas.

Yeah, the 68K supports all kinds of memory configurations via /DTACK, the function pins, etc. Anyway, what I heard was that the ALU is physically 16-bit, but in any case it's microcoded to do 32-bit operations, so it doesn't really make much difference. The most important thing is that the registers are 32-bit, which means that a 32-bit operation can be performed without extra memory accesses.

Last I heard, the SH5 was 'in-silicon' a long time ago. Although (now that you mention it) I cannot seem to find any particular hardware running off of the platform, I am nearly of absolute certainty that the SH5 is in production/use. Perhaps under a new name, I do not know.

It definitely did go to silicon at some point (otherwise the SH-Linux guys wouldn't have had the eval board to port to), but I think it may have just been preproduction/prototype silicon considering that I can't find any part number info for an SH-5. Renesas licenses the core, so it might be hiding in ASSP type chips or something.

on the Genesis it ran in 8-bit in order to achieve compatibility with the onboard Z80 (restricted to 8-bit) and the memory. Therefore, both chips are limited to 8-bit prefetch.

I don't know where you got this idea, but it's not true. The 68K in Genesis does use 16-bit mode. Z80/68K communication is routed through another chip, so they don't share a data bus.

[Morphv2]

Touche.

[Eckostyle]

whatever. the core of every console is the CPU, and thus the most important component. RAM, GPU and all that are very important factors of a system.

Yeah, cause things like new/fun games to enjoy the system with, an innovative new controller to play the system with, active first and third party support to buy mroe games for the system with, and a broadband enabled network to conviently play with others are all secondary to that.

[Morphv2]

The CPU isn't necessarily the 'brains' of a computational device anymore. Both ATI and nVidia (with their R600 & G80 GPU's respectably) can do massive amounts of superscalar math on their GPU's, to the point where nVidia has released high performance machines utilizing G80's as pure floating point crunchers, and F@H being capable or running on just the GPU of a x1k/x2k series Radeon.

[DaMadFiddler]

Last I heard, the SH5 was 'in-silicon' a long time ago. Although (now that you mention it) I cannot seem to find any particular hardware running off of the platform, I am nearly of absolute certainty that the SH5 is in production/use. Perhaps under a new name, I do not know.

It definitely did go to silicon at some point (otherwise the SH-Linux guys wouldn't have had the eval board to port to), but I think it may have just been preproduction/prototype silicon considering that I can't find any part number info for an SH-5. Renesas licenses the core, so it might be hiding in ASSP type chips or something.

It may well be one of those cases like Palm OS 6, where the specifications and reference versions were completed a long time ago, but nobody actually licensed it for use in a retail product.

[Chaniyth]

700MHz just isn't ample for a next-gen system, and that's what people are gonna want... CPU power.

Bullshit.

There is a tiny segment of the market that's even aware of things like CPUs, RAM, clock speeds, polygons, or all the other voodoo that goes into a games machine. Really tiny.

Nobody else cares about CPU power. They don't care about RAM, they don't care about texture fillrate, or how many FLOPs the thing can do, or any of that other crap. None of it's even slightly relevant. It's basically just a my-xxx-is-bigger-than-yours contest. Teenage boy stuff.

In terms of graphics, extra CPU power buys you exactly nothing. You can inch forward a fraction closer to the ultimate goal of photorealism, but we're still so far away that the jump from, say, the Xbox to the Xbox 360 is hard to notice. Most people won't notice it.

In terms of gameplay, extra CPU power usually buys you nothing. Most of the games I've seen that use lots of CPU power to drive gameplay were PC games, and just don't work on games consoles anyway. Face it - developers have never used extra CPU power to improve AI, or to make the game more immersive. They've thrown the whole lot at graphics, simply because you can't take screenshots of AI, and you can't release trailers showing off immersion.

So why, exactly, would anyone want to buy one of these "next generation" games consoles?

I dunno dude, I can tell the difference right off the bat from Xbox and Xbox 360 when it comes to the graphics department. Graphics are nice, but it really truely is the gameplay that matters. You can have the best state of the art looking game, but if it's lacking the gameplay department it isn't worth anything. Yes, i'm a true gamer!

As for PC's (x86 & x86-64)... they require a lot of CPU power for the simple fact that A) PC's are not designed for games and B) Windows is a sloppy OS, not really well designed for the x86 architecture or hardware. A great example of this are Amiga which has Amiga OS; made SPECIFICALLY for the hardware, and Acorn which has RISC OS; once again made SPECIFICALLY for the hardware, both of those systems simply fly, due to not only custom chips, but also their OS!

Windows is only popular because game devvers chose to code for it. The fact is, there ARE much better solutions out there besides x86 & x86-64 arch CPU's and Windows, it's just that people are too blind to see the truth.

What x86 needs is an OS written entirely in ASM; there is one called MenuetOS, but it's more of a tech demo than an OS at this point and time. A pure ASM OS for x86 would simply fly simply because it is talking directly to the hardware instead of being translated.

[Ex-Cyber]

A great example of this are Amiga which has Amiga OS; made SPECIFICALLY for the hardware, and Acorn which has RISC OS; once again made SPECIFICALLY for the hardware, both of those systems simply fly, due to not only custom chips, but also their OS!

I think you're overestimating the impact of the OS itself. There is clearly an effect, but in a modern context I think it's dwarfed by the problems that arise from apps/games themselves. Also, some of AmigaOS (specifically AmigaDOS) was licensed from another company and was not written specifically for Amiga.

Windows is only popular because game devvers chose to code for it.

Windows was popular well before game developers began to embrace it; they had to essentially be dragged kicking and screaming away from DOS. DirectX only really caught on in late 1997 or so - games as late as Tomb Raider and Quake were still developed for DOS. Windows' popularity came from other factors, and games largely got caught up in that web.

What x86 needs is an OS written entirely in ASM; there is one called MenuetOS, but it's more of a tech demo than an OS at this point and time. A pure ASM OS for x86 would simply fly simply because it is talking directly to the hardware instead of being translated.

I'm not sure what you mean by "translated"; the only translation relevant to an ASM/HLL comparison would occur at compile time, not while the program is running. The performance hit is nothing like running under an emulator, which is what your statement seems to suggest. Surely some tasks can be made substantially faster by writing them in hand-optimized assembly language, but the overall architecture of the OS is a bigger issue, and a lot of that stems from the fact that you really can't have apps talking "directly" to the hardware (as many did on Amiga) on a modern PC because as an application author, you don't really know what the hardware is to begin with. That said, I do think we could stand to have a "thinner" OS designed around a single-user experience; it seems that the mainstream operating systems are designed around the concept of a mainframe that happens to have a high-bandwidth connection to a single terminal, rather than really being designed for a personal computer.

[HomerCIDAL]

Too many quotes and too many people full of themselves and the "knowledge" they possess...please!!!

The real bottom line is the software. If Sega released a machine and made their titles exclusive to that machine, I would absolutely buy it. These games would have to be better than the last Sega game for the PS3/Xbox360, but it could happen given the right person at the helm...(possibly Yuji Naka, Yu Suzuki, etc...)