Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Playstation Architecture: A Practical Analysis

copetti.org

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Playstation Architecture: A Practical Analysis

#101

Post by p_l »

bitwize wrote: post #59
Razengan wrote: post #51

Earlier quoted context omitted.

> It seems the craftsmanship aspect of computer programming is getting lost, and all that remains is the large leverage that one can use to drive profits with software. Too many lazy/greedy developers fighting against users and operating systems (coughelectroncough)

Electron is the future. Why? Developers would rather spend more of your computer's time (and other resources) than their own time. And most end users -- e.g., people who work in a Slack-based business and so NEED the Slack app -- consider the tradeoff worth it.

Or, more likely, don't have an option nor a real voice.

Re: Playstation Architecture: A Practical Analysis

#102

Post by mrguyorama »

wtallis wrote: post #95
deelowe wrote: post #92

Earlier quoted context omitted.

> optimizing the SSD-to-VRAM pipeline in a way that component-built PCs won’t be able to do until several new industry standards are developed, with potentially profound impacts on the way games are designed. What are the innovations? I'm just seeing gen 4 pci-e paired with some sort of nvram solution (details are sparse). Apologies if I'm missing something spectacular here...

The only really interesting thing is that the console SoCs have decompression offload hardware, so data coming in from the SSD at 4-5GB/s can be unpacked to a 9+GB/s stream of assets, straight into the RAM shared by the CPU and GPU. A desktop PC can easily handle the decompression on the CPU with a combination of higher core counts and higher clock speeds, but then the data still needs to be moved across a PCIe link…

When it comes to graphics assets, they've been stored compressed and decompressed by the GPU on the fly pretty much since early versions of DirectX. What is the innovative part here?

Re: Playstation Architecture: A Practical Analysis

#103

Post by gridlockd »

mrguyorama wrote: post #100
gridlockd wrote: post #91

Earlier quoted context omitted.

No it isn't! Sure, you can run some sort of Java VM on a lot of platforms. That's no big distinction, you can say the same about Javascript, Python, Lua and so on. Once you enter the realm of graphical applications, it's a clusterfuck, just like any other "cross-platform" thing.

Does Swing not run pretty much the same on Mac, Linux, and Windows?

Yes, it sucks on all these platforms equally badly.

Re: Playstation Architecture: A Practical Analysis

#104

Post by grawprog »

kabes wrote: post #70
dzeix35wc363CzC wrote: post #4

For anyone interested how it was developing for the original PSX (and therefore under hardware constraints) How Crash Bandicoot Hacked The Original Playstation https://www.youtube.com/watch?v=izxXGuVL21o Immensely interesting video! "Old" hardware makes me feel so humble regarding what we have now. Hardware limitations back then really pushed developers towards novel approaches and solutions.

While hardware is a lot more performant now, game devs are still pushing the boundaries, I'd say even more than back then. Modern triple A games like red dead redemption 2 are a giant collection of such tricks.

>Modern triple A games like red dead redemption 2 are a giant collection of such tricks.

It's just too bad somewhere along the way they forgot games were supposed to be fun as they were slapping eachother's backs over how ingenious they were to be able to render every flea and tick on a horse's asshole while you clean it out and feed them a carrot.

Re: Playstation Architecture: A Practical Analysis

#105

Post by danbolt »

mikorym wrote: post #16
kozak wrote: post #11

What's amazing is that it had only 2 MB of RAM, that's at least 2000 times less than a cheap phone has today. In fact, that's less than a moderate quality mobile phone photo as stored on disk.

I think these programmers were forced to understand their subject matter much better than today. Say for (a silly) example you want the first 10 000 digits of Pi. It's pretty easy to just store that today. But back then you didn't just have to know what Pi is , you had to have the smallest program to calculate it that you can think of. Would be interesting to hear too how Tekken 3's coders managed to work with 2 MB o…

I'm not sure if you saw the interview on Polygon [1], but I really liked hearing about doing the first Tekken port from arcades to PS1 and dealing with the newer memory constraints.

[1] https://youtu.be/XB0mgLo9lEw?t=1214

Re: Playstation Architecture: A Practical Analysis

#106

Post by wtallis »

mrguyorama wrote: post #102
wtallis wrote: post #95

Earlier quoted context omitted.

The only really interesting thing is that the console SoCs have decompression offload hardware, so data coming in from the SSD at 4-5GB/s can be unpacked to a 9+GB/s stream of assets, straight into the RAM shared by the CPU and GPU. A desktop PC can easily handle the decompression on the CPU with a combination of higher core counts and higher clock speeds, but then the data still needs to be moved across a PCIe link…

When it comes to graphics assets, they've been stored compressed and decompressed by the GPU on the fly pretty much since early versions of DirectX. What is the innovative part here?

They're using lossless compression algorithms that are a lot more complicated than S3 Texture Compression and friends, and work on arbitrary data rather than being appropriate only for textures.

Re: Playstation Architecture: A Practical Analysis

#107

Post by miskin »

bloopernova wrote: post #62
miskin wrote: post #53

Earlier quoted context omitted.

It's a matter of perspective. When one witnessed it from times of Pong until now, it is maybe much easier to appreciate the whole journey. I still find myself trying to save bandwidth on my internet connection that was very scarce resource not-that-long-ago. When I see people listening to music via youtube, unnecessarily transfering all that video content that nobody really watch, I want to cry :). Same with programm…

How comparable is an ESP32 to a Spectrum 48K? (apart from memory, the esp has many times more to play with)

ESP32 is of course so much more powerful than ZX was. I meant that programming of ESP is much different to usual daily job enterprise stuff.

Re: Playstation Architecture: A Practical Analysis

#108

Post by andrekandre »

softfalcon wrote: post #71
Koshkin wrote: post #63

Earlier quoted context omitted.

Well, as much as I would love to share the excitement, all they've come to is what essentially amounts to another gaming PC. Not sure how 'far' this is, but clearly all innovation happens now on the PC side. (It almost seems now that the fact that the earlier Playstation models and other consoles had the custom architecture that was different from PC may have had to do with the need to provide enough power in a small…

Custom architecture was prevalent back then because there weren't any real standards for developing a system that could render 3D graphics. If you wanted 3D rendering, you had to do it yourself. No one was selling you a pre-built stable chip. The now defunct fixed function pipeline was still being formalized in PCs, let alone consoles. Each console was a massive exploration into what could be done and who could make…

> Having one company able to provide chipsets for any and all applications, including gaming at a practical whim seems pretty amazing.

its amazing, but is it a good thing?

could we say the same about say, amazon?

Re: Playstation Architecture: A Practical Analysis

#109

Post by 2600 »

agavin wrote: post #88
dzeix35wc363CzC wrote: post #4

For anyone interested how it was developing for the original PSX (and therefore under hardware constraints) How Crash Bandicoot Hacked The Original Playstation https://www.youtube.com/watch?v=izxXGuVL21o Immensely interesting video! "Old" hardware makes me feel so humble regarding what we have now. Hardware limitations back then really pushed developers towards novel approaches and solutions.

Thanks for the interest in our shared video gaming past. I had a lot of fun making that video. The PS1 was a fun machine as it was capable, complex enough that you felt it had secrets, but not so bizarre or byzantine that you felt learning them was a waste of time. And you were pretty much the only one in there as the libraries were just libraries, not really an OS. Still true of the PS2 although that was a complex b…

I really enjoyed your "Making Crash Bandicoot" blog posts and the "War Stories" video. I would love to read about your work on Jak & Daxter and working on the PS2.

Re: Playstation Architecture: A Practical Analysis

#110

Post by pcwalton »

louthy wrote: post #90

I remember developing for the PS back in 1996-1999. The first title I worked on I was building the graphics engine and animation systems. Originally in C, then in MIPS assembler to get as much perf as possible: with a fixed target the difference for your title would be mostly down to the performance of the graphics engine. I got to the point where I'd fitted the entire graphics engine and animation system into 4K, so…

> Reading from memory was slow, it took 4 cycles, which normally would be filled with NOPs by the C compiler (1 load instruction, 3 NOPs). So, I'd use assembly instead of C and try to fill those NOPs with other actual operations that didn't need the memory being requested, essentially doing hand-crafted concurrency.

This isn't usual for the MIPS ISA, is it? MIPS has branch delay slots but not memory delay slots, per my understanding. (Of course if there's a data dependency on a pending load the CPU still has to stall.)

Post reply on HN