by running SUPER SLOW code in an emulator. There is a reason every single N64 game was either sparsely textured or looked like blurry mess - 4KB of texture cache.
Check the link, the video, or the title. This is all running on real hardware.
Smooth running video https://www.youtube.com/watch?v=plh9OGel-lM does 60 fps on emulator. Real hardware video shows 15-20fps in a small room and author himself confirms its unfeasible for anything more complicated (~8 minute mark).
15-20fps is a pretty normal framerate for many games on the real Nintendo 64 hardware, especially the later ones from Rare.
The PAL versions of Zelda ran at 15-20FPS even on emulators in the PC. Yet they were pretty playable.
I emulated it back in the day on a CRT monitor, true.
It's not a texture cache, it's 4KB of texture memory that needs to be manually babysat both in an emulator and hardware.
It might be the same situation as with Atari Jaguar where silicon bug turned texture cache into a fixed buffer you have to load manually.
AFAIK, the memory inside the Tom chip was never a cache. The bug you're probably thinking of is one that makes it difficult to run code on Tom's RISC core directly from main RAM. IIRC, jump instructions are pretty bugged when not running from internal RAM, but the homebrew community came up with a workaround. It's still not acting as a cache in that case though. It just fetches instructions from RAM as it goes.