Note this is part of a series: https://www.copetti.org/writings/consoles/
Architecture of the Playstation 2
41–50 of 59 posts
Re: Architecture of the Playstation 2
#42Earlier quoted context omitted.
Including the Xbox and GameCube. Well, the Xbox was built out of significantly more "general purpose" parts than the GameCube, but both still handily outperformed the PS2.
I'm really surprised how the Gamecube was able to run circles around the PS2, despite being cheaper and using just a standard CPU/GPU combo.
Of course Xbox and Gamecube also released at least a year later than the PS2, and graphics tech was moving fast at the time, so that was an advantage for them as well.
Re: Architecture of the Playstation 2
#43> Some time ago, it was discovered that the BIOS of this console could be upgraded using the Memory Card, this function was never used in practice, but neither removed (at during for most of the console’s lifespan). The author is correct that official uses for the MagicGate-encrypted system updates were few and far between, effectively "never", but there were a couple! There was a DVD Player installer/updater for ear…
Re: Architecture of the Playstation 2
#44Earlier quoted context omitted.
Including the Xbox and GameCube. Well, the Xbox was built out of significantly more "general purpose" parts than the GameCube, but both still handily outperformed the PS2.
I'm really surprised how the Gamecube was able to run circles around the PS2, despite being cheaper and using just a standard CPU/GPU combo.
Extra silly when you consider that the N64 had already been hamstrung by the decision to use <= 64MB cartridges over CDs.
Re: Architecture of the Playstation 2
#45Devwiki says it's a PPC 405 and this interview of Tom Reeves, IBM’s VP of semiconductor and technology services, says it's a PPC 440 which is more realistic for a 60 fps emulation of the first PlayStation.
Last question:
https://web.archive.org/web/20060806090854/http://www.reed-e...
Re: Architecture of the Playstation 2
#46Earlier quoted context omitted.
I bet they were writing Vector Unit assembly in Excel. The VLIW design meant that you literally packed 2 assembly instructions together into a 64-bit word. Each side had it's own subset of execution units it could utilize and would have it's own separate latency for each operation. So, to keep track of everything going on you pretty much had to write out two columns of code containing your own no-op notation to repre…
The story I heard was of a very, very heavily macro-based excel sheet that would automatically highlight possible problems including pipeline stalls in one of the VLIW units. Been looking for confirmation or just a screenshot of that monster since :D
I can't find any evidence of actual spreadsheets. They probably would have been setup by each programmer for their liking and maybe shared between programmers on the private sony sdk message board.
Or maybe I have an overactive imagination.
But I have heard is that the leaked Playstation 2 SDK from 2005 does contain a windows program called "VUEditor.exe". It's a custom IDE for writing VU assembly and it kind of acts more like a spreadsheet than a text editor, allowing the programmer to shift highlighted columns of instructions up and down.
It does show stalls and highlight issues. I couldn't find any screenshots, but one could find the sdk and try it out if they wanted.
Re: Architecture of the Playstation 2
#47I ran across an interesting factoid a while back where a line was drawn between the Amiga CD32 and PS2 - that somehow Sony picked up where Commodore left off but I’ve been unable to find a reference since and I’m certain at this stage I’ve got the names and dates mixed up ... anyone heard anything like this?
Re: Architecture of the Playstation 2
#48Earlier quoted context omitted.
I'm really surprised how the Gamecube was able to run circles around the PS2, despite being cheaper and using just a standard CPU/GPU combo.
I think the GameCube would have been much more of a success had Nintendo not opted to go with 1.8GB mini DVDs in an era where huge open world blockbuster games were filling up 9GB dual-layer DVDs on other consoles. Extra silly when you consider that the N64 had already been hamstrung by the decision to use <= 64MB cartridges over CDs.
After the CD-I debacle, Nintendo was not at all on-board with the idea of disc-based storage. One of those reasons was loading times.
Another was likely that they had concerns about games that were more 'FMV' than game; This really -was- a legit problem in the 90s. By keeping things constrained, it limits the temptation for a publisher to push out a crappy title filled with cutscenes.
Re: Architecture of the Playstation 2
#49Earlier quoted context omitted.
I bet they were writing Vector Unit assembly in Excel. The VLIW design meant that you literally packed 2 assembly instructions together into a 64-bit word. Each side had it's own subset of execution units it could utilize and would have it's own separate latency for each operation. So, to keep track of everything going on you pretty much had to write out two columns of code containing your own no-op notation to repre…
The N64 RSP is similar. I've been playing with a N64 RSP assembler that'll understand how instructions can dual issue, and give warnings when two instructions on the same line can't dual issue, so I can for sure see myself using excel back in the day to help manage the complexity.
Re: Architecture of the Playstation 2
#50I remember when Toshiba first showed us the R5900, which was a real screamer for its time. They couldn’t tell us at first whom they were designing it for. This was perhaps 2-3 years before the PS2 was publicly announced (at, IIRC, E3) and even before it had been discussed with any 3P developers. In fact the secrecy before it was released was insane. Toshiba and Sony kept their technology very close to their chest and…