spicyjpeg

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.

[1] https://psx-spx.consoledev.net/memorycontrol/#1f801060h-ram_...

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.

[1] https://github.com/spicyjpeg/ps1-bare-metal

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.

[1] https://en.wikipedia.org/wiki/FTDI#Driver_controversy

[2] https://github.com/therealdreg/ftdibrick#diving-deep

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.

[1] https://mon.im/2017/12/konami-arcade-drm

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.

[1] https://psx-spx.consoledev.net/graphicsprocessingunitgpu/#24...

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

[1] https://github.com/DragonMinded/bemaniutils/blob/trunk/beman...

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.

[1] https://psx-spx.consoledev.net/geometrytransformationengineg...

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

[1] https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/08... - bit of a shameless plug, but notice how the Z coordinates are never sent to the GPU in this example.

[2] https://fabiensanglard.net/doom_psx/index.html

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.

[1] https://github.com/spicyjpeg/ps1-bare-metal

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:

https://github.com/spicyjpeg/ps1-bare-metal

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

Flat triangles and trapezoids are sometimes used internally by these GPUs as a building block for other polygons, possibly since the logic to split up triangles and quads into flat trapezoids may have taken less die space than a rasterizer capable of handling three edge equations at a time rather than just two.

While exposing these lower level internal primitives typically did not make sense for general purpose graphics accelerators, some in-house embedded implementations did actually go further and only supported flat trapezoids, relying on the CPU to preprocess more complex shapes. For instance, the "SOLO" ASIC used in second-generation WebTV boxes took this approach [1] (among other interesting cost-cutting measures such as operating natively in YUV color space).

[1] http://wiki.webtv.zone/misc/SOLO1/SOLO1_ASIC_Spec.pdf (warning: 200 MB scan)

You can buy off-the-shelf modules that take a lithium ion cell and provide charging, overcurrent and overdischarge protection; just search your Chinese online retailer of choice for "TP4056 module" and you will find plenty of them. There is a Hackaday article [1] that goes in depth on how to use them properly.

If you'd rather not wire it up yourself there are also ESP32 dev boards with built-in battery management functionality, such as the LoLin32 Lite and Sparkfun ESP32 Thing. I haven't had much luck with the former (possibly due to its lack of RF shielding) but the latter seems to be pretty solid. I think Adafruit sells similar boards as well.

[1] https://hackaday.com/2022/10/10/lithium-ion-battery-circuitr...

There are homebrew tools that can be installed on a PS1 memory card [1] and allow for executables to be loaded from a host machine into RAM through the serial port on the back of the console, in a similar way to what Sony's official Net Yaroze loader did back in the day. These tools can also use undocumented CD-ROM drive commands to disable region checks without the need for a modchip, provide semihosting (host filesystem access) and so on.

On the PS2 it's slightly more complicated, as there is no way to launch the "native" PS1 backwards compatibility mode other than to use a modchip (or firmware mod on some models) and burn the executable onto a disc; the serial port is not exposed either, making debugging much harder. It can still be done, but it's much easier to just use an actual PS1.

[1] https://github.com/JonathanDotCel/unirom8_bootdisc_and_firmw...

Not directly related to the course, but, should anybody want to see what programming on the PS1 would look like using only modern tools (latest GCC, CMake, no third party libraries), I've written a few bare metal C examples that explain in depth how the console's hardware works [1]. Currently only graphics and input are covered, but I'm planning to add examples showing how to handle interrupts, play audio and access the CD-ROM next.

[1] https://github.com/spicyjpeg/ps1-bare-metal

PSn00bSDK maintainer here. Unfortunately the project cannot really be considered clean room; the original versions of most libraries contained code that was either lifted straight from Psy-Q disassemblies or heavily inspired by them. I have since rewritten pretty much all of it (with the exception of the GTE library which still has some Sony code) using only Psy-Q API documentation as a reference, but the "ship of Theseus" nature of the rewrite makes it hard to argue that it is a clean and legally safe project.

On the flip side, there are plenty of other open source PS1 SDK options that have been written from scratch, do not reimplement the same API as Psy-Q and can thus be considered clean for the most part. Here's a few of them:

- https://github.com/grumpycoders/pcsx-redux/tree/main/src/mip...

- https://github.com/ChenThread/candyk-psx

- https://github.com/cuckydev/CKSDK

- https://github.com/spicyjpeg/ps1-bare-metal (shameless plug)

There definitely is one [1], albeit perhaps not as large and active as the homebrew communities for 8/16 bit consoles (which benefit from low-code tools such as GB Studio and the ability to sell physical game cartridges that do not require modchips) or more modern ones (which tend to have a much lower barrier to entry, given the better specs and availability of SDL ports and whatnot). It is definitely growing though, as I'm seeing more and more people get interested in developing for the PS1.

[1] https://psx.dev/

For those interested in the technical details of the Clapper's clap detection, the patent the article links to [1] is definitely worth taking a look at. Not only does it feature detailed explanations and flowcharts of the algorithm, but page 13 even has a full source code listing of the firmware that runs on the Clapper's ST6210 microcontroller - which, in true "there's a 6502 inside every toy" fashion, has a very blatantly 6502-inspired architecture [2].

[1] https://patents.google.com/patent/US5493618A

[2] https://www.st.com/en/microcontrollers-microprocessors/st621...

I apologize for sounding offensive or otherwise dismissive of the discovery. I'm just clarifying what this actually is, as I have already seen discussions on Discord about this being a "game changing" exploit that will make copies of Alien Resurrection impossible to obtain for reasonable prices, or that it would have killed the console if it was discovered back in the day. While it is remarkable that this feature managed to make it past Sony's review process (and that it had obfuscation measures intentionally put in place), functionally it isn't any different from what unlicensed third party products such as the PS-X-Change or Import Player already did, and it's not like you strictly needed any of those to perform the disc swap trick anyway. A mention of those in the video, as well as a few more details on what the cheat code actually does behind the scenes, would have helped clear things up.

It's worth pointing out that there have been other instances of developers sneaking "forbidden" functionality past QA as well. For instance, an indie game developer famously tried to sneak a Perl (IIRC) interpreter into a Switch game and only got it taken down by Nintendo after publicly disclosing it.

As with seemingly everything PS1 related there is a healthy dose of misleading information here. What the game implements is known as an assisted swap trick and is nothing new, neither now nor at the time. In particular, after entering the cheat code, the game will:

- stop the CD-ROM drive's spindle motor, so that the disc can be safely removed while manually holding the lid sensor down to trick the drive into thinking a licensed PS1 disc is still present;

- wait for user input, as the lid sensor obviously cannot be used to determine when the new disc is ready;

- turn the spindle motor back on and force the game's ISO9660 driver to rescan the contents of the disc;

- parse SYSTEM.CNF, a text file containing the path to the main executable, then hand that path over to the kernel and let it load the game.

The fact that the PS1's optical drive only validated a disc's license when it was first inserted, and didn't invalidate it until the lid switch was released, was a pretty well known one even back then. Swapping out a legitimate game for a burned one as it spun up during startup was a rite of passage for many PS1 owners, and plenty of third-party cartridges that would plug into the back of the console (before Sony eventually removed the port for that) offered assisted swap trick functionality as well. Some games with anti-piracy checks did actually force the drive to authenticate the disc multiple times in order to detect and block disc swapping.

The video is partially misleading as it compares this feature to the likes of modern PS1 modding solutions such as Unirom or tonyhax, which do not require fiddling with the lid sensor as they instead activate an undocumented backdoor in the drive's firmware [1]. The backdoor was first discovered in 2013 and no code to enable it is known to be present in this game or in any officially pressed disc.

For the reverse engineers out there, the function responsible for this feature is at 0x8003ec84 in ALIEN.BIN (which is a regular PS1 executable). Interestingly, the string "SYSTEM.CNF" is shuffled and XOR-obfuscated, possibly to reduce the chance of Sony and/or the general public finding out about the functionality.

[1] https://psx-spx.consoledev.net/cdromdrive/#cdrom-secret-unlo...

Nintendo wasn't actually the first company to implement cartridge logo checks. Sega did it first with their "Trademark Security System" or TMSS, which worked in pretty much the same way, but then lost in a US court case against Accolade as the judges deemed that anything strictly required for games to work could not be protected by copyright or trademark law.

Despite the precedent however, the same idea kept popping up in many subsequent consoles and even some non-gaming products:

- The original PlayStation reads the logo that gets displayed on the startup screen from the first 16 sectors of the disc. Notably, US consoles will not validate the logo against a known good copy - possibly hinting at the fact Sony was aware of the TMSS case - but Japanese and late European models will.

- Similarly, PS2 games must contain a bitmap of the startup screen logo in the first 16 sectors of the disc, and PS3 games are required to have a PNG of the original PS3 logo in their filesystem.

- Xbox 360 hard drives must have a PNG of the Microsoft logo in their "security sector", which among other things contains a digitally signed copy of the drive's serial number to ensure third party drives cannot be used.

- macOS will refuse to boot in a VM or on non-Apple hardware unless the BIOS can provide a supposedly copyrighted (but otherwise well known) 64-character string.

- The handshaking process for establishing a connection to an Oracle database server involves sending a string that clearly states it is property of Oracle and protected by copyright law.