riscv-profiles VS PSn00bSDK

Ssstrict is supposed to address the undefined behaviour problem, or at least it'll make undefined instructions actually trap.

https://github.com/riscv/riscv-profiles/blob/main/rva23-prof...

>there are a lot of incompatible ISA implementations of RISC-V

This is common FUD.

In reality, most chips in the market, including all known application processors, follow the RVA profile[0] spec.

So do Linux distributions.

0. https://github.com/riscv/riscv-profiles/releases

The bit manipulation [0] extension has been ratified for a while now and is part of the RVA22 application extension profile [1].

You can already buy SOCs that support it, e.g. vision five 2 and star64.

Interestingly the risc-v vector has it's own popcount instructions for vector registers/register masks. This is needed, because the scalable architecture doesn't guarantee that a vector mask can fit into a 64 bit register, so vector masks are stored in a single LMUL=1 register. This works really well, because with LMUL=8 and SEW=8 you get 100% utilization of the single LMUL=1 vector register.

Another interesting thing is that the vector crypto extension will likely introduce a element wise popcount instruction.

[0] https://github.com/riscv/riscv-bitmanip/releases/download/1....

[1] https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

That's why we have RISC-V profiles.

Yeah more or less. They now have RISC-V Application Profiles which are basically minimum requirements for "application processors" - essentially devices like phones where you might want to distribute binary apps.

The Profiles spec which includes RVA22 was finally ratified[0] last week.

0. https://github.com/riscv/riscv-profiles/releases/tag/v1.0

Context: RISC-V profiles spec got ratified last week.

Yeah unfortunately there isn't really a great place that lists all the extensions with links and ratification status.

But anyway there is a sort of standard set of extensions that "application processors" (I guess CPUs that want to run precompiled code) should support:

https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

The 22 indicates the year.

Ah, you're right: https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

That's good to see. (Boy, it's really hard to find info about RISC-V profiles on Google. It just seems to ignore all the letters and numbers.)

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.