On the PS1 it's actually slightly more complex than that. The CPU does support up to 16 MB of main RAM (development kits and PS1-based arcade systems did come fitted with more than 2 MB) and has a register to configure its geometry, with the CPU automatically generating an exception when attempting to access unmapped memory. However, Sony's BIOS made the mistake of initializing said register to 8 MB (the configuration used by dev boards) even on retail hardware, resulting in the 2 MB region being mirrored four times. Development builds of games typically assumed 8 MB and put the stack at 0x80800000, so the accidental mirroring made that setup work on retail hardware too (at least as long as the stack did not collide with the heap) even if the developer forgot to move the stack down in the final build.
It does. The SPU only handles decoding and playback of ADPCM samples from its own memory and receives all CD audio from an I2S bus; the CD-ROM sector decoder chip handles XA-ADPCM decoding and resampling to 44.1 KHz internally, then sends the audio over I2S as if it were CD-DA. This is also why the SPU's ADPCM format is slightly different from XA-ADPCM (no interleaving and 5 filter coefficient presets rather than just the 4 used by XA-ADPCM and the older ADPCM format used on the SNES).
I would recommend trying out Snow (https://snowemu.com/), a somewhat recently released 68000 Macintosh emulator that is cross-platform and focuses on low-level accuracy, unlike prior efforts which traditionally preferred HLE approaches and suffered from compatibility issues as a result.
As with any other emulator, you will have to obtain system ROM dumps and disk images of the software you want to run. There is no clear precedent on the legality of acquiring said files through any means, however it's generally believed that you should be in the clear if you dump them yourself from a Mac you own and an original physical copy of the software. Of course, doing so is non-trivial and requires at the very least a working Mac and a way to get files in and out of it (e.g. a SCSI drive emulator that uses an SD card for storage), so it's understandable why virtually everyone resorts to the gray area approach of downloading ROMs instead.
The "hard work" in question is a death sentence for computing as we know it today. All implementations of zero-knowledge proofs require device integrity assurance to prevent the otherwise anonymous tokens from being passed onto another user, and Google has a vested interest in pushing solutions involving remote attestation as they would double as an effective weapon against ad blocking, YouTube downloaders, pirated games, sideloaded apps that don't pay the Play Store tax and more. Requiring remote attestation on all internet-connected devices would result in the complete overnight death of desktop Linux, contribute significantly to e-waste and pave the road for further initiatives such as mandatory client-side scanning of all files (of the kind Apple attempted to introduce not too long ago, with massive backlash); I am not sure this would be preferable to simply handing over your ID.
In case anybody here is interested, a few years ago I put together a similar (albeit far less comprehensive) resource on original PlayStation programming [1], exploring the GPU, geometry coprocessor and serial I/O hardware step-by-step with plain C examples. I'm planning to extend it with more examples covering audio and CD-ROM access next, but haven't yet had the chance to do so.
Almost all IDE and SCSI CD-ROM drives were indeed capable of playing audio CDs fully autonomously, with the host PC basically only sending them the command to start playing; many drives took it one step further and provided a play button in addition to the usual eject button, which worked even if the drive wasn't plugged at all into a machine. The audio was typically output both to the front panel headphone jack and to a 4-pin connector on the back of the drive, which you were supposed to connect to one of your sound card's aux inputs so that it would get mixed into the system audio output.
Unfortunately, a decent number of machines were not fitted with the relevant cable. Combined with the low-quality DACs that most drives used, the compatibility issues that plagued ATAPI implementations and the dramatic increase in CPU power and sound card quality throughout the mid-to-late 90s, this led media player software to quickly move on from drive based playback to so-called "digital audio extraction", where the CD is basically ripped in real time and streamed to your sound card's own DAC. Thus, unless you played older games that relied on hardware CD-DA playback [1], it's somewhat unlikely you ever experienced it under, say, Windows 98 or XP.
[1] As offloading playback to the drive had no CPU overhead, games often stored their music as additional tracks on the game disc and played it that way. Incidentally, basically all CD-ROM-based game consoles and arcade systems relied heavily on hardware accelerated playback as well, with some going even further and allowing for compressed (ADPCM) CD audio streaming with no CPU intervention.
Solutions based on zero-knowledge-proofs would solve the privacy aspect at the massive cost of killing general purpose computing as we know it today, by mandating the use of remote device attestation (as that is the only way to guarantee an otherwise fully anonymous token is not being sniffed and passed onto someone else). That would be in my opinion significantly more dystopian than every service having a copy of my ID, as it would lay the groundwork for corporations and governments to be able to dictate what you can and cannot do exactly with any internet-connected device.
It's not hard for instance to imagine that once every computing device available to the general public is locked down and cannot be jailbroken without also losing the ability to log into any online service, a law would be introduced requiring client-side scanning of all files to check for CSAM, evidence of political dissent or even just plain old movie piracy. The technology to implement this exists (see what Apple tried to do a few years ago) and the exact same legislation is currently being pushed in the 3D printing space, so these fears are not unfounded.
The even worse part about PayPal is that they have a whole system of nonsensical fees to fall back to when you inevitably figure out how to evade the obvious ones. For instance, sidestepping their dynamic currency conversion by temporarily changing which currency they bill on your card (which by the way is rate limited to only a few times per month) will result in another "non-foreign transaction but with recipient in foreign country" fee appearing, covering the inherent costs of converting German US dollars to American US dollars or whatever. They will at least hide the fee from you for business transactions, but the merchant still has to pay it.
A similar, even higher profile case that shook the electronics industry around a decade ago was chip manufacturer FTDI releasing an update to their drivers that would detect and semi-permanently brick clones of FTDI USB serial bridge chips [1]. The bricking was performed by setting the USB product ID to zero, preventing Windows and macOS from detecting the device at all; the Linux drivers quickly got updated to recognize the new PID, allowing for the development of unbricking tools. Somewhat ironically, the detection relied on errata of the original parts that the clones fixed [2].
The backlash to this measure was massive, as many legitimate products turned out to use counterfeit FTDI parts without the manufacturers' awareness due to unreliable supply chains. Microsoft quickly pulled the update but FTDI seemed not to care for the most part, eventually releasing another similar update a couple of years later that would deliberately corrupt all data sent through clone chips.
Plenty of low-volume industrial software has never really moved on from security dongles. Most modern arcade games for instance still rely on a USB dongle to decrypt game files [1], though nowadays they typically also come with an additional layer of TPM-backed encryption as well as always online DRM (many of them are region locked and operate on a revenue share contract, where the owner has to pay a per-play fee to the game manufacturer).
These measures typically work well against piracy in the markets the game is officially distributed in (mainly Japan), but end up being cracked anyway once the game is popular enough that foreign arcades and private owners start importing older decommissioned cabinets and create demand for a way to get them running again without depending on the manufacturer's servers.
Bayer dithering was also employed heavily on the original PlayStation. The PS1's GPU was capable of Gouraud shading with 24-bit color precision, but the limited capacity (1 MB) and bandwidth of VRAM made it preferable to use 16-bit framebuffers and textures. In an attempt to make the resulting color bands less noticeable, Sony thus added the ability to dither pixels written to the framebuffer on-the-fly using a 4x4 Bayer matrix hardcoded in the GPU [1]. On a period-accurate CRT TV using a cheap composite video cable, the picture would get blurred enough to hide away the dithering artifacts; obviously an emulator or a modern LCD TV will quickly reveal them, resulting in a distinct grainy look that is often replicated in modern "PS1-style" indie games.
Interestingly enough, despite the GPU being completely incapable of "true" 24-bit rendering, Sony decided to ship the PS1 with a 24-bit video DAC and the ability to display 24-bit framebuffers regardless. This ended up being used mainly for title screens and video playback, as the PS1's hardware MJPEG decoder retained support for 24-bit output.
While great on paper, zero-knowledge-proof based systems unfortunately have a fatal flaw. Due to the fully anonymous nature of verification tokens, implementations must have safeguards in place to prevent users from intercepting them and passing them onto someone else; in practice, this will likely be accomplished by making both the authenticator and the target service mobile apps that rely on device integrity APIs. This would ultimately result in the same accessibility issues that currently plague the banking industry, where it is no longer possible to own a bank account in most countries without an unmodified, up-to-date phone and an Apple or Google account that did not get banned for redeeming a gift card.
Furthermore, if implementers are going to be required to verify users per-session rather than only once during signup, such a measure would end up killing desktop Linux (if not desktop PCs as a whole) by making it impossible for any non-locked-down platform to access the vast majority of the web.
If we truly want to point out the ridiculousness of Italian tech regulations, the influencers' registry, the temporary ChatGPT ban from a few years back or even the new AI regulations cannot hold a candle to the 22-year-old war on... arcade games.
A poorly written regulation from 2003 basically lumped together all gaming machines in a public setting with gambling, resulting in extremely onerous source code and server auditing requirements for any arcade cabinet connected to the internet (the law even goes as far as to specify that the code shall be delivered on CD-ROMs and compile on specific outdated Windows versions) as well as other certification burdens for new offline games and conversions of existing machines. Every Italian arcade has remained more or less frozen in time ever since, with the occasional addition of games modded to state on the title screen that they are a completely different cabinet (such as the infamous "Dance Dance Revolution NAOMI Universal") in an attempt to get around the certification requirements.
Custom Flash players were actually relatively common in game development during the mid to late 2000s, as Flash provided a ready-to-go authoring solution for UI and 2D animation that artists were already familiar with. Autodesk's Scaleform was probably the most popular implementation but a number of AAA developers had their own in-house libraries similar to Doom 3's; some of them, such as Konami's "AFP" [1], are still in use to this day (the latest game to use it, Sound Voltex Nabla, was released last month).
It is actually much worse than that. Much like banking, the push for digital government services in many countries has ended up more or less requiring every citizen to own an up-to-date, non-jailbroken iOS or Android device. If you blocked your phone from accessing Apple or Google servers (or if it's 6 years old, a dumb phone or runs GrapheneOS), the support staff will just tell you to walk to your closest Best Buy equivalent and grab the cheapest Android device you can find; in the name of "security" there often is no fallback option, and when there is one it's SMS 2FA which is (understandably) rate limited to three uses per year.
If your phone gets stolen, meanwhile, you may find yourself unable to log into the police's portal for reporting it.
It's not just a multiplication instruction. The CPU is equipped with a fixed-point coprocessor to accelerate the most common computations in 3D games, the geometry transformation engine [1], capable of carrying them out much faster than the CPU alone could. For instance, the GTE can apply a transformation matrix to three vertices and project them in 23 cycles, while the CPU's own multiplier takes up to 13 cycles for a single multiplication and 36 (!) for a division. Combined with a few other "tricks" such as a DMA unit capable of parsing linked lists (which lets the CPU bucket sort polygons on the fly rather than having to emit them back-to-front in the first place), it allowed games to push a decent number of polygons (typically around 1-3k per frame) despite the somewhat subpar performance of the cache-less MIPS R3000 derivative Sony chose.
If you have some basic familiarity with C, you can see both the GTE and the Z bucket sorting of GPU commands in action in the cube example I linked in the parent comment.
It has been enabled mainly by the the advent of streamlined tooling to assist with 1:1 byte-by-byte matching decompilations (https://decomp.me/ comes to mind), which allows new projects to get off the ground right away without having to reinvent basic infrastructure for disassembling, recompiling and matching code against the original binary first. The growth of decompilation communities and the introduction of "porting layers" that mimic console SDK APIs but emulate the underlying hardware have also played a role, though porting decompiled code to a modern platform remains very far from trivial.
That said, there is an argument to be made against matching decompilations: while their nature guarantees that they will replicate the exact behavior of the original code, getting them to match often involves fighting the entropy of a 20-to-30-year-old proprietary toolchain, hacks of the "add an empty asm() block exactly here" variety and in some cases fuzzing or even decompiling the compiler itself to better understand how e.g. the linking order is determined. This can be a huge amount of effort that in many cases would be better spent further cleaning up, optimizing and/or documenting the code, particularly if the end goal is to port the game to other platforms.
The PS1's GPU does not support perspective correction at all; it doesn't even receive homogeneous 3D vertex coordinates, instead operating entirely in 2D screen space and leaving both 3D transformations and Z-sorting to the CPU [1]. While it is possible to perform perspective correct rendering in software, doing so in practice is extremely slow and the few games that pull it off are only able to do so by optimizing for a special case (see for instance the PS1 version of Doom rendering perspective correct walls by abusing polygons as "textured lines" [2]).
If anybody here wants to learn more about console graphics specifically, I think the original PlayStation is a good starting point since it's basically the earliest and simplest 3D-capable (though it would be more correct to say triangle capable, as it does not take Z coordinates at all!) GPU that still bears a vague resemblance to modern shader-based graphics pipelines. A few years ago I wrote a handful of bare metal C examples demonstrating its usage at the register level [1]; if it weren't for my lack of spare time over the last year I would have added more examples covering other parts of the console's hardware as well.
I'm late to the party but, as a prolific contributor to PSn00bSDK and the PS1 homebrew scene more in general, I feel obliged to shamelessly plug my own "PlayStation 1 demystified at the absolute lowest level" repo:
It's still very work in progress - I have only covered a tiny fraction of what the console's hardware can do - but I find it fascinating to explore how little code you actually need to get started on such a simple platform, even with no external SDKs or tools (aside from a completely standard MIPS GCC toolchain).
[1] https://psx-spx.consoledev.net/memorycontrol/#1f801060h-ram_...