Wow I never imagined my article being in hackernews. Thanks for sharing it! If anyone has any comments, requests or want to report a mistake, please drop me a message (email address is in that website), I’m constantly adding more material.
Playstation Architecture: A Practical Analysis
81–90 of 118 posts
Re: Playstation Architecture: A Practical Analysis
#82It's crazy to see just how far they've come from the first console to the latest and all the lessons they've learned along the way. https://www.youtube.com/watch?v=ph8LyNIT9sg (Some Playstation 5 architecture highlights).
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…
It’s specifically an interesting contrast with the Playstation 3’s exotic Cell processor architecture, which was probably driven more by a desire to appear innovative than by practical applications. By moving to standard x86 architecture, Sony has counterintuitively allowed its system designers to focus on areas that will actually give game developers some novel possibilities.
Re: Playstation Architecture: A Practical Analysis
#83What'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.
Re: Playstation Architecture: A Practical Analysis
#84Earlier quoted context omitted.
I understand that Electron apps tend to be a resource hog, but what other options for software create as many cross platform opportunities with as much work? I think for every single greedy developer/company there's another small software project only able to get off the ground because of the maximized opportunities. This is coming from a relatively new full time developer who's trying to get a small side project off…
This is also partially the fault of the operating system companies for not making native development as easy and portable as it should be. Things like SwiftUI and the upcoming "clips" (or whatever the iOS/Android "partial/temporary apps" tech is going to be called) are a step in a good direction.
Re: Playstation Architecture: A Practical Analysis
#85Earlier quoted context omitted.
> I understand that Electron apps tend to be a resource hog, but what other options for software create as many cross platform opportunities with as much work? Is laziness a good excuse for poor software? For wasting the time and resources of every one who uses the application? For disregarding the conventions of the host platform including any user preferences and accessibility features?
> For wasting the time and resources of every one who uses the application? I don't believe this argument for a second, with the ubiquitousness of successful Electron apps.
Re: Playstation Architecture: A Practical Analysis
#86Earlier quoted context omitted.
Like shipping Electron apps.
Honestly dude, I know you are trying to joke and all but this just sounds incredibly rude. This minimization of someone else's skill is petty and absurd. Electron apps serve their purpose and have their place, hating on them will not get you anywhere.
Re: Playstation Architecture: A Practical Analysis
#87It makes me feel nostalgic to read about the times when people still tried to understand the hardware and make things work amazingly well despite harsh resource limits. Nowadays, even simplistic programs take ages on a device 1000 times more powerful. I had time to read this article because restarting our ruby development server is so excruciatingly slow. It seems the craftsmanship aspect of computer programming is g…
I don't think it's about developers caring less. I think it's because businesses have figured out that it is most cost-efficient to throw powerful hardware on problems rather than spending money on bespoke solutions or specialists in most cases.
Re: Playstation Architecture: A Practical Analysis
#88For 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.
Re: Playstation Architecture: A Practical Analysis
#89Earlier 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)
I understand that Electron apps tend to be a resource hog, but what other options for software create as many cross platform opportunities with as much work? I think for every single greedy developer/company there's another small software project only able to get off the ground because of the maximized opportunities. This is coming from a relatively new full time developer who's trying to get a small side project off…
Re: Playstation Architecture: A Practical Analysis
#90I got to the point where I'd fitted the entire graphics engine and animation system into 4K, so it would fit in the instruction cache, and moved as much regularly used data into the 1K scratchpad as I could fit (Yes, an L1 cache that you decided manually what to put in it!). Access to the scratchpad would take 1 cycle.
Then I'd 'hand interleave' asm operations. 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.
Because loading and storing from/to memory was such a common operation, this would make the code very, very hard to maintain, and sent me slightly crazy for a while! Often it meant doing x, y, z operations (for 3D processing, like vector multiplication) concurrently, but wherever the the NOPs could be reduced, more could be done.
With various other bits of cunning I eventually got it to the point where I broke the manufacturers specs for whatever Sony said the PS could do per-second (memory is a bit fuzzy about what those specs were, but I remember myself and the team being pretty damn pleased at the time).
It was a fun machine to program for. The Saturn which was out at the same time always struggled to keep up because it was so hard to develop for, even though on paper it was better. I think that was what struck the death knell for Sega.