How well understood is the N64 understood now? Is most of the knowledge of how it works from reverse engineering or is there actually stuff from nintendo explaining it that's now available?
A lot of the knowledge is from patents and dev kit leaks. Also, it was built by Silicon Graphics and uses similar tech to their indigo workstations so some knowledge from those apply.
The Verilog source code for the N64 ASICs leaked at some point, it's been floating around the internet for a while. So there's very little you couldn't figure out by looking at that, at this point.
That's relatively recent, though; the vast majority of the emulation knowledge was from reverse engineering, patents, and typical devkit leak stuff as you say.
Verilog RDP leak is overrated, IMHO. It helps to shape “broadly” how the black box (for the time) RDP works so RE work can starts.
TBH, most peoples still prefer to RE on dedicated N64 hardware (hand crafted physical CPU interrupt/inspection). The problem is Verilog source alone is not that useful as you need to “plug” it to CPU with the N64 interface.
>Wow I had no idea verilog was used for ASIC design this far back
"This far back" is not that far back. N64 came out in 1996, at which point custom ASIC design and EDA tooling was already commonplace.
Verilog appeared in 1984, and EDA tooling was in use way before that.
What's more commonplace today is the number of fabless IP companies in the semi space that focus exclusively on selling only IP, rather than selling fully made chips, like SGI, NEC, TOSHIBA, etc. did back then.
It is pretty much understood in most aspects that pertain regular software development, though there are still corners that are investigated.
The most accurate and fast emulator right now is Ares (https://ares-emu.net), which bundles the Vulkan-accelerated RDP emulation with a recompiler for both CPU and RSP. It is extremely accurate in many regards and in general much closer to the real hardware than any other emulators (with cen64 being a close second). Other emulators manage to run most of the game library but using several hacks, while Ares keeps a zero-hack approach, so not everything works, but it is for instance far more compatible with advanced home-brew stuff which use the hardware in ways that the Nintendo SDK did not.
The most advanced open source library for N64 development is libdragon (https://github.com/DragonMinded/libdragon) which is currently growing very advanced RSP ucodes that do things that are not possible with Nintendo SDK. For instance, it was recently merged a command list support to send commands from CPU to RSP without any lock in the happy path, and fully concurrent access from both the processors. Another example would be its DMA support for fetching data from ROM that exploits undocumented partially-broken features of the RCP that were previously unknown to allow for misaligned memory transfers.
The most accurate source of hardware documentation is the n64brew wiki, which is slowly gathering accurate, hardware-tested information on how the whole console works. https://n64brew.dev/wiki/Main_Page. Unfortunately, it's still lacking in many areas (eg: RSP). It's a painstaking long work because there are many many documents floating around with partial or completely wrong information.
At the bottom end they're really, really simple if someone else has done the grunt work of writing the CPU code. I remember back in the mid-90s my buddy and I wrote a Sega Game Gear emulator in one evening after grabbing a .c file for the CPU. Those 8-bit console GPUs are pretty simple.
But... once you get past the 16-bit consoles it all goes to shit. Something like a Sega Saturn with two CPUs and 3D hardware. Lord help me. I honestly would not want to even begin trying to emulate a PS3. Total respect to those guys writing emulators for modern consoles and actually getting them to play the software.
17 comments
[ 3.3 ms ] story [ 41.1 ms ] threadhttps://web.archive.org/web/20220329011051/https://alinacier...
N64 is well understood, and there are low level emulators now available that emulate the RSP and RDP on modern GPUs implemented with compute shaders. https://www.libretro.com/index.php/category/parallel-n64/
That's relatively recent, though; the vast majority of the emulation knowledge was from reverse engineering, patents, and typical devkit leak stuff as you say.
TBH, most peoples still prefer to RE on dedicated N64 hardware (hand crafted physical CPU interrupt/inspection). The problem is Verilog source alone is not that useful as you need to “plug” it to CPU with the N64 interface.
"This far back" is not that far back. N64 came out in 1996, at which point custom ASIC design and EDA tooling was already commonplace.
Verilog appeared in 1984, and EDA tooling was in use way before that.
What's more commonplace today is the number of fabless IP companies in the semi space that focus exclusively on selling only IP, rather than selling fully made chips, like SGI, NEC, TOSHIBA, etc. did back then.
I think now all ucode are now properly documented[0][1][2].
[0]: http://gliden64.blogspot.com/2019/02/hle-implementation-of-b...
[1]: http://gliden64.blogspot.com/2018/05/hle-implementation-of-m...
[2]: http://gliden64.blogspot.com/2017/08/star-wars-rogue-squadro...
The most accurate and fast emulator right now is Ares (https://ares-emu.net), which bundles the Vulkan-accelerated RDP emulation with a recompiler for both CPU and RSP. It is extremely accurate in many regards and in general much closer to the real hardware than any other emulators (with cen64 being a close second). Other emulators manage to run most of the game library but using several hacks, while Ares keeps a zero-hack approach, so not everything works, but it is for instance far more compatible with advanced home-brew stuff which use the hardware in ways that the Nintendo SDK did not.
The most advanced open source library for N64 development is libdragon (https://github.com/DragonMinded/libdragon) which is currently growing very advanced RSP ucodes that do things that are not possible with Nintendo SDK. For instance, it was recently merged a command list support to send commands from CPU to RSP without any lock in the happy path, and fully concurrent access from both the processors. Another example would be its DMA support for fetching data from ROM that exploits undocumented partially-broken features of the RCP that were previously unknown to allow for misaligned memory transfers.
The most accurate source of hardware documentation is the n64brew wiki, which is slowly gathering accurate, hardware-tested information on how the whole console works. https://n64brew.dev/wiki/Main_Page. Unfortunately, it's still lacking in many areas (eg: RSP). It's a painstaking long work because there are many many documents floating around with partial or completely wrong information.
But... once you get past the 16-bit consoles it all goes to shit. Something like a Sega Saturn with two CPUs and 3D hardware. Lord help me. I honestly would not want to even begin trying to emulate a PS3. Total respect to those guys writing emulators for modern consoles and actually getting them to play the software.