Xbox Architecture
copetti.org
copetti.org
Aint that universal.
Or do you mean that the API only nice in theory, but is actually not nice in practice (lot of undocumented corner cases, or bugs, that games might rely on) ?
As for HLE based on the API it's definitely possible but there's probably tons of nasty corner cases and that's my theory on why it's never been done. That and the chance of games with their own proprietary APIs existing and thus they won't work with that solution.
Ultimately designing a circuit board layout is an optimization problem. You usually have some constraints, like how close chips can be before they start interfering with each other magnetically, where the I/O will be, and where you need holes to mount the board. Then you either try to be a pathing optimizer yourself or you run a program that will layout your board for you.
I'm not sure about the XBox, but game consoles sometimes have faster Memory->GPU pipelines than normal PCs to speed up render times, which might be why the GPU is the most central component.
Over time CPUs have integrated all those features on-die, resulting in today's SoC-like processors where the "chipset" is merely an I/O expander connected over a PCIe-like link.
Back in the years we're talking about, that would be AGP (https://en.m.wikipedia.org/wiki/Accelerated_Graphics_Port).
The only way to do this is to have one chip (It's always the GPU. The GPU needs more memory bandwidth) connected directly to the dram, and the second chip (CPU) has to send memory requests to the second chip.
Though, this console dates to a time when CPUs didn't typically have dram controllers onboard. PCs usually relied on a northbridge chip to have the dram controllers, along with the routing to all peripherals (PCI/AGP) and present a nice tidy Front-side-bus that the CPU understands. In the case of the xbox, the GPU is acting as a combined Northbridge/GPU (a design that was common at the time in low-cost desktops and laptops)
Unified memory has a large number of advantages for consoles. It lowers cost. It gets rid of copying delays between GPU and CPU memory and it allows the game developer to dynamically allocate memory to the GPU or CPU depending on their needs.
As I recall, the earliest Intel integrated graphics added almost nothing to the production cost of the chipset. The die needed a certain perimeter to support all the IO connections, and that left quite a bit of unused silicon in the middle. Putting GPU logic in that space was almost free (minus R&D), and only slightly increased the total pin count. Intel got to capture slightly more revenue per PC and deny a lot of revenue to competing chip companies making discrete GPUs.
The situation today is very different, with GPU and CPU on the same die and the GPU blocks taking up far more space than the CPU cores. The integrated GPU is an important part of the chip cost, and that means desktop processors often have worse (smaller) iGPUs than laptop chips.
It's a lot like what you see today with AMD's chiplets at 7nm connected to a central I/O die on 14nm. Just the classic systems were integrated at the board level instead of a special interposer.
EDIT: I wonder if the switch to serdes links instead of parallel buses (infinity fabric instead of hypertransport) is a large part of what made this idea useful again, reducing the number of off chip signals again for the CPU dies. I wonder if we'll therefore see a replacement for Intel's QPI if they switch to chiplets too.
I think Intel's trying to ensure they have the advanced packaging/interposer/bridge tech to handle wide parallel connections between chiplets. If it works out, they might even end up moving in the opposite direction—toward wider interconnects rather than narrower.
Wikichip [1] says there are two versions of infinity fabric (which is a super-set of HyperTransport), one optimised for on-package communication that is 32 bits wide, and one optimised for inter-socket communication that is 16bits wide.
I'm not a hardware person, just a software person who dabbles in hardware, so I don't know if the term "SerDes" strongly implies serial and AMD have misused it here, or if SerDes is generic enough to apply to any SERialisation/DESerialisation.
But still, I think you are on the right track. The investment and development into low power, high-speed, and low-latency on-package links is probably what has enabled chiplets to become relevant now.
Because multi-chip modules have always existed.
The primary reason for this design is that at current frequencies it is essentially impossible to manufacture the physical parallel interface with equal-enough wire lengths. Interestingly, memory interfaces (like DDR4) use opposite approach: the interface is still mostly parallel, but memory controller measures the delays and mismatches of the physical wires and compensates for that in its timing.
Really? That's crazy! I thought DDR was serial connections. In fact, I thought parallel connections had mostly gone the way of the dodo. Serial is just so much less complicated.
One fun thing was optimizing for the SPUs meant that your code was really cache coherent and usually saw significant gains on all platforms. Of course most people at that time wrote for PC+360 first and entered a world of pain when PS3 came along.
If there's one lesson to take away it's always build for your most constrained platforms first. There's still a few funky architectures out there(RPi I'm looking at you[1]) so it's always worth understanding where the hardware constraints in your system can come back to cause havok.
[1] https://www.raspberrypi.org/documentation/configuration/conf...
What do you mean by this?
Especially if the GPU already had custom silicon for it.
Whether it would be good engineering (cost, time to market, risks) is of course another issue.
It gets harder and harder to do such external muxing as the ram gets more and more complex. With multiple banks, row open delays, bursts and more complex signalling (fast and faster ual data rate at lower and lower voltages) it's near impossible to control modern DRAM without a proper controller.
And that controller has to live inside a single chip. It would be insanity to try and have two different dram controllers multiplexing the same DRAM chips.
I don't think thats true, in embedded architectures its not uncommon to have dual-port RAM.
I'm not aware of any designs which have large amounts of dual-port RAM as main system memory.
The only unusual thing here is that the GPU and Northbridge are the same chip.
The following generation though everything switched to more commodity hardware, with the PS4 and Xbox One using x86_64 processors and the Switch using an almost off-the-shelf SoC from nvidia.
EDIT: Gamecube was also PPC.
I can't parse this excerpt
* Some emulator do exists. The earlier attempts were just API translation layers that work a bit like wine: translate the function calls to native system APIs on windows. As time went, tricks and workarounds were piling up, especially as some games used lower level HW functionality (writing in registers, etc), which provided difficult to emulate, and game executables had to be patched, thus making the emulators a collection of special cases. Such emulators include Xenia, Cxbx (and derivatives such as shogun's version, dxbx, etc).
* More recently, efforts turned to low-level emulation, with complete emulation of the Xbox GPU, using a codebase derived from QEMU: XQEMU, and more recently XEMU (mborgeson's fork, focused on trying less-proven tricks and workarounds to maximize compatibility). Both are being developed in the open (XQEMU's development process might be slightly more open), and reverse-engineering is ongoing.
* There is also an ongoing effort to port ReactOS to both the Xbox and XQEMU (probably using the official nvidia NV2A driver): https://reactos.org/wiki/Install_ReactOS_on_Xbox
* Big names (among others) on the emulation scene: mborgeson, JayfoxRox, Espes, Shogun
* Bunnie Huang’s Hacking The Xbox was mentioned by another commenter, but 17 Mistakes Microsoft Made in the Xbox Security System is also an interesting read about working around the Xbox security mechanisms: https://xboxdevwiki.net/17_Mistakes_Microsoft_Made_in_the_Xb...
* I cannot stress enough how https://xboxdevwiki.net/ is a great resource for information. Other links: https://xqemu.com/ https://github.com/xqemu/xqemu/ https://xemu.app/ https://github.com/mborgerson/xemu/wiki#content-top https://shogun3d-cxbx.blogspot.com/
* There is a big discord community, some rooms are bridged with IRC on freenode, I also bridged #xqemu on Matrix: https://xboxdevwiki.net/Main_Page/Header
> Every game console since the first Atari was more or less designed to prevent the piracy of games and yet every single game console has been successfully modified to enable piracy. However, this trend has come to an end. Both the Xbox One and the PS4 have now been on the market for close to 6 years, without hackers being able to crack the system to enable piracy or cheating. This is the first time in history that game consoles have lasted this long without being cracked to enable piracy. In this talk, we will discuss how we achieved this for the Xbox One. We will first describe the Xbox security design goals and why it needs to guard against hardware attacks, followed by descriptions of the hardware and software architecture to keep the Xbox secure. This includes details about the custom SoC we built with AMD and how we addressed the fact that all data read from flash, the hard drive, and even DRAM cannot be trusted. We will also discuss the corresponding software changes we made to keep the system and the games secure.
Unlike past generations you can't just brute force it with hardware modifications either, the security is so deeply embedded in the SoC now that there's no way to touch it. Without a software exploit you're shit out of luck.
But I can say that I became disinterested in piracy when they made getting games more convenient than piracy. When they made using the hardware closer to its full potential part of the default experience. When they got the pricing right for these “premium” but pretty basic features. And of course, personally having the disposable income to afford the content because I would have never been a customer when I was pirating, only an unpaid evangelist of the franchise.
(Also xbox sales are often very good. I'm ok paying $10-20 (sometimes less!) for games).
I suppose it helps that my backlog is 6 years now; up until last week I was still playing games on 360/ps3.
games seems to loose value rapidly after they are released so some are very affordable.
https://support.spotify.com/us/using_spotify/features/listen...
I think this is most of the story.
I mean, it's fun to hack, but a lot of people's ideology about a lot of things go out the window as soon as they have a regular job and can afford to buy regular stuff and see these things as pretty much regular products and services.
Future generations of consoles made that default behavior, and games are released in multiple continents at the same time with their respective localization. American flagship games are now more appealing and engaging than their Japanese counterparts.
Its not just the money.
It's still fun to hack, by the way, I just have less time to do it.
In fact, if they're smart, they'll be fine with it, because it's a form of 'perfect price discrimination'.
That said, the question is to what extent piracy from other areas bleeds into the higher value markets. Which I believe does happens, ergo 'a crack is a crack is a crack' probably.
It's funny because if the cost of getting a 'hack' of a game literally entails buying a 'CD-ROM' and going through the pain of copying it like in the 'old days', which is a small pain but more than many want to bear, it puts a natural bound on the copying/hacking: it will happen a lot in poor countries, less so in rich countries.
But if a hack is 'discovered once', wherever, and then easily exploited everywhere ... not so good.
That's not true. Many people won’t pay for something if they can get it for free reasonably easy.