In early May 2020 a leak of Nintendo Source Code hit the popular image board 4chan. The material contained in this leak was obtained by a young hacker known as Zammis Clark.
The material itself was uploaded twice, the first upload was named
unsorted.zip. The problem with this archive was that it contained many files with the extension
,v (comma intentional).
The archive was then re-uploaded with the CVS files fixed and called it “unsorted-nocvs.zip”.
Concurrent Versions System or CVS is a version control system which predates both Git and SVN and was based on the Revision Control System (RCS).
When the files were downloaded from the Nintendo server they were in a CVS repository.
A CVS repository is file-based, where the version history, file contents and commit messages are stored in a
Thus the original leak of the files were not the raw files. Each file was wrapped in a container that had the additional version control information.
In order to view the actual file you would need to use a VCS or RCS command to get the latest version of the file.
If you are just interested in browsing the files then it is highly recommended you download the noCVS version as it is not just a case of removing the
,v from the filename, you need to use CVS or RCS commands to fix the files.
However the advantage of the CVS version is that it contains the commit history of the files which can be very interesting!
Whether you have the original or the NOCVS fixed version you will get 3 different tar files in the archive:
The name depot may be related to the network functionality of the iQue known as the iQue Depot.
The iQue Depot is the service that was later enchanted and used for the Nintendo Wii.
As the name implies this folder is for the configuration of the Concurrent Versions System. You can think of this folder as similar to the
.git folder in more modern projects. Nothing interesting to see here.
The HW folder contains hardware specifications for the Kilopass Super Permanent Memory or XPM.
This is presumable the hardware used in the iQue Player to enable storing code and data on the chip in a way that makes it harder for reverse engineers to access the data.
There is basic Verilog source code in this folder along with official specifications all from Kilopass themselves.
The DataSheets folder contains three pdf files:
gds folder contains more Verilog source files, such as the TSMC layout layer mapping (
Virtuoso_0.13um_Ver2.1a.1.map) along with the GDS files used to describe it in a graphical form.
models folder contains the timing library Verilog source code in both ascii (.lib) and binary compiled form (.db). This also contains the Verilog source file
kp13ts64_r01w01_70c3p.v which is the main code for the Kilopass
netlist folder contains the netlist specification in the CDL file format, this is a plain text document that specifies what each node is connected to in the circuit.
Not sure why this man directory is called
rf but it contains most of the files for the iQue Player (also known as Project BB during development). This includes hardware source code (Verilog), software source, SDK and Documentation.
This folder contains two files at the root called
BBrules, these are both common Make definitions that get included into Makefiles in the child folders.
There is also an empty sub folder called
ecad and it is unclear what this folder could be been used for but it is likely that it is hardware related and would stand for electronic computer-aided design.
The iQue player was codenamed the “BB” project (possibly reference to something in Chinese?) so much of the documentation references the system as the BB or BB Player.
This folder contains the Verilog source code and a bunch of software source code that is used to help verify that the hardware is working correctly.
This folder contains the source code for software related to the iQue Player such as the SDK.
The top level of this folder is a bash script called
mklinks which simply creates symbolic links to common folders so they can be used easily after they have been built.
This folder contains the final version of the internal N64 development tools from SGI, an earlier version of this content was released as part of the “Oman Archive”, so only the changes will be listed here.
The Verification folder contains the source code for a tool called
aes which is simply code to do simple Advanced Encryption Standard (AES) encryption and decryption.
For security the iQue Player only allows running signed and encrypted code, AES Cipher block chaining (CBC) is the encryption algorithm used for this. This tool specifically is used to test the encryption and decryption of binary content.
In fact this folder comes with two pre-compiled Windows executables:
The source code for these too executables are
The AES algorithms is also known as
rijndael which is why most of the source code files start with that name as a prefix. These files come from the AES reference implementation by Paulo Barreto and Vincent Rijmen.
The folder also contains
*.bin files that can be used to test the algorithm, when you feed in
input.bin into test_dec then
deciphered.bin should match exactly.
This folder is pretty boring in that it just contains a standard distribution of Apache Ant version 1.4.1. Apache Ant is basically a task runner written in Java, but it is unclear what they were using it for in the iQue project.
Nothing is customised so we will not cover the contents here.
The Library folder contains the source code for two very similar libraries:
PLI stands for Programming Language Interface and refers to the Verilog PLI as these libraries are used to communicate with the verily models of the Reality Co-processor (RCP or BCP).
The RCP version is presumably from SGI as part of the original Ultra 64 project, but it was not previously released in the “Oman Archive”. It requires an SGI IRIX workstation to compile.
The code in these libraries seems to be related to interprocess communication (IPC) for managing shared data in the system.
The BCP version of the library is a fork of the RCP library with added support to be able to compile on linux.
Each version contains a
.tab file (
bcppli.tab) which is a verilog file 1 and has the form:
$my_function_name call=CalledByThis size=32 maxargs=1 roparm=ffffffff nocallback
If you build the libraries you will get a static library output (
Both the resulting library files and tab files are used in the the Behavioural Simulator code (located in rf/hw/chip).
Principles of Verilog PLI By Swapnajit Mittra page 6 ↩