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

Architecture of the Playstation

copetti.org

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Architecture of the Playstation

#81

Post by ndesaulniers »

chondl wrote: post #38
dmbaggett wrote: post #9

This is a great overview. I don't remember having to put in padding instructions to prevent the pipeline issues mentioned here; maybe we just never ran into that. (I wrote pretty much all the R3000 code for Crash 1 and just do not recall problems like that coming up.) To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer. This meant…

Reverse engineering the assembly code required to drive the Geometry Transformation Engine efficiently from the compiled output of the C libraries is to this day one of my favorite technical puzzles I've worked on in my career. I remember sitting in a meeting with our technical contact at Sony's headquarters in San Mateo where he basically asked without asking if we were using the C libraries. From the way he asked t…

I assume you only had a disassembler to work with, at the time?

Re: Architecture of the Playstation

#82

Post by ndesaulniers »

AtlasBarfed wrote: post #71
dmbaggett wrote: post #9

This is a great overview. I don't remember having to put in padding instructions to prevent the pipeline issues mentioned here; maybe we just never ran into that. (I wrote pretty much all the R3000 code for Crash 1 and just do not recall problems like that coming up.) To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer. This meant…

I think a late-generation ps1 game did have a z-buffer, I don't remember the one though. Blasto maybe?

It would have had to have been in software then; modern hardware handles Z buffer calculations for you. That would have been slow and memory intensive on the PS1.

Re: Architecture of the Playstation

#83

Post by dmbaggett »

sokoloff wrote: post #3

I led a small dev team to port a PC title to the original PSX. It had a physics engine that ran at 30Hz and needed to run close to isochronously to preserve gameplay. One of the hacks we created was a limited pre-emptive multi-tasking system on the original Playstation to run our physics engine at a constant frequency. We'd asked Sony US who escalated to Sony Japan and told us it couldn't be done and we should write…

You probably know this, but for the benefit of others: this technique of using the vertical blank interrupt to run code was very common in the 8-bit (Atari/Apple/C64) era. In fact you really couldn't write a decent game without hooking the vertical blank interrupt (and often the per-scanline horizontal interrupt as well).

It's interesting that you were able to adapt this technique to PS1 hardware; does that game run properly under emulators or does it give them fits?

Re: Architecture of the Playstation

#84

Post by Talanes »

etempleton wrote: post #14
bluedino wrote: post #4

The PSX did not age well. I noticed this at a friend house, while looking for something in the garage we came across his old system and games. We could not resist taking it back into the house and setting it up. The first thing I noticed was how long the load times were. And how noisy the machine was when reading and seeking on the discs. The next thing was the primitive texture mapping. Polygons 'jiggling' and 'spar…

PS1 and N64 visuals have both aged poorly, though I agree, I think the PS1 is the toughest to go back to from a visual perspective. The shimmering polygons that you see on the PlayStation and on the Saturn feels unacceptable by today’s standards and then they are both also notorious for long load times. The N64 has it’s own set of graphical limitations, but hold up a bit better to the test of time, IMO. At the time I…

Weirdly, I think sharpness is exactly where PS1 games don't hold up. Metal Gear Solid is less off-putting to go back to than Metal Gear Solid 2. The pixely textures and dim lighting give it some atmosphere, where the extra detail in MGS2 just comes off as very plastic now.

Re: Architecture of the Playstation

#85

Post by dmbaggett »

Tsiklon wrote: post #6

It’s a minor point in the breakdown of the system, but I had absolutely no idea that the Memory Card Slots and the Controller Ports on the PlayStation were electrically identical, when I was younger I had recognised that they both had 9 contacts. But I hadn’t considered that they would be electrically the same. The only difference being in how they were addressed. I regularly use my PlayStation instead of my PlayStat…

This (the linkages between the controller and the memory card) turned out to be problematic for us on Crash, actually. I've posted about this here in prior years so I won't rehash it. :)

https://www.gamasutra.com/blogs/DaveBaggett/20131031/203788/...

Re: Architecture of the Playstation

#86

Post by sokoloff »

dmbaggett wrote: post #83
sokoloff wrote: post #3

I led a small dev team to port a PC title to the original PSX. It had a physics engine that ran at 30Hz and needed to run close to isochronously to preserve gameplay. One of the hacks we created was a limited pre-emptive multi-tasking system on the original Playstation to run our physics engine at a constant frequency. We'd asked Sony US who escalated to Sony Japan and told us it couldn't be done and we should write…

You probably know this, but for the benefit of others: this technique of using the vertical blank interrupt to run code was very common in the 8-bit (Atari/Apple/C64) era. In fact you really couldn't write a decent game without hooking the vertical blank interrupt (and often the per-scanline horizontal interrupt as well). It's interesting that you were able to adapt this technique to PS1 hardware; does that game run…

Indeed: that's where I learned it, having written both H/VBLANK ISRs on the beloved 8-bit Atari I grew up with. HBlank ISRs were needed to get more than 4 + 1 player-missile (sprites) to work.

I don't know if the game runs on emulators, but I know it runs correctly on a mid-generation PS3 and I'd expect that VBlank interrupt handling would be implemented by an emulator, so I'd expect it should work.

PS: Massive, massive respect for you and the rest of the Crash team. When that game came out, we couldn't comprehend how you were able to pull off that game on the same hardware we were using. Much respect (and thanks for the great gaming memories)!

Re: Architecture of the Playstation

#87

Post by Talanes »

insin wrote: post #52
bluedino wrote: post #4

The PSX did not age well. I noticed this at a friend house, while looking for something in the garage we came across his old system and games. We could not resist taking it back into the house and setting it up. The first thing I noticed was how long the load times were. And how noisy the machine was when reading and seeking on the discs. The next thing was the primitive texture mapping. Polygons 'jiggling' and 'spar…

It's worth revisiting some of your favourites in an emulator - these days PSX emulators can do perspective correct texturing to fix the jiggling and warping, which combined with internal upscaling makes games which were badly affected by those shimmering textures feel much more "solid". Here's the first track in Ridge Racer Type 4, for example, which looks so much nicer without the track and wall textures wobbling ab…

Except for the pixely UI elements, upscaled Ridge Racer could pass for a launch PS2 title.

Re: Architecture of the Playstation

#88

Post by Arelius »

dmbaggett wrote: post #9

This is a great overview. I don't remember having to put in padding instructions to prevent the pipeline issues mentioned here; maybe we just never ran into that. (I wrote pretty much all the R3000 code for Crash 1 and just do not recall problems like that coming up.) To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer. This meant…

> To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer.

There is a section "Visibility Approach" under the GPU section that starts: "Just like the competition, the PS1 doesn’t include any hardware feature that solves the visibility problem."

I agree that it doesn't really stress the ramifications of that.

Re: Architecture of the Playstation

#89

Post by EricE »

dmbaggett wrote: post #59
djhworld wrote: post #56

Earlier quoted context omitted.

> The other thing to note is that to make a truly high-performance game for PS1 you had to completely ditch Sony's sanctioned C APIs -- something they said would cause your game to get banned, but which we did anyway. Fascinating! Was this because Sony didn't bother checking, or they saw the performance you were getting and just let it slide?

I recall that they mandated use of the C APIs to easily support future PS2 backward compatibility. I think what they ended up doing was just embedding a PS1 into the PS2, so use of the C APIs never mattered. Which was good, because by the time PS2 was out, lots of PS1 games had shipped that used the bare metal hardware, circumventing the APIs. The problem was there was just no way to make a fast C API for things like…

"I think what they ended up doing was just embedding a PS1 into the PS2, so use of the C APIs never mattered." I'm not sure on the PS2 but I know that's what they did in the PS3 - I found the 60GB launch PS3 that had the hardware PS2 embedded as well as the greatest amount of ports and maybe a few other aspects that made it one of the more sought after PS3 version. I still use it as a Bluray player and occasionally fire up Little Big Planet - still one of my favorite games.
Post reply on HN