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).
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).
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.
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.
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.
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:
> using only Psy-Q API documentation as a reference
Doesn't that mean it's not clean room? Since even having those docs in the first place would not be legal?
I've seen others claim that clean room can only be an option if development was done without any input from anyone who has even read their docs, not just whether you have yourself or not.
For example in the N64 world some might say development is forever tainted because it's almost impossible to get information that wasn't sourced somehow ultimately from the oman dump.
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.
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].
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.
feel like you're missing the point of the video. no one is saying its new. It's that it made it into a commercial game that passed through Sony TRC and was kept a secret for 23 years until the developer reached out to me
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.
Your clarification was provided based on baggage from discord that isn't talked about on the video at all.
The video never said that it would "make copies of the game impossible to obtain for reasonable prices" or that it would have killed the console.
You also said:
> healthy dose of misleading information here (emphasis mine).
Charitably, "here" could be read as either the video or the HN thread, but since neither contain those points, I agree that your comment came off as dismissive since it reads as strawmanning both the video and the contents of this thread based on stuff that's happened on discord in order to swoop in with a correction that wasn't needed.
Otherwise, your post contained useful additional information.
Based on my own interests, the interesting thing in the video is indeed the points that the poster raised, namely how procedure used for multi-disc games got past Sony QA despite being a single disc game, which could have been flagged through scanning of the APIs called. (Presuming there weren't other genuine uses for the same API call outside of multi-disc games, which I'd be happy to learn about).
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.
There is an even bigger missing entry: toys. The Chinese company Sunplus/GeneralPlus has had a near monopoly on toy microcontrollers for over two decades at this point and the vast majority of their lower-end offerings are based on trimmed down 6502 derivatives, usually expanded with dedicated hardware for tasks like audio playback. Notably, the original Furby [1] and many Tamagotchi models [2] use such chips.
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).