Live data from Hacker News

Xbox Architecture

copetti.org

61–70 of 78 posts

Re: Xbox Architecture

#61
post #36

Earlier quoted context omitted.

Interestingly you see one of the major compelling reasons for the north bridge functionality to be on a separate chip. That large fixed area cost component (the pads have a lot analog components that don't shrink like logic does) can be manufactured on whatever tried and true older process node gets amazing yields for the area cost rather than the cost per gate (like you want your CPUs on). It's a lot like what you s…

Infinity fabric isn't serial. 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 misu…

Probably all modern fast interconnects work by interleaving some kind of "physical frames" (often bytes with some 8B10B encoding) across multiple distinct serial links that are synchronized as if these frames were bits of parallel interface.

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.

Re: Xbox Architecture

#62
> It is speculated that Microsoft may have left that code from prototype/debug units, so for the purposes of his research (possibly accidental, since this block exposes the types algorithms that Microsoft applied). In conclusion, this was considered garbage code [...]

I can't parse this excerpt

Re: Xbox Architecture

#63
A few tidbits not included in the article:

* 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

Re: Xbox Architecture

#64
post #62

> It is speculated that Microsoft may have left that code from prototype/debug units, so for the purposes of his research (possibly accidental, since this block exposes the types algorithms that Microsoft applied). In conclusion, this was considered garbage code [...] I can't parse this excerpt

Fixed, thanks

Re: Xbox Architecture

#65
post #58
post #18

Earlier quoted context omitted.

The xbox (like many consoles, n64, gamecube, xbox360, wii, wii u, xbox one, ps4, switch ps5, XSX) has unified memory, as in the CPU and GPU share the same sdram. 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 di…

Why would it be impossible to have >1 chip access the SDRAM? Like Amiga did. 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 works for the Amiga because the Amiga has simple DRAM.

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.

Re: Xbox Architecture

#66
post #18

Earlier quoted context omitted.

The xbox (like many consoles, n64, gamecube, xbox360, wii, wii u, xbox one, ps4, switch ps5, XSX) has unified memory, as in the CPU and GPU share the same sdram. 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 di…

> 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. I don't think thats true, in embedded architectures its not uncommon to have dual-port RAM.

Inside chips it's common to have dual port ram. But it's really expensive.

I'm not aware of any designs which have large amounts of dual-port RAM as main system memory.

Re: Xbox Architecture

#67
post #58
post #18

Earlier quoted context omitted.

The xbox (like many consoles, n64, gamecube, xbox360, wii, wii u, xbox one, ps4, switch ps5, XSX) has unified memory, as in the CPU and GPU share the same sdram. 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 di…

Why would it be impossible to have >1 chip access the SDRAM? Like Amiga did. 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.

The Amiga "chip" memory was actually quite slow to use, precisely due to it being accessed by both the CPU and chipset - the solution was to add "fast", CPU-only RAM. The address space was unified between "chip" and "fast" memory, but the underlying hardware arrangement was different.

Re: Xbox Architecture

#68
post #66

Earlier quoted context omitted.

> 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. I don't think thats true, in embedded architectures its not uncommon to have dual-port RAM.

Inside chips it's common to have dual port ram. But it's really expensive. I'm not aware of any designs which have large amounts of dual-port RAM as main system memory.

Fair enough, I should have been more precise. I wanted to point out that it is not a hard technical limitation, but should have added that in that specific use case it is economically unfeasible.

Re: Xbox Architecture

#69

For the Xbox 360, they ditched Intel and went for PowerPC. Microsoft then bought a bunch of PPC Mac Pros from Apple for development since they shared the same ISA :D

That entire generation of consoles, the Xbox 360, PS3 and Wii (and then arguably the Wii U) were all some form of PowerPC.

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.

Re: Xbox Architecture

#70
post #58
post #18

Earlier quoted context omitted.

The xbox (like many consoles, n64, gamecube, xbox360, wii, wii u, xbox one, ps4, switch ps5, XSX) has unified memory, as in the CPU and GPU share the same sdram. 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 di…

Why would it be impossible to have >1 chip access the SDRAM? Like Amiga did. 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.

Amiga worked exactly the same way. All memory access to the so called "Chip" ram had to go thru Agnus. CPU address lines didnt touch ram chips directly. CPU was just a passenger riding on the back of powerful GPU.

https://www.pmsoft.nl/amiga/A500-block-diagram.jpg

Post reply on HN