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

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

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

[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

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

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

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.

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.

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

Points: 2

# Comments: 0

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/

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

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.

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/

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

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

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

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.