As described in this post on ASSEMblergames.com and in this post, there is still a secret left that needs to be lifted for the newer “Type 3” triforces.
As a short summary, the new type triforce is probably a cost reduction of the old hardware. As part of this cost reduction, handling of the GDROM and security PIC, which was previously implemented in an SH-4 CPU, was “removed”. The network stuff was now handled separately on a MIPS cpu, but several strings that are proven to exist do not exist anymore in the flash rom, at least not as plaintext.
I’m sitting on this for a while now, and it didn’t change a lot. That means it’s either 100% finished or completely useless. It’s a python script which talks to the NetDIMM board on a Triforce/Naomi/Chihiro, and implements the “Satellite” protocol for uploading and running games. I dunno if it really works.
Have fun!
Here it is:triforcetools.py
See some hardware pr0n after the break. First, please remember the overall structure of a pre-Type-3-Triforce:The first picture shows the Gamecube board, together with the Power- and IO-board still attached. Also you can see the bios override chip (modchip). Here you can see the IPL with debug output redirected to the screen:Finally, the whole setup (GDROM is in the blue thing in the back, PCB on top is the network PCB of the DIMM board) as it’s currently on my desk: Thanks!
As my original Triforce is not reachable for me at the moment, I’ve bought another one. This time it was a “newer-type” Triforce, without the detachable DIMM board. Those are also called “type 3”. At first it looked as they only integrated the DIMM board into the triforce housing, but after more investigations, it looks like this was a complete redesign. On the other hand, the Base board (handling JVS IO) and the gamecube remained identical.
Just a small tool to decrypt Triforce images:
decrypt.py
Have fun! You have to point it to the right place for the keys. Also, you need to unpack the ISO filesystem first. I do this by Converting the GD-ROM data session to 2048 bytes/sector (UltraISO offers this functionality in the context menu), extracting the game files with extract.exe A bit ugly, but that works.
See decrypt.py for more details on how this works.
[I’ve started writing this a few days after the last post. I was still waiting for some things to develop, but I’m a bit out reach at the moment, so this might take some time. So this post isn’t as finished as I hoped it it would be. But these “news” already started to smell funny.]
In the first 3 parts I explained how I could modify the Gamecube board inside the Triforce to dump the plain game images.
Step 1: $40k overpriced LA (could be replaced easily with a $150 FPGA board), some wires
<
Step 2: 20 lines of python code
Difference between those? Just some simple XOR and ADD.
Ok, now a better step-for-step description what’s this all about.
As you might have seen, GDROM-games for the Naomi/Triforce/Chihiro come with a security chip, which has to be plugged into the “DIMM Board”. The “DIMM board” is, as previously explained, in charge for loading and decrypting the GDROM data.
I’ve spent some time on understanding the exact protocol spoken to the baseboard. Thanks to dolphin, I could run the software (for example, media board bios) and log all EXI/SI transfers. More details later, but I could replay them on the Triforce, thus grabbing the right responses, and emulating them properly in dolphin.
There is still a lot left to do, of course. :) The media board emulation is more than incomplete (it only emulates reads, so far), and there is no JVS IO yet.
I almost forgot to write about the successful execution of Task 3:
I basically patched the SegaLoader (i.e. the Media Board payload) to break after initializing the GD-ROM, i.e. after reading the GD-ROM into Dimm-Board’s memory. Then I just repeated the steps I did for dumping the Media Board (after the Media Board is switched into “Dimm Board”-mode, the same read commands will read the data from the DIMM Board instead of the onboard flash).
The Media Board contains an FPGA which interfaces to the DI bus, i.e. replaces the DVD-ROM. However, A quick test shows that the original DVD commands don’t work. Here the modchip’ed triforce comes handy again: The qoob bios leaves the original bootrom (i.e. the triforce IPL) at 0x81300000. I could then upload my own test tool via network, patch the IPL (for example I’ve redirected OSReport to the screen and to the USBGecko), and let it run.
I’ve already described that the heart of the beast is a basically unmodified retail Gamecube board. Rumors tell it has 48MB of (MEM1-)RAM, but based on the memory chip quantity and description, I cannot confirm that - they exactly match a retail Gamecube. As a side note, games seem to be 512MB max. I won’t give any further comment about the possible implications of these facts ;).
However what is modified versus a retail Gamecube board is that a different IPL is installed.
What is “The Beast”? Other than what you find on wikipedia, the Triforce can be described as a tweaked Gamecube.
The heart is a standard, retail Gamecube board, allegedly with twice the amount of MEM1, and a custom IPL. Instead of the DVD drive, the Triforce has a Sega-developed “media board” which interfaces to a “DIMM board”. The “DIMM board” is an embedded computer running VxWorks. It has a large amount of buffer RAM (my unit has 512MB), and interfaces to a NAOMI GD-ROM.