Like the DMEM, you can replace the IMEM at any time. In this case, when you're done with processing a block of music, you can DMA the code for 3d transforms or anything else to the RSP.
Libdragon handles this transparently for you with a queue[1].
Agreed! I used it to build the maps for my 13kb Quake demake[1]. Compared to q3radiant that I used back in the day, Trenchbroom is just so much more pleasant to work with. In hindsight it seems totally obvious that _this_ is the way a map editor should work.
That[1] was James Lambert, who was also responsible for Portal 64[2] and is now developing a completely new N64 game. His Youtube channel is worth a follow.
Related to this, every ROM needs a "boot loader" that has to be signed and is verified by the lockout chip.
Nintendo's boot code is under copyright and thus cannot be used. So the boot code distributed with Libdragon is signed by finding a hash collision with a brute force tool running on the GPU[1]. Fun stuff!
The “development” version of that is even crazier: it's a very tiny signed bootloader that does nothing but copies the “real” bootloader into memory, then trampolines into it, such that even developing your own IPL3 doesn't require having to re-brute-force the signature for every build.
And on top of that, libdragon's IPL3 doesn't just blindly copy the first megabyte of ROM code into RDRAM like the official Nintendo one does, but actually expects the ROM data after it to be a full-blown ELF executable, which it parses out and copies pieces of to the specified places.
They might be able to get around it with an affirmative defense in court, but they obviously don't want to, lest they lose.
But it's legal to use the Sony and Nintendo trademarks in a similar way. The court ruled that since they are checked by the console, there was no way not to use them, and Nintendo lost their protection by doing so.
Libdragon handles this transparently for you with a queue[1].
[1] https://libdragon.dev/ref/rspq_8h.html
reply