Team Xbox speculates on Xbox 2 CPU.

[Brimstone]

Interesting speculation, and for me as an AMD fan, good news. Would ensure AMD's survival over the foreseeable future.

Still, I don't quite believe this story. For one thing, using AMD64 tech would kill an UMA design stone dead. The built-in memory controller in the CPU isn't fast enough to feed a GPU more advanced than a GF4MX, and the hypertransport interface is also too slow and adds (probably too much) latency.

I'm still guessing it'll be a PPC chip in XB2.


*G*

I don't think they need to go unified .

But athlon 64 to the main ram

Athlon 64 via hypertansport to the graphics card (hypertransport shoudl be fast enough for that) THen the gpu to ram

Wouldn't that work fine ?

SiS is known for designing Rambus chipsets for the PC. Sony has chosen Rambus XDR for the PS3, and I won't be surprised to see Rambus XDR technology standards inside the X-Box 2. The Rambus XDR technology on paper looks good for a gaming console. If Microsoft could negotiate a good price with Samsung if they decide to make XDR, it could be a serious consideration. Samsung has licensed XDR, but have yet to put out a memory roadmap for it.

 

[akira888]

PS3 is not gonna use a multicore PPC, but well...

I thought the general consensus of the B3D console "community" was that the "PU"s in the patent were some type of PPC based design. Since IBM is the lead designer of the Blue Gene/Cell architecture, what else could they be?

Or do you have secret info you can't share...

 

[Paul]

I thought the general consensus of the B3D console "community" was that the "PU"s in the patent were some type of PPC based design. Since IBM is the lead designer of the Blue Gene/Cell architecture, what else could they be?

Widely concidered fact that the PU's are cut down PowerPC's.

 

[cthellis42]

I personally hope and pray Nintendo calls their next console "Starcube" like they were gonna do with GC. It's just such a cool name!

Nah, they're going with "DoGameaHedron."

 

[jvd]

SiS is known for designing Rambus chipsets for the PC. Sony has chosen Rambus XDR for the PS3, and I won't be surprised to see Rambus XDR technology standards inside the X-Box 2. The Rambus XDR technology on paper looks good for a gaming console. If Microsoft could negotiate a good price with Samsung if they decide to make XDR, it could be a serious consideration. Samsung has licensed XDR, but have yet to put out a memory roadmap for it.

Amd has a liscense to use rambus . So they could just do a new spin of the a64s with support for rambus

 

[Dio]

Uh, 6502, the torture... They all look easy when you learn 6502 first, then x86.

It was Z80 first, then 68k, then 6502. That accumulator-based architecture came as a real shock!

6502 was self-taught using a Commodore machine (was it a C16???) that had a built in debugger, by poking random values into memory, disassembling the opcodes, and seeing what they did. A weekend at my cousin's with not much but the C16 for company proved enough to get the job done.

I did ARM and 56001 (now that's REAL torture but helped a lot with my more recent 'asm's ) before x86, by then I could be up and running in a new asm in a couple of hours.

 

[Crazyace]

65816 was always wierd - having to set 8 and 16 bit mode for the registers and addressing banks...
56k was pretty normal for a dsp - try the newer ti chips or the phillips trimedia where you have to pipeline explicitly....

 

[MfA]

try the newer ti chips or the phillips trimedia where you have to pipeline explicitly....

As it should be, why would a developer want to waste perfectly good registers by allocating them to instructions which havent even finished Branch delay slots are a lot more fun than branch prediction too ... Ill decide if there is any usefull work to be done thank you.

 

[akira888]

What's interesting is that the 65816 (which is a 16-bit version of the 8-bit 6502 with block transfers and an attempt at register sanity) has a "6502 emulation mode" that runs exactly as a stock 6502 would. Unfortunately - many people used the unused opcode hex values to implement bizarre operations that weren't documented (and were certainly the result the ALU control unit spitting bizarre values). Needless to say, the 65816 didn't implement these, so much software wouldn't work...