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. The previously FPGA-based Media Board attached to the DIMM board - now, the Media Board contains the DIMMs, a fat SEGA chip (I call it “asic”), the GD-ROM connector, an unused IDE-style header, the SegaBoot flash (Media board bios) and the backup battery. Also, the “Security” PIC attaches to this board. There is no SH-4 CPU anymore. However, there is also a “network board”. While there was already a separate network board in the old triforce, previously it only contained the NIC. Now it contains a MIPS CPU (AMD AU1500), with a separate flash rom. The “Netfirm”, as the firmware on this board is called, is still VxWorks-based - however, all GD-ROM and PIC functionality is not present there. That’s interesting - there is no other firmware or obvious CPU on any of those boards. But it must be SOMEWHERE.
After thinking about this mystery for some time, I decided that probably the best bet is that the big-fat-Sega-chip now also contains a (small) CPU, which would be in charge for doing the GD-ROM access and the security PIC handling. But where is the firmware?
Disassembling the newer SegaBoot gives a possible answer: While the original Triforce BIOS only accepted one type of DI Inquiry response (0x21), the new firmware also looks for 0x29 and 0xA9. If it finds 0x29, it will upload a blob of data - actually, a file called “firmware.asic”, which lives inside the SegaBoot GCM. It’s 96kb, and looks encrypted. Actually, we see repeating 8byte patterns. My guess is DES. However, the first 0x10 bytes seem to have a special meaning, but that would go too much into details at this point. I was not yet able to decrypt the firmware.
As a side note, the Netfirm can communicate with the gamecube software over specific DI commands (or, technically, answers: the gamecube constantly polls for queries from the DIMM board/netfirm). The Netfirm has a nice “debug-mode”/“development”/“backdoor” on tcp port 10703, which allows you to read/write gamcube memory (isn’t that nice?) as well as DIMM memory as well as the DES key for the uploaded content (as decryption happens on the fly)… … … Guess what we will see next.
Some (older) emulation screenshots after the break…
As you can see, my Dolphin version currently emulates Segaboot fine, including most peripherals. Network doesn’t work yet. However, most games freeze for an unknown reason before showing anything on the screen, one at leasts shows a “illegal to be used outside of japan”. These are probably emulation errors, either in Dolphin itself or in my peripheral emulation.