6 ms·

Among the intended audience, it likely is. I think this article is here to equally amuse and traumatize folks familiar with the system. The Emotion Engine (CP

Among the intended audience, it likely is. I think this article is here to equally amuse and traumatize folks familiar with the system. The Emotion Engine (CPU) to GS (GPU) link was what made the PS2 so impressive for the time, but it also made it somewhat hard to code for and immensely hard to emulate. If I recall correctly, the N64 has something like 4x the memory bandwidth (shared) of the PS1, and the PS2 had roughly 6x (3GB/s) the system bandwidth of the N64. However, the PS2's GS RAM clocked in at 48GB/s, more than the external memory bandwidth of the Cell (~25GB/s), which meant that PS3 emulation of PS2 games was actually done with embedded PS2 hardware. It was a bonkers machine. I don't think workstation GPU bandwidth created 50GB/s for another 5-6 years. That said, it was an ultra simple pipeline with 4MB of RAM and insane DMA requirements, which actually got crazier with the Cell in the PS3. I was at Sony (in another division) in that era. It was a wild time for hardware tinkering and low level software.

djtango 2y ago
Thanks for sharing! Back then the appeal of console games to me were that beyond a convenient factor, they were also very specialised hardware for one task - running games. I remember playing FF12 (IZJS) on a laptop in 2012 and it ran very stable granted that was 6 years post release but by then had the emulator issues been fully solved? Re. Wild time for low level programming I remember hearing that Crash Bandicoot had to duck down into MIPS to eke out every extra bit of performance in the PS1.
- fmbb 2y ago
  Pretty sure all 3D PS1 games tapped into assembly for performance. The most “famous” thing about Crash programming is probably that it’s all in lisp, with inline assembly.
  - wk_end 2y ago
    I don’t think either of these things are true. By the mid-90s, C compilers were good enough - and CPUs were amenable enough to C - that assembly was only really beneficial in the most extreme of cases. Sony designed the Playstation from the jump to be a 3D machine programmable in C - they were even initially reluctant to allow any bit-bashing whatsoever, preferring devs used SDKs to facilitate future backwards compatibility. No doubt some - even many - PS1 games dropped down into assembly to squeeze out more perf, but I doubt it’s anything like “all”. As for Lisp, Crash used a Lisp-like language, “GOOL”, for scripting, but the bulk of the game would’ve been native code. It was with Jak & Daxter that they really started writing the game primarily in a Lisp (GOAL, GOOL’s successor).
  - boricj 2y ago
    Definitely not. I'm reverse-engineering Tenchu: Stealth Assassins and the original Japanese release's game code is written entirely in C as far as I can tell. It does use the Psy-Q SDK which contains assembly, but it's not something that the game developers have written.
  - dagmx 2y ago
    Both PS1 and N64 games were beyond the generation where direct assembly was required to achieve necessary performance. Compilers were good enough by that point in time for the vast majority of games.
  - mypalmike 2y ago
    Most games were primarily C. 3D performance came from the graphics hardware, which had straightforward C APIs and dedicated texture RAM. The machine lacked a floating point processor, so I think we wrote some fixed point math routines in assembly, but that's basically it.
  - pjmlp 2y ago
    PS1 is famous among game developers for being the first games console for the home market with a C SDK, instead of only Assembly as programming option. All games tap into Assembly, in some form or the other, even nowadays.
- 2600 2y ago
  I heard something similar with Jak and Daxter, where they took advantage of the embedded PS1 hardware on the PS2 to scrape together some extra performance. I very much enjoyed this video that Ars Technica did with Andy Gavin on the development of Crash Bandicoot: https://www.youtube.com/watch?v=izxXGuVL21o https://www.youtube.com/watch?v=izxXGuVL21o
  - midnightclubbed 2y ago
    Most PS2 games used the PS1 hardware for audio/sfx so you freed the main CPU for rendering/gameplay. I believe Gran Tourismo 3 used the ps1 hardware for everything except rendering, which was the kind of nuts thing you could do if your games were single platform and with huge budget.
- heraldgeezer 2y ago
  Would programmers now be able to make God of War 2, FF12, Jak 2&3 and Ratchet and Clank 3&Deadlocked? PS2, slim especially, is an incredible machine. Scale the games up to 1080p or 1440/4k and they look great still.
dietrichepp 2y ago
It’s hard to compare memory bandwidth of these systems because of the various differences (e.g. different RAM types). I know that the theoretical RAM bandwidth for the N64 is way higher than what you can practically achieve under typical conditions.
- chaboud 2y ago
  I totally agree, except when it comes to emulation. It is immensely hard to real-time emulate if some facet of your host hardware isn’t at least a little bit faster than the corresponding element in the emulated system. Then you have to lift the abstraction and often find that the rest of the system reflects this specificity. At my last job, we had ASICs that allowed for single-sample audio latency with basic mixing/accumulation functions for pulling channels of audio off of a bus. It would have been tragically expensive to reproduce that in software, and the required hardware to support a pure software version of that would have been ridiculous. We ended up launching a new platform with a different underlying architecture that made very different choices.
forgotpwd16 2y ago
PS2 compatibility on PS3 went through 3 phases. Launch models had EE+GS+RDRAM (full PS2 hardware), just after had only GS, and finally emulation was done entirely in software. Using a CFW can utilize the latest method to play most (ISO backed-up) PS2 games.
- Cloudef 2y ago
  Unfortunately the PS2 emulation on PS3 left a lot to be desired
- jonny_eh 2y ago
  > Using a CFW can utilize the latest method to play most (ISO backed-up) PS2 games Can it not use the first method if the hardware is available?
  - forgotpwd16 2y ago
    Sure and actually if available that is the default when mounting ISO. Just saying essentially every PS3 can emulate PS2 games. Not only those with (full or partial) PS2 hardware. Worth mentioning PSN classics (or converted games) utilize software emulation in every PS3.
    - to11mtm 2y ago
      Huh, TIL! (I never had a PS3, AFAIR my PSP just downclocked it's CPU, I remember battery life playing classics was awesome...)
deaddodo 2y ago
> However, the PS2's GS RAM clocked in at 48GB/s, more than the external memory bandwidth of the Cell (~25GB/s), which meant that PS3 emulation of PS2 games was actually done with embedded PS2 hardware. That's kinda overselling it, honestly. When you're talking about the GIF, only the VU1's vertex pipeline was able to achieve this speed directly. PATH2/PATH3 used the commodity RDRAM's bus (unless you utilized MFIFO to mirror a small portion of that to the buffer, which was much more difficult and underutilized than otherwise since it was likely to stall the other pipelines); the exact same bus Pentium 4's would use a few months after the PS2's initial launch (3.2-6.4GB/s). It's more akin to a (very large) 4M chip cache, than proper RAM/VRAM. As to the PS3 being half that, that's more a design decision of the PS3. They built the machine around a universal bus (XDR) versus using bespoke interconnects. If you look at the Xbox 360, they designed a chip hierarchy similar to the PS2 architecture; with their 10MB EDRAM (at 64GB/s) for GPU specific operations. As to those speeds being unique. That bandwidth was made possible via eDRAM (on-chip memory). Other bespoke designs utilized eDRAM, and the POWER4 (released around the same time) had per-chip 1.5M L2 cache running at over double that bandwidth (100GB/s). It also was able to communicate chip-to-chip (up to 4x4 SMP) at 40GB/s and communicate with it's L3 at 44GB/s (both, off-chip buses). So other hardware was definitely achieving similar to and greater bandwidths, it just wasn't happening on home PCs.
- twoodfin 2y ago
  Growing up with the tech press in this era, “commodity RDRAM” is a funny phrase to read! As I recall, the partnership between Intel and Rambus was pilloried as an attempt to re-proprieterize the PC RAM interface in a similar vein to IBM’s microchannel bus.
  - deaddodo 2y ago
    "Commodity" meaning "something that could be bought at the store".
    - twoodfin 2y ago
      From the Rambus store!
pjmlp 2y ago
Most third parties weren't able to explore the PS2 properly, until Sony had to go through a revamp of their SDK, and collaborated with Gran Turism folks to show what was actually possible.
- xgkickt 2y ago
  Not sure what you mean. The entire system was available to everyone day 1 through the manuals. The introduction of the VLC VU assembler made VU development easier (single instruction stream, automatic register allocation). PATH3 texture uploads maybe?
  - pjmlp 2y ago
    Just because someone gets a driver license, doesn't mean they are fit to drive on F1 GP. Likewise most game developers weren't fit to drive PS2 without additional help from Sony.

djtango 2y ago

Thanks for sharing! Back then the appeal of console games to me were that beyond a convenient factor, they were also very specialised hardware for one task - running games. I remember playing FF12 (IZJS) on a laptop in 2012 and it ran very stable granted that was 6 years post release but by then had the emulator issues been fully solved? Re. Wild time for low level programming I remember hearing that Crash Bandicoot had to duck down into MIPS to eke out every extra bit of performance in the PS1.

fmbb 2y ago
Pretty sure all 3D PS1 games tapped into assembly for performance. The most “famous” thing about Crash programming is probably that it’s all in lisp, with inline assembly.
- wk_end 2y ago
  I don’t think either of these things are true. By the mid-90s, C compilers were good enough - and CPUs were amenable enough to C - that assembly was only really beneficial in the most extreme of cases. Sony designed the Playstation from the jump to be a 3D machine programmable in C - they were even initially reluctant to allow any bit-bashing whatsoever, preferring devs used SDKs to facilitate future backwards compatibility. No doubt some - even many - PS1 games dropped down into assembly to squeeze out more perf, but I doubt it’s anything like “all”. As for Lisp, Crash used a Lisp-like language, “GOOL”, for scripting, but the bulk of the game would’ve been native code. It was with Jak & Daxter that they really started writing the game primarily in a Lisp (GOAL, GOOL’s successor).
- boricj 2y ago
  Definitely not. I'm reverse-engineering Tenchu: Stealth Assassins and the original Japanese release's game code is written entirely in C as far as I can tell. It does use the Psy-Q SDK which contains assembly, but it's not something that the game developers have written.
- dagmx 2y ago
  Both PS1 and N64 games were beyond the generation where direct assembly was required to achieve necessary performance. Compilers were good enough by that point in time for the vast majority of games.
- mypalmike 2y ago
  Most games were primarily C. 3D performance came from the graphics hardware, which had straightforward C APIs and dedicated texture RAM. The machine lacked a floating point processor, so I think we wrote some fixed point math routines in assembly, but that's basically it.
- pjmlp 2y ago
  PS1 is famous among game developers for being the first games console for the home market with a C SDK, instead of only Assembly as programming option. All games tap into Assembly, in some form or the other, even nowadays.
2600 2y ago
I heard something similar with Jak and Daxter, where they took advantage of the embedded PS1 hardware on the PS2 to scrape together some extra performance. I very much enjoyed this video that Ars Technica did with Andy Gavin on the development of Crash Bandicoot: https://www.youtube.com/watch?v=izxXGuVL21o https://www.youtube.com/watch?v=izxXGuVL21o
- midnightclubbed 2y ago
  Most PS2 games used the PS1 hardware for audio/sfx so you freed the main CPU for rendering/gameplay. I believe Gran Tourismo 3 used the ps1 hardware for everything except rendering, which was the kind of nuts thing you could do if your games were single platform and with huge budget.
heraldgeezer 2y ago
Would programmers now be able to make God of War 2, FF12, Jak 2&3 and Ratchet and Clank 3&Deadlocked? PS2, slim especially, is an incredible machine. Scale the games up to 1080p or 1440/4k and they look great still.

dietrichepp 2y ago

It’s hard to compare memory bandwidth of these systems because of the various differences (e.g. different RAM types). I know that the theoretical RAM bandwidth for the N64 is way higher than what you can practically achieve under typical conditions.

chaboud 2y ago
I totally agree, except when it comes to emulation. It is immensely hard to real-time emulate if some facet of your host hardware isn’t at least a little bit faster than the corresponding element in the emulated system. Then you have to lift the abstraction and often find that the rest of the system reflects this specificity. At my last job, we had ASICs that allowed for single-sample audio latency with basic mixing/accumulation functions for pulling channels of audio off of a bus. It would have been tragically expensive to reproduce that in software, and the required hardware to support a pure software version of that would have been ridiculous. We ended up launching a new platform with a different underlying architecture that made very different choices.

forgotpwd16 2y ago

PS2 compatibility on PS3 went through 3 phases. Launch models had EE+GS+RDRAM (full PS2 hardware), just after had only GS, and finally emulation was done entirely in software. Using a CFW can utilize the latest method to play most (ISO backed-up) PS2 games.

Cloudef 2y ago
Unfortunately the PS2 emulation on PS3 left a lot to be desired
jonny_eh 2y ago
> Using a CFW can utilize the latest method to play most (ISO backed-up) PS2 games Can it not use the first method if the hardware is available?
- forgotpwd16 2y ago
  Sure and actually if available that is the default when mounting ISO. Just saying essentially every PS3 can emulate PS2 games. Not only those with (full or partial) PS2 hardware. Worth mentioning PSN classics (or converted games) utilize software emulation in every PS3.
  - to11mtm 2y ago
    Huh, TIL! (I never had a PS3, AFAIR my PSP just downclocked it's CPU, I remember battery life playing classics was awesome...)

deaddodo 2y ago

> However, the PS2's GS RAM clocked in at 48GB/s, more than the external memory bandwidth of the Cell (~25GB/s), which meant that PS3 emulation of PS2 games was actually done with embedded PS2 hardware. That's kinda overselling it, honestly. When you're talking about the GIF, only the VU1's vertex pipeline was able to achieve this speed directly. PATH2/PATH3 used the commodity RDRAM's bus (unless you utilized MFIFO to mirror a small portion of that to the buffer, which was much more difficult and underutilized than otherwise since it was likely to stall the other pipelines); the exact same bus Pentium 4's would use a few months after the PS2's initial launch (3.2-6.4GB/s). It's more akin to a (very large) 4M chip cache, than proper RAM/VRAM. As to the PS3 being half that, that's more a design decision of the PS3. They built the machine around a universal bus (XDR) versus using bespoke interconnects. If you look at the Xbox 360, they designed a chip hierarchy similar to the PS2 architecture; with their 10MB EDRAM (at 64GB/s) for GPU specific operations. As to those speeds being unique. That bandwidth was made possible via eDRAM (on-chip memory). Other bespoke designs utilized eDRAM, and the POWER4 (released around the same time) had per-chip 1.5M L2 cache running at over double that bandwidth (100GB/s). It also was able to communicate chip-to-chip (up to 4x4 SMP) at 40GB/s and communicate with it's L3 at 44GB/s (both, off-chip buses). So other hardware was definitely achieving similar to and greater bandwidths, it just wasn't happening on home PCs.

twoodfin 2y ago
Growing up with the tech press in this era, “commodity RDRAM” is a funny phrase to read! As I recall, the partnership between Intel and Rambus was pilloried as an attempt to re-proprieterize the PC RAM interface in a similar vein to IBM’s microchannel bus.
- deaddodo 2y ago
  "Commodity" meaning "something that could be bought at the store".
  - twoodfin 2y ago
    From the Rambus store!

pjmlp 2y ago

Most third parties weren't able to explore the PS2 properly, until Sony had to go through a revamp of their SDK, and collaborated with Gran Turism folks to show what was actually possible.

xgkickt 2y ago
Not sure what you mean. The entire system was available to everyone day 1 through the manuals. The introduction of the VLC VU assembler made VU development easier (single instruction stream, automatic register allocation). PATH3 texture uploads maybe?
- pjmlp 2y ago
  Just because someone gets a driver license, doesn't mean they are fit to drive on F1 GP. Likewise most game developers weren't fit to drive PS2 without additional help from Sony.