spicyjpeg

When deciding on a style for documentation, I typically draw the line between tutorials and references. The linear top-down flow of an introductory guide lends itself well to inserting additional context throughout it even if not completely on-topic, while in an API or hardware reference you generally want to keep each section reasonably self-contained, trivially searchable for (minimizing false hits by carefully choosing keywords) and readable independently of the others. I have found the literate programming approach [1] of writing entire tutorials as code to work pretty well for this purpose, which I've used to great effect in some of my pet projects [2].

[1] https://en.wikipedia.org/wiki/Literate_programming

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

There actually is a pretty large community of hardware reverse engineers decapping chips for fun, sometimes just to dump internal ROMs (like in this case) and other times going as far as to try reconstructing the original schematics and netlists in order to document the chip's internals and allow for more accurate emulation, in some cases all the way down to the transistor level [1] [2]. If you want to learn more, Ken Shirriff has written a lot of blog posts on the subject [3] and Siliconprawn [4] hosts a huge collection of die shots from many contributors.

[1] https://floooh.github.io/visual6502remix

[2] https://github.com/iaddis/metalnes

[3] https://www.righto.com/

[4] https://siliconprawn.org/

ZKPs (as well as C2PA and similar user attestation systems) are quite literally a DRM scheme for the web, fraught with all the usual control and accessibility issues while still being relatively easy to circumvent by a sufficiently motivated and funded actor. Given the huge number of shady companies that run "phone farms" for purposes ranging from social media spam to Spotify royalty farming, I doubt they would even put a dent on this kind of automated abuse. They would however be very effective at locking every Linux and GrapheneOS user out of the internet.

I like to call this phenomenon "reverse compression", or occasionally "depression". It's even lossy and subject to generational loss.

The internet is still full of individuals sharing deep passion for all sorts of things, but only within the walls of invite-only communities you have to go out of your way to find (Discord servers, private forums) and/or make a financial commitment towards (Patreon).

Or at least it was, before LLM "enthusiasts" started leaking into these otherwise hermetic communities and overrunning formerly safe spaces with mass-produced low-effort content nobody wants to see, particularly when anyone else could prompt the exact same thing into existence.

This isn't even the worst payload ever delivered through Windows Update. The prize for that should probably go to chip manufacturer FTDI, which once abused the system to publish a driver that would semi-permanently brick USB serial bridge parts the driver detected as counterfeit [1] by exploiting a command that the genuine parts did not implement correctly (how ironic) [2]. The backlash was large enough that Microsoft ended up pulling the update almost immediately, but that did not stop FTDI from trying again a few years later with another driver update that deliberately corrupted data sent through detected-counterfeit parts.

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

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

This is indeed what is happening behind the scenes. By default Windows Update will automatically download and install support packages for pretty much any device Windows can identify through manufacturer/device IDs, which includes PCIe and USB devices but also monitors. This is most commonly used to deliver drivers but Microsoft allows these packages to silently install any user-facing application as well, presumably due to peripherals such as GPUs or audio chipsets often requiring "control panels" or similar companion apps.

Around a month ago LG took advantage of this feature by publishing a Windows "driver" for all their TVs and monitors that consisted entirely of payola bloatware, resulting in predictable backlash [1] and the obligatory subsequent HN discussion [2]. None of this has anything to do with the TVs themselves being connected to the internet or not.

[1] https://youtube.com/watch?v=Q9uefFYe6bM

[2] https://news.ycombinator.com/item?id=48956688

A particularly worrying trend that keeps spreading is the one of restricting significant amounts of (often non-financial) functionality to the apps only, gated behind your phone passing device integrity checks, in what seems to be a poorly thought out attempt at blocking all forms of scraping and automation (AI or not). The worst offender right now is probably Twitter, which alongside the recent Nitter cease-and-desist now appears to require client integrity on all logged out access.

The FeliCa NFC standard made its way into more than just transit cards in Japan. One notable user is the Amusement IC network, which lets you quickly log into arcade games across multiple manufacturers using a single card. Some implementations (Konami's e-amusement most notably) even go as far as to allow any FeliCa-compatible card or device to be linked to a profile, including transit cards, phones (with no app required!) and certain models of Sony Bluetooth earbuds which use FeliCa for quick pairing.

If C2PA and similar signature systems ever become a meaningful authenticity signal, they will create huge incentives for someone (potentially a state actor) to hack at least one camera in order to sign images of arbitrary provenance with its private keys. This will in turn inevitably lead to the same game of cat-and-mouse we have seen play out with video DRM schemes, where keys are regularly extracted from exploitable devices and used to decrypt as much content as possible before the device gets blacklisted entirely (harming all legitimate owners in the process).

The article does not make it particularly clear, but the malware in question is delivered through official first-party OTA updates on cheap Chinese aftermarket head units that happen to run Android. It cannot self-propagate to any Android-based head unit, nor does it affect Android Auto which is a "dumb" screen mirroring protocol with the bulk of the software running on the connected phone rather than the head unit. This seems to be a very similar situation to that of cheap generic Android TV streaming boxes, which often come pre-infected from the factory with residential proxies and other malware as well; most of the infrastructure is likely shared.

The 6502 and its variants are still ubiquitous as well, powering millions of toys based on Sunplus/GeneralPlus microcontrollers [1] [2] [3] as well as the vast majority of bootleg game consoles that use variants of "Famiclone" hardware (or occasionally general-purpose 6502 MCUs [4]) to this day. It's fascinating how the toy industry went for the 6502 over the 8051 and PIC12 clones more common in other cheap electronics; I suspect it had to do both with the architecture's better performance (important for tasks such as audio decoding) and with the historical availability of experienced 6502 assembly developers as the game industry moved away from 8-bit platforms.

[1] https://spritesmods.com/?art=tamasingularity&page=2

[2] https://archive.org/details/furby-source

[3] https://dmitry.gr/?r=05.Projects&proj=37.%20Pixter#_TOC_a6fe...

[4] https://github.com/davidgiven/tony-sdk

Browser fingerprinting can get creative at times, to say the least. eBay's WebSocket port scanner [1] and Reddit's abuse of DRM and JavaScript JIT exploits [2] from years ago are two examples of the kind of in-depth introspection you can perform completely in the background using nothing more than simple non-permission-gated APIs.

[1] https://blog.nem.ec/2020/05/24/ebay-port-scanning/

[2] https://iter.ca/post/reddit-whiteops/

It's even funnier when you realize that not too long ago a decent chunk of the software industry did have to deal with the realities of having to press CDs, print boxes and ship them to retailers in time for the holiday season. The idea that you can ship a half-baked product directly to your end users, charge for it and promise it will get better over time (but only if you manage to secure enough VC funding in the meantime) is a relatively new invention.

RISC-V is in many aspects just legally-distinct-MIPS, from the base instruction set all the way up to how certain extensions introduce kludges that are very reminiscent of later MIPS additions. While I do somewhat agree on the fact it was a huge missed opportunity to improve upon MIPS's technical flaws in order to realistically compete against the likes of ARMv8, we still have to keep in mind that the primary driving force behind RISC-V is and has always been fixing the legal flaws instead.

There is indeed plenty of value to be had from a standardized (if poorly) PlayStation-1-era instruction set you can safely implement in silicon with no risk of a zombie company husk coming after you, especially in the ASIC space where (as Dmitry himself recognized) anything is better than an 8051 core you need a copy of Keil C51 and a lot of patience to write code for. Even if you end up having to add custom extensions, it still is a much better starting point than coming up with your own bespoke ISA, building a toolchain around it and convincing potential customers that your proprietary architecture is worth the effort to deal with over another vendor's licensed Cortex-M cores with full GCC and LLVM support.

The entire point of piracy and related copyright infringement is to build a path to appreciation of an artist's works without necessarily agreeing to their pricing and terms (whether imposed by the artist themselves or by publishers). What you are suggesting is the complete opposite: leveraging established or even defunct artists as mere brands to slap on generic machine-generated content that does a great job imitating said artists' style, but bears no resemblance whatsoever to the actual creative process that led to that specific style in the first place.

Record labels would actually love this model: they'd be able to put their extensive back catalogs to use by giving everyone their very own hyper-personalized, maximally-stimulating Beatles, Queen, Linkin Park and more, all without paying a single cent to the humans who actually built those acts. What breaks this utopia, and what you seem to be missing here, is that by far and large people want to listen to the real deal and not to a deepfake Chester Bennington's song on the Israel-Palestine conflict in an unprecedented act of VC-funded digital necromancy.

The wiki of Guitar Hero simulator Clone Hero has extensive information on controllers [1]. Some of them can still be purchased brand new but overall the most popular option seems to be to acquire (and sometimes modify) a used first-party controller from back in the day, as the quality of newly manufactured guitars can be inconsistent given the lack of demand.

You may also consider trying out other rhythm games such as the home versions of Beatmania IIDX [2], Sound Voltex [3] or Taiko no Tatsujin, for which high-quality arcade accurate controllers are readily available brand new (if somewhat expensive). There are plenty of modern titles that are playable with nothing more than a keyboard and mouse as well, so you are spoiled for choice if you are not looking for a Guitar-Hero-like experience specifically.

[1] https://wiki.clonehero.net/books/guitars-drums-controllers/p...

[2] https://iidx.org/

[3] https://sdvx.org/

It's slightly more complicated than that. The PlayStation's geometry pipeline uses fixed-point coordinates with a decent amount of fractional precision (12 bits), however the GPU lacks support for subpixel rendering and operates entirely in screen space using integer X/Y pixel coordinates; all transformed vertices thus have to be rounded CPU-side before they reach the GPU. The GPU is also a 2D rasterizer only, with no perspective correction nor depth buffering, so transformed Z values are used on the CPU to sort polygons back to front (typically using hardware-assisted linked list bucket sorting) and dropped afterwards [1].

[1] https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/08...

An overhaul of my original PlayStation bare-metal programming tutorial repo: https://github.com/spicyjpeg/ps1-bare-metal

It was never really meant to be an SDK of sorts that other PS1 homebrew projects would pull as a submodule and depend on, but since it more or less became one I am likely going to split off the examples from the "core" (headers, CMake build scripts and tools). I have also been asked to add more examples, particularly on how to play sounds through the SPU and access the CD-ROM drive, and may cover I/O on some PS1-based arcade systems in the future.

The same way it's done now with current generation consoles: the manufacturer would provide you with SDKs and development hardware once you paid them a decent chunk of money and signed an NDA. Prior to the fifth generation it was common for the SDK to be just an assembler, debugger and register-level hardware documentation, leaving the implementation of a kernel and game engine up to the game developer.

Sony however decided to provide a full C toolchain based on GCC as well as a set of very high level libraries that abstracted away basically all aspects of the PS1 [1], all the way up to implementing a ready-to-go 3D engine and MIDI sequencer. This was an unpopular move as the libraries were slow, inefficient and most game developers were used to having full control over the hardware, but it also allowed inexperienced devs to get started quickly (as proven by the thousands of low budget PS1 titles that used the high level APIs) and eventually contributed to the popularity of the console over its peers with worse tooling.

Sony would eventually go on to release some slightly lower level documentation for certain aspects of the console as well as APIs that better mapped to how the hardware actually worked under the hood. It wasn't however until years later that the hardware would be fully reverse engineered at the register level [2], and it took even longer for most homebrew to move away from the official SDK (which only really started happening a few years ago as accurate emulators and homebrew SDKs started popping up).

[1] https://psx.schnappy.xyz/sdk/Psy-Q/DOCS/LibOver47.pdf

[2] https://psx-spx.consoledev.net/

I am still amazed my own minimalist PS1 tutorial series [1] became as popular as it did, given that prior to it basically all learning material on the internet was written around the decent-for-the-time-but-horrible-now Sony SDK and often based on 30-year-old example code full of 30-year-old C practices (in particular the complete disregard for aliasing and concurrency, which resulted in plenty of headaches once people started using those ancient libraries and example code with modern GCC). We even have bleeding-edge C++ SDK options [2] complete with an STL and coroutine support, so if anybody here wants to try their hand at PS1 homebrew development I would highly encourage checking out the modern tooling we have now.

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

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

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.