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

101–110 of 116 posts

Re: Architecture of the Playstation

#101

Post by rffn »

dumael wrote: post #16
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…

> 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.) If you were using the GNU assembler, it automatically fills branch delay slots with nop instructions unless you prefix assembly code as using `.set n…

Inserting NOPs is a waste of code space and execution resources though. If resources are not too tight, this is fine.

We used gcc on a MIPS M4K in a communication chip. We had a lot of existing C code and were short on ROM and on CPU cycles. Therefore a few co-workers wrote a tool which parsed the gcc asm output to fill the branch delay slot with an instruction with no side effects on the branch. It also fixed some gcc issue with 16 bit memory accesses in C were created as 32 bit load instruction in asm (which can be two cycles if the first 16 bit of a 32 bit word are needed). I had a HW/SW cosim setup to test code and hardware (Verilog). These were cool projects. Good memories (although quite vague now).

PS: If we would have had a license of the Green Hills compiler we could have saved some of the effort. IIRC it did branch delay slot optimization.

Re: Architecture of the Playstation

#102

Post by flipacholas »

badsectoracula wrote: post #97
flipacholas wrote: post #80

Earlier quoted context omitted.

The lack of floating point unit on the PS1 is commonly misinterpreted, see https://www.copetti.org/writings/consoles/playstation/#tab-5...

I'm not sure why you think the "Models/textures flicker due to lack of Z-buffering" is not accurate. I mean, sure, models/textures can flicker for other reasons too so technically that can be inaccurate but lack of z-buffer is one of the most common reasons since the majority of 3D games software relied on z sorting polygons that couldn't always be sorted perfectly (static geometry could be preprocessed with, e.g., a…

> Or is it that it isn't a problem of PS1 but a problem of games

Yes, this is what I wanted to emphasize.

My intent wasn't to say that the 'lack of z-buffering' statement was incorrect (it's still true), but that there's a fundamental issue behind it, the visible/hidden surface determination, and now it depends on the developer's implementation. I believe this is overlooked on non-technical sites.

With this, I just wanted to make it more informative for the reader. I don't think the question is if the PS1 has a z-buffer or not. Sure, z-buffering is a solution, but there's the reasoning behind it that I wanted to transmit it to the reader.

Anyway, that's just my opinion.

Re: Architecture of the Playstation

#103

Post by flipacholas »

hypertele-Xii wrote: post #96
flipacholas wrote: post #80

Earlier quoted context omitted.

The lack of floating point unit on the PS1 is commonly misinterpreted, see https://www.copetti.org/writings/consoles/playstation/#tab-5...

Your citation contradicts itself. The polygon jitter exists for lack of floating point unit. While it's possible to emulate the necessary precision, it's uneconomical without the acceleration provided by a dedicated processing unit. Without floating point, the PSX isn't fast enough to render complex scenes in real-time accurately; Hence the jitter.

I don't mind being wrong and I will correct the article if needed. That being said, I'm interested in debating this, what if the PS1's GPU had implemented some sort of sub-pixel precision and edge antialiasing? Do you think the lack of floating-point vertex coordinates would have been noticeable? (I'm assuming the 'jitter' means the sudden jumps when polygons move slowly).

Re: Architecture of the Playstation

#104

Post by dmbaggett »

korethr wrote: post #100
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…

> The CPU and RAM in those machines were just incredibly slow by today's standards. I have a few questions, interspersed with my musings on them. Based on an initial misreading of the above as the RAM being slow, I mistook your statement to mean that memory latency on a similar order to today's computers was something that you had to fight with. Was it memory latency per-se that made achieving sufficient performance…

Good questions. We were using SGI workstations which ran at 250Mhz if I recall correctly — so ~8x the PS1 CPU.

It was admittedly nearly 30 years ago but my recollection is that the only way to make anything fast on that hardware was to keep everything in registers and avoid touching memory except when absolutely necessary. It was definitely many cycles to access memory.

Re: Architecture of the Playstation

#105

Post by dmbaggett »

NortySpock wrote: post #50
dmbaggett wrote: post #49

Earlier quoted context omitted.

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. :)

It’s not a basic question at all. If you look at the most innovative games of that era, they all found some way to not resort to O(N^2) polygon sorting. A bit before Crash came out ID Software showed that spatial data structures like BSP trees could help a lot; we were influenced by that.

Re: Architecture of the Playstation

#106

Post by dmbaggett »

sokoloff wrote: post #86
dmbaggett wrote: post #83

Earlier quoted context omitted.

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, mass…

Thank you so much for the kind words. We took huge technical risks and got really lucky.

Re: Architecture of the Playstation

#107

Post by a1369209993 »

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…

> Reverse engineering the assembly code

Well of course you were using the libraries! Just like you were using the documentation. Exactly like you were using the documentation, in fact. The fact that neither got jumped to as executable code is clearly immaterial.

Re: Architecture of the Playstation

#108

Post by SSLy »

badsectoracula wrote: post #95
SSLy wrote: post #92

Earlier quoted context omitted.

>CD distortion There is no such thing as CD distortion. Does that make the whole opinion invalid?

Perhaps lack of distortion? I remember some DJ friends from back in the day saying that CDs sound more "sterile" than vinyl (this was late 90s/early 2000s).

Yeah maybe, but as a composer he should know better than that, no? Or does he rely on his engineers for that?

Re: Architecture of the Playstation

#109

Post by anthk »

korethr wrote: post #100
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…

> The CPU and RAM in those machines were just incredibly slow by today's standards. I have a few questions, interspersed with my musings on them. Based on an initial misreading of the above as the RAM being slow, I mistook your statement to mean that memory latency on a similar order to today's computers was something that you had to fight with. Was it memory latency per-se that made achieving sufficient performance…

An MMX Pentium would run circles around the PSX as it could play lots of games with a 3DFX.

A Pentium Pro could run Unreal, I think. That game (and engine) basically could crush down any PSX and N64 at once.

A Pentium 2 could emulate the PSX at lowest settings.

Re: Architecture of the Playstation

#110

Post by anthk »

ranma42 wrote: post #30
flipacholas wrote: post #15

Oh what an amazing feeling seeing one of my articles here. Let me share you a bit of history about this one: - A year ago, an old version of this article got shared in hn ( https://news.ycombinator.com/item?id=22932134 ) and since then, google started positioning my site in their search results, and many forums started noticing the site. Yay! - Fast forward, I graduated from uni, continued working on more articles in…

> CD-ROM sub-channels traditionally store metadata, mostly to guide the drive. These aren’t user accessible and conventional readers rarely allow to manually write over them. Maybe early CD-ROM drives couldn't read the side-channel data, but all drives (readers and burners) after a certain generation can read raw 2448 byte (2352 byte raw sector data + 96 byte subchannel data) sectors. I think Plextor drives might hav…

Yes, with cdrdao I could read any rented PSX disc under Linux in order to "backup" it.
Post reply on HN