I'm going to try to relay as much info about nintendo64 homebrew development as best as i can. I do need to note a few things before i begin.

do not use nintendos sdk for the love of god. its 1 not even better than homebrew. and 2 nintendo does crack down on things using proprietary tool chains.

do not reuse models form nintendo games as they will see it in the same light as above. the entire point of using a homebrew sdk is to avoid legal issues and this defeats the purpose.

dont use any leaked documentation as i wont even apply.

the above is due to the nature of this console being in a place where we have gotten to a state where its not reqired to use anything proprietary much like generations before this console.

if you want to use a premade engine some exist.

if your expecting to have to lean mips assembly you do not.

if you are expedcting your games to run in any n64 emulator you will not.

So if you are not intiminated yet heres the things really needed.

for a dev kit you would install libdragon. unlike nintendos this is actually perfered. it supports c cpp rust and i think someone ported go.

c works the best. rust is incomplete but is planned to be maintained in the official repo when complete. cpp usually goes untested and 3rd party microcodes like tiny3d tend to not work. go never tried.

for music you have options, libdragon suports .xm files. it also suports streamed using .mp3 and .wav.

for games intended dor flashcarts you are not limited to the native rom size as sd io is present.

for graphics it supports cpu and rsp rendering and has a opengl 1.1 comlient implimentation.

it is not entirely wise though to use that as tiny3d will allow you to use the hardware's full feature set using blender to make gltf with fast64 to add the n64 specific things.

for people wanting animatons you are in luck as unlike nintendos sdk this one knows about the "non features" sgi talked about. it has mips 3 complient avi hardware acelleration.  in short a dedicated programmer could remake resident evil 1 with no comprimises if they wanted to.

the caviots would be this.

the sdk often dips into the expansion ram.

hardware acceleration works best in the preview branch.

skined models dont support bone weights. they only use vertex groups. the exporter will pick and chose the group thats effected the most wehn exporting. no floating limbs nessacery.

this is an early console so yes its runs circles around a snes and technically is i a tiny faster than ps1 but have realistic expectations.

for emulation there are 2 ones that i can recommend

ares - the same devs that make lib dragon make this so this one is guarrentied to work

gopher64 - this one aims to be the successor to simple64 by the same dev and tries to maintain libdragon support. it can sometimes break but usually works.

to get started mpt blender 4.1 fast64 and wsl or real linux would be a must. other things are flexable so if you have a preference between bandlab or flstudio i dont think that part matter. same with kirita / gimp / adobe / ect.

for engines i think the most complete is hlfg. its an acrynym for happy little frog game. collision is shotty but for small games i would recommend studying the quirks and working within them.

also keep in mind you are stuck compileing your code in a gcc cross compiler for now. i doubt other compilers will be added.

the donts are probably common sense but unlike other consoles the homebrew community was very underground for a bit tp make sure bad actors didnt taint the sdk forming process. (i and the n64 community know the efforts that were used to sabotoge pokemon)