Playstation Architecture: A Practical Analysis
copetti.org
copetti.org
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.
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.)
And you had to do the work that an optimizing compiler could do today, although they have to target a "theoretical" CPU rather than a fixed hardware set like the old consoles.
Since all the superscalar tricks such as out of order, spec exec, and the like are now maxed out, maybe what should happen is that CPU vendors should concentrate on optimizing a fixed VM-sized hardware profile that the compilers can more efficiently target.
A CPU ISA is somewhat like that, but it has so much variance.
With Moore's law gone, we will actually have to start removing abstraction from the development pipeline and get to more optimized and direct code to drive performance.
How Crash Bandicoot Hacked The Original Playstation
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.
https://www.pcmag.com/news/first-kirby-game-was-created-with...
It's just too bad somewhere along the way they forgot games were supposed to be fun as they were slapping eachother's backs over how ingenious they were to be able to render every flea and tick on a horse's asshole while you clean it out and feed them a carrot.
I happened to already be half-way through the extended "war stories" interview on the making of Crash you had done and it is superb; you are a joy to listen to! I remember reading these blog articles of yours many years ago but will definitely be revisiting!
As an aspiring hobbiest game developer, I often feel I have missed out on this golden age of game development - where you really had to think outside the box and hack your way around the architecture to achieve your design and performance goals.
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.
Is it running on Windows? (Honest question.)
Too many lazy/greedy developers fighting against users and operating systems (coughelectroncough)
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.
All that said desktop development is an interesting challenge, if sometimes maddening.
Is laziness a good excuse for poor software? For wasting the time and resources of every one who uses the application? For disregarding the conventions of the host platform including any user preferences and accessibility features?
I don't believe this argument for a second, with the ubiquitousness of successful Electron apps.
Sure, you can run some sort of Java VM on a lot of platforms. That's no big distinction, you can say the same about Javascript, Python, Lua and so on.
Once you enter the realm of graphical applications, it's a clusterfuck, just like any other "cross-platform" thing.
This is the tendency for any craft that gains popularity over time. We can only advocate best practices by making them accessible, approachable and applicable. We can then hope the crowd listens and if they don't, that's ok, it's their loss (or not if their audience doesn't care).
A good analogy is, you don't have to build an earthquake resistant building if you are gonna use it to store some metal junk (carpenter tools, gardening tools etc). It's not a house and there is no danger even if you live on top of an active fault line.
Hard to find time for when you have 30 JIRA tickets every two-week "sprint", none of which have anything to do with improving performance.
I think it's because businesses have figured out that it is most cost-efficient to throw powerful hardware on problems rather than spending money on bespoke solutions or specialists in most cases.
I have a friend I play go with that is an old Univac programmer (he's 30 years older than me) and he often pulls the "call me when you have to use punch cards".
Developers always look back on the past a bit wistfully, but I assure you that some things never change.
This applies to general software too, things that weren't big deal/non-existent in 90's are important now, security, networking, OS native UI frameworks. The OS itself doesn't give you FFA access to the machine anyway.
Also if you really wanted, instead of using Ruby you could bang out a backend/REST API using assembly[1]/C[2] even today, just that nobody wants to do that because it's a fucking pain in the ass.
[1] https://asm32.info/index.cgi?page=content/0_MiniMagAsm/index...
[2] https://kore.io/
https://www.youtube.com/watch?v=ph8LyNIT9sg (Some Playstation 5 architecture highlights).
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.
its amazing, but is it a good thing?
could we say the same about say, amazon?
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.
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...
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.
I highly recommend the series about various ports of Another World on the same website as well.
Say for (a silly) example you want the first 10 000 digits of Pi. It's pretty easy to just store that today. But back then you didn't just have to know what Pi is, you had to have the smallest program to calculate it that you can think of.
Would be interesting to hear too how Tekken 3's coders managed to work with 2 MB of RAM.
Everything is going through the prism of "but how much will it cost in terms of performance? Granted, this should be the case for server software as well, but in case of clients, you don't know what ghetto shit your code will run on - you write for the worst possible case. Server specs are unknown.
I can hit cmd+ and cmd- to scale their content and UI up and down.
That is dang near a killer feature for me.
Very handy for presenting, screen sharing, when I move my apps to an external monitor with a slightly different UI, or for moments when my eyes are simply tired and I want something easy to read.
You can say that I shouldn't need hundreds of MB of RAM to run Slack's desktop client, and you ain't wrong, but I've got plenty of RAM. My eyes and my time are much more finite resources.
Sure, we used Assembly when performance was the ultimate goal, but also plenty of high level languages, including stuff like Clipper for database front ends.
512 KB with a couple of MHz are already capable of doing a lot of stuff, one just needs to actually think how to properly implement it.
Short answer, Parkinson's law.
When I browse the Web, open my Windows File Explorer, open Photoshop, open Visual Studio, open just a graphical application that needs GPU acceleration, or do whatever thing that should not be an issue, I find that Parkinson's law very much applies.
https://youtu.be/GC-0tCy4P1U?t=1727
https://youtu.be/GC-0tCy4P1U?t=2172
https://twitter.com/rogerclark/status/1247299730314416128
Wtf. Did you see how fast VS6 started on a machine from almost 20 years ago. Today I get depressed whenever I need to open Visual Studio, and I don't even know that I use any more functionality that wasn't available 20 years ago.
Many many programmers (in my perception at least) are extremely dissatisfied with today's state of computing, and the reason why we got here is the popular opinion that we don't need to worry about performance.
Nobody should optimize representations of Pi or count CPU cycles by default. That's not the point. But if you claim that Java is always fast enough for example, then I think we're having a strong disagreement. It's partly confirmation bias and being unaware of vast parts of the landscape, but it's also a fact, that I couldn't name you a complex GUI written in Java with satisfying ergonomics.
The problem is that mechanical sympathy seems to be a lost art, and it is going to be slow as molasses regardless of the language being used.
What to expect when Electron is the new darling for writing desktop applications?
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 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
The problem is what Java encourages you to do. And I didn't want to single out a language; Java is just one that I revisit from time to time and I'm always astonished how awkwardly hard it is to do the simplest things in a straightforward (and CPU-efficient) way.
And yes, there are a lot of slow C++ programs, and even slow C programs. There's just a clear tendency for C programs to be faster and more responsive.
I was involved in a massive rewrite of a website from C to Java a while back. One coworker observed that, when they were coding in C, it took a lot longer to get anything working, but once you did, it was pretty solid: C had a tendency to just crash if anything was wrong, so you'd work for quite a while before you got something that didn't crash consistently. Java, on the other hand, allowed you to get something working (that is, running without crashing) much quicker: but the things that were out of place were still there, they just caused harder-to-find problems that were much more likely to become customer-facing before they were caught.
I read once that adobe acrobat has thousands of static variables that initialize on startup. Multiple pdf readers like sumatraPdf are successful largely because of their bloat and start up time.
It's crazy what happens when programming teams have no priority for not wasting user's time and computer resources.
VSCode is electron.
If they had kept maintaining the old thing maybe they would experience less performance issues, which you say is suffering from age, but actually they threw out the old thing and rewrote on costlier and more recent frameworks.
OTOH, the only people who can think how to properly implement it are people who are also perfectly comfortable with Assembly, C or C++.
However, I know from former university friends, that eventually became TAs, that was what required from students was kept at the same level of requirements.
The professor responsible for the class, had a battery of tests (almost a decade before unit tests became a known term), and having the tests green was the first requirement to even accept the class projects.
Those tests did not only test for correctness, performance, memory consumption and execution time were all part of the acceptance criteria.
This is what is missing from many teaching institutions.
A floating point division on two three digit numbers used to be used as a good enough approximation to 𝛑.
The presentation could be made much better by getting rid of those tabbed sections and just making the article one long page.
Anyway, I’m not a professional web designer, the tabs are just an attempt to keep the info concentrated.
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! :)
Otherwise a copy is required into a hardcoded address or physical memory, and then you're not double-buffering anymore.
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.
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.
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