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

111–118 of 118 posts

Re: Playstation Architecture: A Practical Analysis

#111

Post by fomine3 »

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.

PWA should be the future for apps that don't need much permissions. Why we need individual Chromium for just chat app?

Re: Playstation Architecture: A Practical Analysis

#112

Post by camgunz »

hvs wrote: post #76
fxtentacle wrote: post #46

It 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 was a programmer back then, and it's not the "golden age of programming" that some make it out to be. For one thing, WE were complaining about how big and bloated software was becoming compared to the "old days" when programmers only had 64KB to work with. On top of that, it took SO LONG to develop basic functionality that you could probably build in a one hour language tutorial now. Things that were excruciating t…

Thank you for this wisdom and perspective.

Re: Playstation Architecture: A Practical Analysis

#113

Post by wtallis »

0xcde4c3db wrote: post #66
idoby wrote: post #27

Is "page-flipping" basically double buffering or am I missing something?

I hadn't heard the term in a while, but I believe page-flipping more specifically means that the buffer roles can be switched in hardware (e.g. by changing a "framebuffer start address" register in the CRTC or RAMDAC) instead of requiring a buffer to be copied (e.g. via a DMA or blitter operation). Both schemes are double-buffered in the sense that you're never actively rendering to the same buffer that's being scann…

When's the last time anyone produced a hardware platform where double-buffering required a full copy rather than just updating a pointer/register? PCs moved past that in the '90s at the latest, and I'd expect most other platforms that supported 32+ bit addressing on both the CPU and graphics processor were similarly capable of relocating the front buffer at will.

Re: Playstation Architecture: A Practical Analysis

#114

Post by JohnBooty »

pjmlp wrote: post #23
newswasboring wrote: post #21

Earlier quoted context omitted.

yeah but modern programmers are also solving harder problems. Compare games from early consoles and today, the scope is vastly larger.

Like shipping Electron apps.

Folks crap on Electron apps and rightfully so, but I absolutely LOVE one thing about them relative to native GUI apps.

I can hit cmd+ and cmd- to scale their content and UI up and down.

That is dang near a killer feature for me.

Very handy for presenting, screen sharing, when I move my apps to an external monitor with a slightly different UI, or for moments when my eyes are simply tired and I want something easy to read.

You can say that I shouldn't need hundreds of MB of RAM to run Slack's desktop client, and you ain't wrong, but I've got plenty of RAM. My eyes and my time are much more finite resources.

Re: Playstation Architecture: A Practical Analysis

#115

Post by louthy »

pcwalton wrote: post #110
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…

The R3000 suffered from the need for load delay slots too, unfortunately. I may have forgotten all the exact details though. I am genuinely in awe of people who seem to retain the details of this stuff 10 - 20 years later, my brain certainly doesn't work like that!

Re: Playstation Architecture: A Practical Analysis

#116

Post by AtlasBarfed »

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…

The current AMD chips have 1.5MB of LEVEL 1 CACHE! To say nothing of the 8MB L2, 32MB L3, and the integrated video processor.

And you had to do the work that an optimizing compiler could do today, although they have to target a "theoretical" CPU rather than a fixed hardware set like the old consoles.

Since all the superscalar tricks such as out of order, spec exec, and the like are now maxed out, maybe what should happen is that CPU vendors should concentrate on optimizing a fixed VM-sized hardware profile that the compilers can more efficiently target.

A CPU ISA is somewhat like that, but it has so much variance.

With Moore's law gone, we will actually have to start removing abstraction from the development pipeline and get to more optimized and direct code to drive performance.

Re: Playstation Architecture: A Practical Analysis

#117

Post by kernelbugs »

2600 wrote: post #109
agavin wrote: post #88

Earlier quoted context omitted.

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.

Me too, the Jak & Daxter games have a very special place in my heart as my childhood introduction to gaming. I'd love to reach about it!

Re: Playstation Architecture: A Practical Analysis

#118

Post by idoby »

0xcde4c3db wrote: post #66
idoby wrote: post #27

Is "page-flipping" basically double buffering or am I missing something?

I hadn't heard the term in a while, but I believe page-flipping more specifically means that the buffer roles can be switched in hardware (e.g. by changing a "framebuffer start address" register in the CRTC or RAMDAC) instead of requiring a buffer to be copied (e.g. via a DMA or blitter operation). Both schemes are double-buffered in the sense that you're never actively rendering to the same buffer that's being scann…

In all multiple-framebuffer capable hardware platforms I know of, there's a pointer to the FB involved (in the case you describe, an address-bearing register).

Otherwise a copy is required into a hardcoded address or physical memory, and then you're not double-buffering anymore.

Post reply on HN