rpi-open-firmware VS PSn00bSDK

> Please correct me if I'm wrong.

My memory told me it was the GPU that needed the blobs. So I asked at DDG

https://duckduckgo.com/?t=ftsa&q=binary+blobs+and+the+Raspbe...

Turned up this: https://wiki.debian.org/RaspberryPi and it says...

> All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W, 2, 3, Zero 2 W) boot from their GPU (not from the CPU!), so they require a non-free binary blob to boot

So the 4 (and I suppose the 5, if it ever actually comes...)

Goes on to say:

> Since then, Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016. See more at https://news.ycombinator.com/item?id=11703842 . Unfortunately development of rpi-open-firmware is currently (2021-06) stalled.

So there you are. Not wrong, are you, but not strictly correct, depending on "...to run properly" definition

https://github.com/librerpi/rpi-open-firmware has updates 3-months ago

many of those demos work on the the entire pi model range

pi3 support is only broken due to arm side problems, which could be fixed by just using a different bootloader

and the https://github.com/librerpi/rpi-open-firmware codebase can already boot linux headlessly on both pi2 and pi3, it uses a different arm bootloader

Yes, and some folks are reverse engineering their stuff:

https://github.com/librerpi/rpi-open-firmware/

rpi-open-firmware: open-source VPU side bootloader for Raspberry Pi\ (35 comments)

There is work being done on the RPi4, for example the SHA1 HMAC protecting the boot on the RPi4 had to be cracked (and was easily), I hear future versions have RSA signing support, so the proprietary firmware might become mandatory at some point.

https://github.com/librerpi/rpi-open-firmware/blob/master/do...

There is a project to create an open source version of the proprietary GPU firmware that boots into the ARM processor:

https://github.com/librerpi/rpi-open-firmware

I note that even the Raspberry Pi is moving towards locked down devices, the RPi4 has an (easily cracked) HMAC blocking booting into the open source firmware and I hear more recent hardware editions have RSA signing support in the bootrom code.

https://github.com/librerpi/rpi-open-firmware/blob/master/do...

The original PlayStation's main SoC (which is incidentally about 30 years old at this point) included a trimmed down JPEG decoder [1] meant to be used for video playback. It still relied on the CPU to handle Huffman decompression [2], but it allowed that otherwise anemic 33 MHz MIPS core to push 320x240 video at 30fps.

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

[2] https://github.com/Lameguy64/PSn00bSDK/blob/master/examples/...

That post introduced me to both WebGL and reverse engineering back in the day. I remember reading it years ago and asking myself "seriously, is it that easy to do 3D in a browser???". The web as an app platform is not without its issues, sure, but for quick prototyping being able to just write some JS and have instant access to plenty of APIs is awesome.

Last year I decided to finally break out of the browser and get into actual PS1 homebrew. Unfortunately the state of the scene wasn't, and to some extent still isn't, that great: most homebrew games are still made using what's basically a modded version of the original Psy-Q SDK, which is rather limited in many ways. I started contributing to an open-source PS1 SDK instead [1] by first adding a dynamic linker, then revamping the build system entirely and now building a custom high efficiency FMV playback library (totally not inspired by pl_mpeg of course) that combines the hardware accelerated MJPEG-like decoder with the GPU's alpha blending capabilities. I'm also working with a few other people on reverse engineering one of the most famous PS1-based arcade systems, the Konami System 573.

It's a shame the PS1 isn't receiving the attention other consoles are getting in the homebrew scene. The hardware is architecturally simple yet powerful [2], but I guess nobody wants to fiddle with 120mm polycarbonate circles anymore.

[1] https://github.com/Lameguy64/PSn00bSDK

For coding I used PSn00bSDK .

From what I was able to gather the lack of attention for PS1 is mainly due to lack of usable SDK but there is now https://github.com/Lameguy64/PSn00bSDK which made me go this rabbit hole. The demo you shared is nuts tbh.

Thankfully though there is a work-in-progress unofficial SDK that is far easier to set up and more optimized than the Sony crap. It's still in its early stages, but you can already do a lot with it. Anything not covered by the SDK is of course still accessible directly by manipulating hardware registers, just like Arduino.