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

41–50 of 116 posts

Re: Architecture of the Playstation

#41

Post by yjftsjthsd-h »

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…

> then restore the registers and longjmp back to the main game code which had been originally interrupted by the vertical blank interrupt.

So that's really like, half preemptive with the return side really being cooperative style?

Re: Architecture of the Playstation

#42

Post by yjftsjthsd-h »

flipacholas wrote: post #20
4ad wrote: post #17

Truly excellent information, but the "tabs" that you have to click in order to read the next part is positively the worst UX I have ever seen on a static website.

The tabs were made to prevent the user from scrolling indefinitely if he/she is not interested in one section in particular. This only appears in desktop (not mobile). I'm not a web dev though, so I don't mind switching to a better pattern. Do you know a better one?

Table of contents (made of links to sections) at the top?

Re: Architecture of the Playstation

#44

Post by willcipriano »

TwoBit wrote: post #29
gumby wrote: post #7

> During the development of the PlayStation, MIPS was offering the R3000A series of processors. The TMPR5900 (the MIPS chip developed by Toshiba to power the PS2) was sufficiently complex to develop that we developed a cycle-accurate simulator so Sony (and a few game developers) could start development before hardware was available. However emulation isn't always the best approach: the PS2 (at least the first edition…

The first gen of PS3 included a PS2 on board.

Game boy advance had a game boy on board as well.

Re: Architecture of the Playstation

#45

Post by sokoloff »

yjftsjthsd-h wrote: post #41
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…

> then restore the registers and longjmp back to the main game code which had been originally interrupted by the vertical blank interrupt. So that's really like, half preemptive with the return side really being cooperative style?

Yes, exactly (and why I described it as limited).

The physics thread (with interleaved joystick read code on PC) did have to yield back to the main/graphics thread. That was no issue in our case; I've not thought deeply about it, but it seems like the method is likely extensible to do context switches among multiple [unaware/non-cooperating] threads.

Re: Architecture of the Playstation

#47

Post by NortySpock »

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…

Something I've wondered about the "sorting polygons" strategy: would sorting only part of the part of the polygons per frame been enough? (front-half vs back-half, one-bubble-sort-pass-per-frame, or some other iterative partial solution)

How often did the polygons get out of order?

(Or am I thinking only in 2D arrays when the problem is really multiple-polygon occlusion?)

Re: Architecture of the Playstation

#48

Post by dfox »

TwoBit wrote: post #29
gumby wrote: post #7

> During the development of the PlayStation, MIPS was offering the R3000A series of processors. The TMPR5900 (the MIPS chip developed by Toshiba to power the PS2) was sufficiently complex to develop that we developed a cycle-accurate simulator so Sony (and a few game developers) could start development before hardware was available. However emulation isn't always the best approach: the PS2 (at least the first edition…

The first gen of PS3 included a PS2 on board.

I believe that even the slim PS3 versions without full-blown GS+EE hardware still include the PS1 CPU somewhere in a role of IO controller.

Re: Architecture of the Playstation

#49

Post by dmbaggett »

NortySpock wrote: post #47
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…

Something I've wondered about the "sorting polygons" strategy: would sorting only part of the part of the polygons per frame been enough? (front-half vs back-half, one-bubble-sort-pass-per-frame, or some other iterative partial solution) How often did the polygons get out of order? (Or am I thinking only in 2D arrays when the problem is really multiple-polygon occlusion?)

I doubt it. One observation is that polygons can experience cyclic overlap, so A > B and B > C does NOT imply A > C. This transitivity property is required for O(N lg N) sorting algorithms. And note that even with Crash 1 polygon counts, O(N^2) is > 1000^2 -- way too huge for a 33Mhz processor.

However, the way I did it was to precompute the sort order of the polygons ahead of time and store periodic key frames (the complete sorted list) along with diffs. These diffs were generally very small, meaning your intuition that not much changes from frame to frame is a valid one. The problem is without the runtime oracle telling you which polygons move from frame to frame, it seems hard to exploit this property.

Another issue with approximate polygon sorting methods like bucket sorting is that the sort isn't terribly stable from frame to frame, so you get the annoying flickering effect that you see so often in PS1 games, as a pair of polygons alternates between relative sort order as you move around.

Re: Architecture of the Playstation

#50

Post by NortySpock »

dmbaggett wrote: post #49
NortySpock wrote: post #47

Earlier quoted context omitted.

Something I've wondered about the "sorting polygons" strategy: would sorting only part of the part of the polygons per frame been enough? (front-half vs back-half, one-bubble-sort-pass-per-frame, or some other iterative partial solution) How often did the polygons get out of order? (Or am I thinking only in 2D arrays when the problem is really multiple-polygon occlusion?)

I doubt it. One observation is that polygons can experience cyclic overlap, so A > B and B > C does NOT imply A > C. This transitivity property is required for O(N lg N) sorting algorithms. And note that even with Crash 1 polygon counts, O(N^2) is > 1000^2 -- way too huge for a 33Mhz processor. However, the way I did it was to precompute the sort order of the polygons ahead of time and store periodic key frames (the…

Thanks, really clear explanation, and thanks for taking the time to answer such a basic question. :)
Post reply on HN