Live data from Hacker News

Xbox 360 Architecture

copetti.org

41–50 of 67 posts

Re: Xbox 360 Architecture

#41
post #27

Earlier quoted context omitted.

Is that a POWER thing or what was the main cause?

As said in other comments, not a power thing. Example, the Nintendo Wii U chose to use 3 1.2ghz (iirc) Out of Order execution cpu's that were more like a PC than the cores in the Xbox 360 even though sounding similar in instruction set and composition. This lead the Wii U to be able to do things like Run Mass Effect 3 and Deus Ex better (arguably) than the PS3 and 360 most of the time. The Wii U was probably the bett…

You're comparing the 2012 Wii U against 2005/2006 360/PS3. The PPE was indeed terrible but it's not clear that IBM had anything better available at that time.

Re: Xbox 360 Architecture

#42
post #21

Earlier quoted context omitted.

The "compiler will solve everything" theory seemed to last quite a long time, I first heard it with the Itanium and again with these pipelined CPUs. Narrator: It didn't solve anything.

This is speculation, but: optimizing compilers are pretty good, right? On x86 at least. Perhaps they do a good job on popular platforms like x86, because we can encode decades of experience, but not so great on brand new ones.

Nah, in-order just can't be fixed by any compiler.

Re: Xbox 360 Architecture

#43

It is kind of funny that the 3 major consoles of this generation used PowerPC, followed by the next generation mostly using AMD. Do the major manufacturers just copy each other?

More like they had similar requirements and IBM was the only company interested in building high-performance custom SoCs at that time.

Re: Xbox 360 Architecture

#44

Earlier quoted context omitted.

This is speculation, but: optimizing compilers are pretty good, right? On x86 at least. Perhaps they do a good job on popular platforms like x86, because we can encode decades of experience, but not so great on brand new ones.

One thing that Intel and AMD do better than any other player in the industry is branch prediction. An absolutely stupifying amount of die area is dedicated to it on x86. Combining this with massive speculative execution resources and you can get decent ILP even out of code that's ridiculously hostile to ILP. Our modern CPU cores have hundreds of instructions in flight at any one moment because of the depth of OoO exe…

> An absolutely stupifying amount of die area is dedicated to it on x86.

Yep. For example, on this die shot of a Skylake-X core,[0] you can see the branch predictor is about the same area as a single vector execution port (about 8% of the non-cache area).

[0]: https://twitter.com/GPUsAreMagic/status/1256866465577394181

Re: Xbox 360 Architecture

#45
post #41
post #27

Earlier quoted context omitted.

As said in other comments, not a power thing. Example, the Nintendo Wii U chose to use 3 1.2ghz (iirc) Out of Order execution cpu's that were more like a PC than the cores in the Xbox 360 even though sounding similar in instruction set and composition. This lead the Wii U to be able to do things like Run Mass Effect 3 and Deus Ex better (arguably) than the PS3 and 360 most of the time. The Wii U was probably the bett…

You're comparing the 2012 Wii U against 2005/2006 360/PS3. The PPE was indeed terrible but it's not clear that IBM had anything better available at that time.

The Wii U also needed to be backwards-compatible with the Wii, which used the bespoke paired singles and locked cache line features of the GameCube's PPC 750 derivative. This almost certainly locked them out of newer PowerPC designs without more engineering work than Nintendo would be willing to put into its systems.

For context, Nintendo has always been weirdly quirky and low-buck when it comes to core silicon engineering. The Switch is a Tegra X1 in a trenchcoat, the SNES used a 65C816 at about half the clockspeed it needed to be[0] and had half the VRAM removed at the last minute, and the NES stole[1] the 6502 masks so they didn't have to pay MOS for legit chips. All of those design decisions were made purely to improve margins and genuinely constrained game developers in the process. "Lateral thinking with withered technology" is kind of just their thing.

At least now they're 100% on board with a silicon vendor with a sane roadmap, so they'll at least have a steady supply of backwards-compatible last-gen chips to repackage.

[0] At least it wasn't as slow as the Apple IIgs they pulled it from

[1] Technically legal as IC maskwork rights did not exist yet. This is also why decimal mode was removed - it was literally the only thing MOS had a patent on in the 6502 design.

Re: Xbox 360 Architecture

#46
I finally got through this, coming in and out throughout the work day. I owned 3 360's over the lifespan of the console (a launch version, a replacement after it red ringed a few years later, and then a slim), and I never even brushed up against the cracking or homebrew scene. Very interesting stuff!

I am curious though, other that one brief mention, why didn't you touch on the early hardware reliability issues at all?

Also, either the site has been swarmed and its down right now, or the links in footers 117, 118, and 119 are bad.

Re: Xbox 360 Architecture

#47
post #41

Earlier quoted context omitted.

You're comparing the 2012 Wii U against 2005/2006 360/PS3. The PPE was indeed terrible but it's not clear that IBM had anything better available at that time.

The Wii U also needed to be backwards-compatible with the Wii, which used the bespoke paired singles and locked cache line features of the GameCube's PPC 750 derivative. This almost certainly locked them out of newer PowerPC designs without more engineering work than Nintendo would be willing to put into its systems. For context, Nintendo has always been weirdly quirky and low-buck when it comes to core silicon engin…

Ricoh not Nintendo ripped off MOS IP.

Re: Xbox 360 Architecture

#48
I'm thankful for the people that did the work of reverse engineering/modding the Xbox and Xbox 360, without them I'm not sure if I would have gotten into programming as early as I did, around 13 years old. I got started with using simple modding tools for Halo 2 on Xbox then moved on to writing code for modding COD MW2 on the Xbox 360. Good times, it lead me away from spending all my free time gaming for fun and into coding for fun.

Re: Xbox 360 Architecture

#49
post #41

Earlier quoted context omitted.

You're comparing the 2012 Wii U against 2005/2006 360/PS3. The PPE was indeed terrible but it's not clear that IBM had anything better available at that time.

The Wii U also needed to be backwards-compatible with the Wii, which used the bespoke paired singles and locked cache line features of the GameCube's PPC 750 derivative. This almost certainly locked them out of newer PowerPC designs without more engineering work than Nintendo would be willing to put into its systems. For context, Nintendo has always been weirdly quirky and low-buck when it comes to core silicon engin…

>had half the VRAM removed at the last minute

I've never heard anything suggesting that video RAM was removed. AFAIK, the SNES was planned to have only 8KB of main RAM, which was increased to 128KB by release. I think any support for 128KB VRAM was for future proofing, like if the SNES's hardware was reused for arcade systems, or something.

Source: https://www-chrismcovell-com.translate.goog/secret/sp_sfcpro...

The Genesis's video chip can support 128KB video RAM as well, which besides allowing a larger variety of tiles on screen and doubles DMA bandwidth. It was used in the System C2 arcade board. The Genesis was originally designed to use 64KB video RAM, but after hearing about the SNES, support for 128KB was added. Then they decided that the extra RAM didn't make enough of a difference to justify the cost, so they left it at 64KB.

Source: https://readonlymemory.vg/shop/book/sega-mega-drive-genesis-...

Re: Xbox 360 Architecture

#50
post #46

I finally got through this, coming in and out throughout the work day. I owned 3 360's over the lifespan of the console (a launch version, a replacement after it red ringed a few years later, and then a slim), and I never even brushed up against the cracking or homebrew scene. Very interesting stuff! I am curious though, other that one brief mention, why didn't you touch on the early hardware reliability issues at al…

> I am curious though, other that one brief mention, why didn't you touch on the early hardware reliability issues at all?

I guess because they likely didn't have anything to do with the architecture? Or were there really reliability issues that were a result of the architecture, instead of physical/electrical hardware issues?

Post reply on HN