Playstation Architecture: A Practical Analysis

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.

Yep, turning my computer into a heater doing cold winter.

Sometimes it is really important.

>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

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.

I totally agree that the problem is lack of mechanical sympathy.

A big problem is simply that software development is too hyped, and there is too much money in the industry, so there are too many unexperienced developers bringing bad software. Also, projects are too ambitious, leading to compartmentalization of implementation, leading to slow and unreliable code. The problem often starts already with the things that people want to build.

And my guess is that the use of Java and other object languages is highly correlated with these developments.

Java (the language) is not especially slow; back in the mid 2000s I was optimising a Java GUI to display hundreds of thousands of nodes for chip design clock trees.

Java (the culture) makes it hard to be performant. There's a great tendency to use all sorts of frameworks and elaborate object systems where much simpler code would give you at least 90% of the functionality for 10x the performance.

But if you get some programmers with experience beyond Java who care about performance and are rewarded for performance, it's certainly possible.

I briefly wondered whether the demoscene ever had a go at Java, and indeed they did: http://www.theparty.dk/wiki/Java_Demo_1999 / https://www.youtube.com/watch?v=91HzuGqpTHo