12 ms·

Playstation Architecture: A Practical Analysis

342 points by plerpin 6y ago

ddoolin 6y ago
It'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 https://www.youtube.com/watch?v=ph8LyNIT9sg (Some Playstation 5 architecture highlights).
- Koshkin 6y ago
  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 smaller package.)
  - softfalcon 6y ago
    Custom architecture was prevalent back then because there weren't any real standards for developing a system that could render 3D graphics. If you wanted 3D rendering, you had to do it yourself. No one was selling you a pre-built stable chip. The now defunct fixed function pipeline was still being formalized in PCs, let alone consoles. Each console was a massive exploration into what could be done and who could make the best SDK for that hardware to entice developers to make games. The fact that all modern consoles and PC's are similar should be applauded. It's the culmination of decades of hardware and software learnings, standardized into the optimal hardware for graphics and game performance. The fact that they all found what they needed in a similar architecture footprint is good for hardware design, good for developers, good for business, good for porting, good for optimization, and finally, good for performance. Sony, Nintendo, and Microsoft are no longer able to design the latest and greatest chipsets. The complexity is just too much for them to reasonably pay to do so. That's why AMD does it for them. Why would you reinvent the wheel when someone has already spent decades making Ferrari's and is begging you to use their engine at a discount, bulk manufacturing included? Back during the PS1, Sony had a heavy hand in the graphics card design. Not as much anymore. They tell AMD what they want to do and AMD eschews an existing chip to do it for them. I know it sounds less glamorous, but honestly, it's the most remarkable thing I've ever seen in the history of modern manufacturing, short of landing on the moon. Having one company able to provide chipsets for any and all applications, including gaming at a practical whim seems pretty amazing. tldr; The consoles are all the same because AMD/nVidia are so much better at hardware design than Microsoft/Sony/Nintendo that it's not even funny anymore. If someone has the latest and greatest already available for licensing, just buy it and get on with making amazing games.
    - andrekandre 6y ago
      > Having one company able to provide chipsets for any and all applications, including gaming at a practical whim seems pretty amazing. its amazing, but is it a good thing? could we say the same about say, amazon?
  - mortenjorck 6y ago
    Did you watch Cerny’s presentation, specifically the part on the custom SSD architecture? I took the opposite conclusion: This is the most innovative development from the console market in possibly decades. They’re throwing everything behind optimizing the SSD-to-VRAM pipeline in a way that component-built PCs won’t be able to do until several new industry standards are developed, with potentially profound impacts on the way games are designed. 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.
    - deelowe 6y ago
      > optimizing the SSD-to-VRAM pipeline in a way that component-built PCs won’t be able to do until several new industry standards are developed, with potentially profound impacts on the way games are designed. What are the innovations? I'm just seeing gen 4 pci-e paired with some sort of nvram solution (details are sparse). Apologies if I'm missing something spectacular here...
      - wtallis 6y ago
        The only really interesting thing is that the console SoCs have decompression offload hardware, so data coming in from the SSD at 4-5GB/s can be unpacked to a 9+GB/s stream of assets, straight into the RAM shared by the CPU and GPU. A desktop PC can easily handle the decompression on the CPU with a combination of higher core counts and higher clock speeds, but then the data still needs to be moved across a PCIe link to the GPU. The SSDs themselves are nothing special, and there's no clear sign of anything else in the storage stack for either new console being novel. It looks like they're improving storage APIs and maybe using an IOMMU, neither of which requires new industry standards for the PC platform.
        mrguyorama 6y ago
        When it comes to graphics assets, they've been stored compressed and decompressed by the GPU on the fly pretty much since early versions of DirectX. What is the innovative part here?
deleted 6y ago
[deleted]
dzeix35wc363CzC 6y ago
For 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 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.
- glandium 6y ago
  Extended version: https://www.youtube.com/watch?v=pSHj5UKSylk https://www.youtube.com/watch?v=pSHj5UKSylk
  - blondin 6y ago
    awesome! thanks for sharing.
  - junke 6y ago
    Andy Gavin (in the video) was also responsible for the development of GOAL, Game Oriented Assembly Lisp (https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp)
    - thomasfortes 6y ago
      Naughty dog (the studio founded by Gavin and Jason Rubin) is also home of the ICE team, a technology hub for Sony titles, I wonder if Sony saw the tech expertise culture in the studio and decided to put a team to handle psx dev tech with them. https://en.m.wikipedia.org/wiki/Naughty_Dog#ICE_Team https://en.m.wikipedia.org/wiki/Naughty_Dog#ICE_Team
- AmericanChopper 6y ago
  Those war stories videos are very interesting and impressive. But I’m personally glad I’ve never been asked to program a video game in assembler using a trackball and no keyboard. https://www.pcmag.com/news/first-kirby-game-was-created-with-a-trackball-no-keyboard https://www.pcmag.com/news/first-kirby-game-was-created-with...
snvzz 6y ago
Neat article, content wise. I wouldn't call it in-depth because it's very high level, but it is neat. The presentation could be made much better by getting rid of those tabbed sections and just making the article one long page.
- flipacholas 6y ago
  Thanks. The reason for the tabs is that each article has many sections (CPU, graphics, audio, etc) so I imagined some people may be more interest particular sections than others. For this, if you find something interesting, you can use the tabs to read more about it. Otherwise, you only have to scroll down a little bit. This behaviour is only found when viewed on a desktop pc by the way, mobile users will see a long page. Anyway, I’m not a professional web designer, the tabs are just an attempt to keep the info concentrated.
  - pixelbath 6y ago
    I liked the tabbed sections, but I feel like they could use some differentiation from the rest of the content. For example, in the "limitations" tabbed section, I had to scroll down and flip through the tabs to determine where the tabbed content ended. Separating this out a little more would make it apparent that "changing this tab only changes this content," something along these lines (rough in-page mockup): https://imgur.com/D2lhOwV https://imgur.com/D2lhOwV
    - flipacholas 6y ago
      That's a nice idea, I'll experiment with it. Cheers
- NikolaNovak 6y ago
  >> making the article one long page. On a desktop at least, let us please not :) * Allow me to understand the structure and length of content I'm entering * Allow me to jump quickly to what I need, now and in the future * Allow me to load only what I want All good things! :)
smaili 6y ago
It blows my mind that the little mobile device in my hand is able to not only render but actually interact with models at the touch of my fingertips that were once only possible with a major home console. How far we’ve come :)
travbrack 6y ago
Spyro looked a lot better without the textures IMO
- serf 6y ago
  Spyro without textures and only gourand shading looks like every mobile game from 2009-2019. From the examples it looks like the textures in Spyro were mostly about hiding all the ugliness around the edges from the straight gourand shader output, aside from the characters.
  - MegaLeon 6y ago
    I think Spyro is one of the best examples of Gouraud shading mastery on the system. The textures are there to add detail, in fact they had a basic LOD system for the environment where they swapped textured models with gouraud shaded models using the same tint for objects far away. The skyboxes were rendered as well as meshes and then shaded, and they still hold up today from an artistic point of view: https://imgur.com/gallery/vocZw https://imgur.com/gallery/vocZw
YaarPodshipnik 6y ago
Another great article about PSX architecture, with regards to the DOOM port specifically: http://fabiensanglard.net/doom_psx/index.html http://fabiensanglard.net/doom_psx/index.html I highly recommend the series about various ports of Another World on the same website as well.
- jasonwatkinspdx 6y ago
  Unfortunately there's no writeup or such about it, but I worked on a doomed (ha!) project to port Unreal 1 to PSX. I was doing level design at the time. The programmers did manage to get a functioning renderer up. It was limited to more simple geometry than the PC software renderer could handle at the time, but still worked enough you could have made a game on it, had other things not gone wrong with the project. If you search for "Unreal PSX" you'll find some work by a couple diehard retro unreal fans to try to finish up some of the partially completed content.
- fabiensanglard 6y ago
  Thanks!
kozak 6y ago
What'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.
- hyperpallium 6y ago
  2000 times more than a ZX81.
  - silvestrov 6y ago
    2000 times better graphics than a ZX81.
    - miskin 6y ago
      It's a matter of perspective. When one witnessed it from times of Pong until now, it is maybe much easier to appreciate the whole journey. I still find myself trying to save bandwidth on my internet connection that was very scarce resource not-that-long-ago. When I see people listening to music via youtube, unnecessarily transfering all that video content that nobody really watch, I want to cry :). Same with programming - going from ZX to where we are now, you can easily feel the luxury of having almost infinite memory and CPU power. And of course, games now are hardly comparable to what we had on ZX. Great thing is to step back and try to program things like Arduino or ESP8266/ESP32 where you, again, have to think twice about resources.
      - bloopernova 6y ago
        How comparable is an ESP32 to a Spectrum 48K? (apart from memory, the esp has many times more to play with)
        miskin 6y ago
        ESP32 is of course so much more powerful than ZX was. I meant that programming of ESP is much different to usual daily job enterprise stuff.
idoby 6y ago
Is "page-flipping" basically double buffering or am I missing something?
- 0xcde4c3db 6y ago
  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 scanned out, but page-flipping has significantly less overhead.
  - idoby 6y ago
    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.
  - wtallis 6y ago
    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.
justlexi93 6y ago
The PlayStation was quite great: a straight forward to use machine with unparalleled (for its time) 3D capabilities. It took several years for PCs to catch up with its capabilities (the first two generations of 3D accelerators for PCs were crap, generally speaking). It's quite amazing what developers were able to push with its hardware. There are some games running at constant 60 fps in high resolutions such as 512x240. I think a "hidden champion" of the Playstation is the sound processor, the SPU, though. It can mix a massive 24 voices of CD-quality audio in realtime while adding effects like reverb. And the hardware support for ADPCM allows you to store huge amounts of audio data in its 512K of memory.
flipacholas 6y ago
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.
- sgwil 6y ago
  I really enjoyed the special features (3d model viewers etc) you added to this article. It's a great presentation and an interesting read.
willis936 6y ago
There’s a lot of awe in the comments about how limitation drove ingenuity. It’s true throughout most of the second half of the 20th century electronics, not just the toys that came at the end. The gameboy is a great example. A Z80 is an incredibly simple thing. You have to sit there and hack together games in assembly, performing all sorts of tricks to keep the memory footprint down. The first speak and spell is another example. I wish I could conjure up more, but basically any novel toy that involved electricity between 1950 and 1970 is a work of art. You don’t need a computer, or even a transistor, to use electronics tools in a creative way to make an interactive toy.
simias 6y ago
>1024×512 pixels with 16-bit colours or a realistic one of 960×512 pixels with 24-bit colours allowing to draw the best frames any game has ever shown… One small detail that I don't see mentioned in the article is that the GPU cannot actually rasterize at 24bpp, only 15bits RGB555. 24bpp is mostly only used to display pre-rendered static images or video decoded by the MDEC. I seem to recall one 2D game that managed to have 24bpp gameplay but it was a clever hack more than anything else. Internally the GPU always functions at 24bpp however, it just dithers and truncates to RGB555 so an emulator can actually remove the truncation and run at 24bpp "natively". Beyond that some of the GPU's limitations can be improved in emulators with more or less complicated hacks. In particular a modification called PGXP can be used to side-channel the depth and sub-pixel precision data to the GPU implementation to allow perspective correct and more precise rendering: https://www.youtube.com/watch?v=-SXT-y0vKv4 https://www.youtube.com/watch?v=-SXT-y0vKv4 It doesn't work perfectly with all games and it's fairly CPU-intensive but it looks pretty decent when it works well. >MIDI sequencing: Apart from playing samples, this chip will also synthesise MIDI-encoded music. I don't know what that means. I implemented the SPU on my emulator a couple of weeks ago and I'm not really sure what that refers to. >The port of the controller and the Memory Card are electrically identical so the address of each one is hardcoded, Sony altered the physical shape of the ports to avoid accidents. To expand on that: the interface always talks to both controller and memory card within the same slot, so when you talk to memory card 1 you also talk to whatever is plugged into the controller port 1. Then in the serial protocol the first byte tells who you're talking to (0x01 for pad, 0x81 for mc), and the other device is supposed to see that and remain in high-z. So actually plugging a memory card in a controller port (or vice-versa) would work, the problem would be if you plugged two memory cards or two controllers in the same port, in which case they'd speak on top of each other. Beyond that the protocol to discuss with the memory card and especially gamepad is, in my opinion, absolutely insane. It's over-complicated and under-featured. It's also incredibly slow (especially for memory card access). Regarding copy protection: >On the other side, this check is only executed once at the start, so manually swapping the disc just after passing the check can defeat this protection... That works with most games, but later games were more clever: you could relock the drive and restart the init sequence early on to see if the drive really recognizes the disc. It was also used as a protection against early modchips: since those would constantly stream the SCEx magic string to unlock the drive (instead of just during the first sectors like a real disc would) you could lock the drive, read some sectors that shouldn't be able to unlock it then re-check. If the drive is unlocked you know there's a modchip and you display a spooky message about piracy. Note that this technique would detect the modchip even when playing with an authentic disc so you'd effectively be unable to play the game at all on modded hardware.
fxtentacle 6y ago
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 getting lost, and all that remains is the large leverage that one can use to drive profits with software.
- TheRealDunkirk 6y ago
  > restarting our ruby development server is so excruciatingly slow Is it running on Windows? (Honest question.)
- Razengan 6y ago
  > 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)
  - inform880 6y ago
    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 the ground.
    - Razengan 6y ago
      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.
louthy 6y ago
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 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.
- pcwalton 6y ago
  > 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 my understanding. (Of course if there's a data dependency on a pending load the CPU still has to stall.)
  - louthy 6y ago

342 points by plerpin 6y ago

It'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 https://www.youtube.com/watch?v=ph8LyNIT9sg (Some Playstation 5 architecture highlights).

Koshkin 6y ago
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 smaller package.)
- softfalcon 6y ago
  Custom architecture was prevalent back then because there weren't any real standards for developing a system that could render 3D graphics. If you wanted 3D rendering, you had to do it yourself. No one was selling you a pre-built stable chip. The now defunct fixed function pipeline was still being formalized in PCs, let alone consoles. Each console was a massive exploration into what could be done and who could make the best SDK for that hardware to entice developers to make games. The fact that all modern consoles and PC's are similar should be applauded. It's the culmination of decades of hardware and software learnings, standardized into the optimal hardware for graphics and game performance. The fact that they all found what they needed in a similar architecture footprint is good for hardware design, good for developers, good for business, good for porting, good for optimization, and finally, good for performance. Sony, Nintendo, and Microsoft are no longer able to design the latest and greatest chipsets. The complexity is just too much for them to reasonably pay to do so. That's why AMD does it for them. Why would you reinvent the wheel when someone has already spent decades making Ferrari's and is begging you to use their engine at a discount, bulk manufacturing included? Back during the PS1, Sony had a heavy hand in the graphics card design. Not as much anymore. They tell AMD what they want to do and AMD eschews an existing chip to do it for them. I know it sounds less glamorous, but honestly, it's the most remarkable thing I've ever seen in the history of modern manufacturing, short of landing on the moon. Having one company able to provide chipsets for any and all applications, including gaming at a practical whim seems pretty amazing. tldr; The consoles are all the same because AMD/nVidia are so much better at hardware design than Microsoft/Sony/Nintendo that it's not even funny anymore. If someone has the latest and greatest already available for licensing, just buy it and get on with making amazing games.
  - andrekandre 6y ago
    > Having one company able to provide chipsets for any and all applications, including gaming at a practical whim seems pretty amazing. its amazing, but is it a good thing? could we say the same about say, amazon?
- mortenjorck 6y ago
  Did you watch Cerny’s presentation, specifically the part on the custom SSD architecture? I took the opposite conclusion: This is the most innovative development from the console market in possibly decades. They’re throwing everything behind optimizing the SSD-to-VRAM pipeline in a way that component-built PCs won’t be able to do until several new industry standards are developed, with potentially profound impacts on the way games are designed. 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.
  - deelowe 6y ago
    > optimizing the SSD-to-VRAM pipeline in a way that component-built PCs won’t be able to do until several new industry standards are developed, with potentially profound impacts on the way games are designed. What are the innovations? I'm just seeing gen 4 pci-e paired with some sort of nvram solution (details are sparse). Apologies if I'm missing something spectacular here...
    - wtallis 6y ago
      The only really interesting thing is that the console SoCs have decompression offload hardware, so data coming in from the SSD at 4-5GB/s can be unpacked to a 9+GB/s stream of assets, straight into the RAM shared by the CPU and GPU. A desktop PC can easily handle the decompression on the CPU with a combination of higher core counts and higher clock speeds, but then the data still needs to be moved across a PCIe link to the GPU. The SSDs themselves are nothing special, and there's no clear sign of anything else in the storage stack for either new console being novel. It looks like they're improving storage APIs and maybe using an IOMMU, neither of which requires new industry standards for the PC platform.
      - mrguyorama 6y ago
        When it comes to graphics assets, they've been stored compressed and decompressed by the GPU on the fly pretty much since early versions of DirectX. What is the innovative part here?

deleted 6y ago

[deleted]

dzeix35wc363CzC 6y ago

For 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 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.

glandium 6y ago
Extended version: https://www.youtube.com/watch?v=pSHj5UKSylk https://www.youtube.com/watch?v=pSHj5UKSylk
- blondin 6y ago
  awesome! thanks for sharing.
- junke 6y ago
  Andy Gavin (in the video) was also responsible for the development of GOAL, Game Oriented Assembly Lisp (https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp)
  - thomasfortes 6y ago
    Naughty dog (the studio founded by Gavin and Jason Rubin) is also home of the ICE team, a technology hub for Sony titles, I wonder if Sony saw the tech expertise culture in the studio and decided to put a team to handle psx dev tech with them. https://en.m.wikipedia.org/wiki/Naughty_Dog#ICE_Team https://en.m.wikipedia.org/wiki/Naughty_Dog#ICE_Team
AmericanChopper 6y ago
Those war stories videos are very interesting and impressive. But I’m personally glad I’ve never been asked to program a video game in assembler using a trackball and no keyboard. https://www.pcmag.com/news/first-kirby-game-was-created-with-a-trackball-no-keyboard https://www.pcmag.com/news/first-kirby-game-was-created-with...

snvzz 6y ago

Neat article, content wise. I wouldn't call it in-depth because it's very high level, but it is neat. The presentation could be made much better by getting rid of those tabbed sections and just making the article one long page.

flipacholas 6y ago
Thanks. The reason for the tabs is that each article has many sections (CPU, graphics, audio, etc) so I imagined some people may be more interest particular sections than others. For this, if you find something interesting, you can use the tabs to read more about it. Otherwise, you only have to scroll down a little bit. This behaviour is only found when viewed on a desktop pc by the way, mobile users will see a long page. Anyway, I’m not a professional web designer, the tabs are just an attempt to keep the info concentrated.
- pixelbath 6y ago
  I liked the tabbed sections, but I feel like they could use some differentiation from the rest of the content. For example, in the "limitations" tabbed section, I had to scroll down and flip through the tabs to determine where the tabbed content ended. Separating this out a little more would make it apparent that "changing this tab only changes this content," something along these lines (rough in-page mockup): https://imgur.com/D2lhOwV https://imgur.com/D2lhOwV
  - flipacholas 6y ago
    That's a nice idea, I'll experiment with it. Cheers
NikolaNovak 6y ago
>> making the article one long page. On a desktop at least, let us please not :) * Allow me to understand the structure and length of content I'm entering * Allow me to jump quickly to what I need, now and in the future * Allow me to load only what I want All good things! :)

smaili 6y ago

It blows my mind that the little mobile device in my hand is able to not only render but actually interact with models at the touch of my fingertips that were once only possible with a major home console. How far we’ve come :)

travbrack 6y ago

Spyro looked a lot better without the textures IMO

serf 6y ago
Spyro without textures and only gourand shading looks like every mobile game from 2009-2019. From the examples it looks like the textures in Spyro were mostly about hiding all the ugliness around the edges from the straight gourand shader output, aside from the characters.
- MegaLeon 6y ago
  I think Spyro is one of the best examples of Gouraud shading mastery on the system. The textures are there to add detail, in fact they had a basic LOD system for the environment where they swapped textured models with gouraud shaded models using the same tint for objects far away. The skyboxes were rendered as well as meshes and then shaded, and they still hold up today from an artistic point of view: https://imgur.com/gallery/vocZw https://imgur.com/gallery/vocZw

YaarPodshipnik 6y ago

Another great article about PSX architecture, with regards to the DOOM port specifically: http://fabiensanglard.net/doom_psx/index.html http://fabiensanglard.net/doom_psx/index.html I highly recommend the series about various ports of Another World on the same website as well.

jasonwatkinspdx 6y ago
Unfortunately there's no writeup or such about it, but I worked on a doomed (ha!) project to port Unreal 1 to PSX. I was doing level design at the time. The programmers did manage to get a functioning renderer up. It was limited to more simple geometry than the PC software renderer could handle at the time, but still worked enough you could have made a game on it, had other things not gone wrong with the project. If you search for "Unreal PSX" you'll find some work by a couple diehard retro unreal fans to try to finish up some of the partially completed content.
fabiensanglard 6y ago
Thanks!

kozak 6y ago

What'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.

hyperpallium 6y ago
2000 times more than a ZX81.
- silvestrov 6y ago
  2000 times better graphics than a ZX81.
  - miskin 6y ago
    It's a matter of perspective. When one witnessed it from times of Pong until now, it is maybe much easier to appreciate the whole journey. I still find myself trying to save bandwidth on my internet connection that was very scarce resource not-that-long-ago. When I see people listening to music via youtube, unnecessarily transfering all that video content that nobody really watch, I want to cry :). Same with programming - going from ZX to where we are now, you can easily feel the luxury of having almost infinite memory and CPU power. And of course, games now are hardly comparable to what we had on ZX. Great thing is to step back and try to program things like Arduino or ESP8266/ESP32 where you, again, have to think twice about resources.
    - bloopernova 6y ago
      How comparable is an ESP32 to a Spectrum 48K? (apart from memory, the esp has many times more to play with)
      - miskin 6y ago
        ESP32 is of course so much more powerful than ZX was. I meant that programming of ESP is much different to usual daily job enterprise stuff.

idoby 6y ago

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

0xcde4c3db 6y ago
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 scanned out, but page-flipping has significantly less overhead.
- idoby 6y ago
  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.
- wtallis 6y ago
  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.

justlexi93 6y ago

The PlayStation was quite great: a straight forward to use machine with unparalleled (for its time) 3D capabilities. It took several years for PCs to catch up with its capabilities (the first two generations of 3D accelerators for PCs were crap, generally speaking). It's quite amazing what developers were able to push with its hardware. There are some games running at constant 60 fps in high resolutions such as 512x240. I think a "hidden champion" of the Playstation is the sound processor, the SPU, though. It can mix a massive 24 voices of CD-quality audio in realtime while adding effects like reverb. And the hardware support for ADPCM allows you to store huge amounts of audio data in its 512K of memory.

flipacholas 6y ago

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.

sgwil 6y ago
I really enjoyed the special features (3d model viewers etc) you added to this article. It's a great presentation and an interesting read.

willis936 6y ago

There’s a lot of awe in the comments about how limitation drove ingenuity. It’s true throughout most of the second half of the 20th century electronics, not just the toys that came at the end. The gameboy is a great example. A Z80 is an incredibly simple thing. You have to sit there and hack together games in assembly, performing all sorts of tricks to keep the memory footprint down. The first speak and spell is another example. I wish I could conjure up more, but basically any novel toy that involved electricity between 1950 and 1970 is a work of art. You don’t need a computer, or even a transistor, to use electronics tools in a creative way to make an interactive toy.

simias 6y ago

>1024×512 pixels with 16-bit colours or a realistic one of 960×512 pixels with 24-bit colours allowing to draw the best frames any game has ever shown… One small detail that I don't see mentioned in the article is that the GPU cannot actually rasterize at 24bpp, only 15bits RGB555. 24bpp is mostly only used to display pre-rendered static images or video decoded by the MDEC. I seem to recall one 2D game that managed to have 24bpp gameplay but it was a clever hack more than anything else. Internally the GPU always functions at 24bpp however, it just dithers and truncates to RGB555 so an emulator can actually remove the truncation and run at 24bpp "natively". Beyond that some of the GPU's limitations can be improved in emulators with more or less complicated hacks. In particular a modification called PGXP can be used to side-channel the depth and sub-pixel precision data to the GPU implementation to allow perspective correct and more precise rendering: https://www.youtube.com/watch?v=-SXT-y0vKv4 https://www.youtube.com/watch?v=-SXT-y0vKv4 It doesn't work perfectly with all games and it's fairly CPU-intensive but it looks pretty decent when it works well. >MIDI sequencing: Apart from playing samples, this chip will also synthesise MIDI-encoded music. I don't know what that means. I implemented the SPU on my emulator a couple of weeks ago and I'm not really sure what that refers to. >The port of the controller and the Memory Card are electrically identical so the address of each one is hardcoded, Sony altered the physical shape of the ports to avoid accidents. To expand on that: the interface always talks to both controller and memory card within the same slot, so when you talk to memory card 1 you also talk to whatever is plugged into the controller port 1. Then in the serial protocol the first byte tells who you're talking to (0x01 for pad, 0x81 for mc), and the other device is supposed to see that and remain in high-z. So actually plugging a memory card in a controller port (or vice-versa) would work, the problem would be if you plugged two memory cards or two controllers in the same port, in which case they'd speak on top of each other. Beyond that the protocol to discuss with the memory card and especially gamepad is, in my opinion, absolutely insane. It's over-complicated and under-featured. It's also incredibly slow (especially for memory card access). Regarding copy protection: >On the other side, this check is only executed once at the start, so manually swapping the disc just after passing the check can defeat this protection... That works with most games, but later games were more clever: you could relock the drive and restart the init sequence early on to see if the drive really recognizes the disc. It was also used as a protection against early modchips: since those would constantly stream the SCEx magic string to unlock the drive (instead of just during the first sectors like a real disc would) you could lock the drive, read some sectors that shouldn't be able to unlock it then re-check. If the drive is unlocked you know there's a modchip and you display a spooky message about piracy. Note that this technique would detect the modchip even when playing with an authentic disc so you'd effectively be unable to play the game at all on modded hardware.

fxtentacle 6y ago

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 getting lost, and all that remains is the large leverage that one can use to drive profits with software.

TheRealDunkirk 6y ago
> restarting our ruby development server is so excruciatingly slow Is it running on Windows? (Honest question.)
Razengan 6y ago
> 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)
- inform880 6y ago
  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 the ground.
  - Razengan 6y ago
    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.

louthy 6y ago

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

pcwalton 6y ago
> 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 my understanding. (Of course if there's a data dependency on a pending load the CPU still has to stall.)
- louthy 6y ago