Hacker News: spicyjpeg

Psxsplash – Build PlayStation 1 Games in Unity

spicyjpeg — Sun, 19 Apr 2026 21:31:37 +0000

Article URL: https://psxsplash.github.io/

Comments URL: https://news.ycombinator.com/item?id=47827800

Points: 3

# Comments: 0

New comment by spicyjpeg in "US national level OS-level age verification bill proposed"

spicyjpeg — Wed, 15 Apr 2026 21:00:50 +0000

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.

New comment by spicyjpeg in "Introduction to Nintendo DS Programming"

spicyjpeg — Thu, 09 Apr 2026 14:13:45 +0000

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

New comment by spicyjpeg in "Hostile Volume – A game about adjusting volume with intentionally bad UI"

spicyjpeg — Sat, 14 Mar 2026 22:03:53 +0000

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.

New comment by spicyjpeg in "Arizona Bill Requires Age Verification for All Apps"

spicyjpeg — Wed, 18 Feb 2026 20:51:35 +0000

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.

New comment by spicyjpeg in "Skip the Tips: A game to select "No Tip" but dark patterns try to stop you"

spicyjpeg — Fri, 13 Feb 2026 10:56:27 +0000

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.

New comment by spicyjpeg in "PC Floppy Copy Protection: Vault Prolok"

spicyjpeg — Sat, 07 Feb 2026 11:41:23 +0000

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

New comment by spicyjpeg in "Defeating a 40-year-old copy protection dongle"

spicyjpeg — Mon, 02 Feb 2026 13:50:50 +0000

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

New comment by spicyjpeg in "Dithering – Part 2: The Ordered Dithering"

spicyjpeg — Mon, 26 Jan 2026 22:58:42 +0000

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

New comment by spicyjpeg in "UK House of Lords Votes to Extend Age Verification to VPNs"

spicyjpeg — Mon, 26 Jan 2026 12:26:01 +0000

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.

New comment by spicyjpeg in "Cloudflare CEO on the Italy fines"

spicyjpeg — Fri, 09 Jan 2026 19:11:53 +0000

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.

New comment by spicyjpeg in "Macromedia Flash, from an Animator's Standpoint (2022)"

spicyjpeg — Sun, 04 Jan 2026 21:52:02 +0000

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

New comment by spicyjpeg in "Danish postal service to stop delivering letters"

spicyjpeg — Mon, 22 Dec 2025 14:09:38 +0000

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.

New comment by spicyjpeg in "Super Mario 64 for the PS1"

spicyjpeg — Thu, 11 Dec 2025 09:04:08 +0000

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

New comment by spicyjpeg in "Super Mario 64 for the PS1"

spicyjpeg — Thu, 11 Dec 2025 02:04:00 +0000

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.

New comment by spicyjpeg in "Super Mario 64 for the PS1"

spicyjpeg — Wed, 10 Dec 2025 21:34:29 +0000

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

New comment by spicyjpeg in "Ask HN: How were graphics card drivers programmed back in the 90s?"

spicyjpeg — Sun, 21 Sep 2025 20:42:29 +0000

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

New comment by spicyjpeg in "Notris: A Tetris clone for the PlayStation 1"

spicyjpeg — Sat, 24 Aug 2024 16:05:44 +0000

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

New comment by spicyjpeg in "Pyramid3D Real-time Graphics Processor (1997) [pdf]"

spicyjpeg — Mon, 13 May 2024 17:39:51 +0000

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)

New comment by spicyjpeg in "ESPHome"

spicyjpeg — Wed, 24 Apr 2024 09:03:43 +0000

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