Does anyone here have experience with reverse engineering hardware? Sometimes documentation for older systems is especially lacking.
My current issue happened after I’ve followed an N64 tutorial on polling controller input (from chibiakumas) and managed to assemble a ROM and run it on an emulator and then real hardware. The result? Works fine in Project 64, but not hardware. I get an image on the screen, but the controller input is completely ignored.
That means there is an inaccuracy somewhere in Project 64 (no emulator is perfect), or I have a different board revision than it’s configured to use.
Can someone recommend a tutorial on logic analyzers? So I can see what load/stores are happening? I suppose I can write whatever CPU registers I want to RDRAM somewhere and then snoop the data bus to see them. Or dump all of PIF RAM, that would help too.
It’s new and I’ve never used it, but Sipeed’s SLogic16U3 16CH Logic Analyzer was recently brought to my attention (£60) - docs here. It’s USB3 so has good capture throughput.
.
N64 runs at 93.75 Mhz… so that should be enough. I know I could simply print to the screen, but that only holds so much. Button press data should be going into CPU but isn’t, and this would certainly be much easier to figure out if it were possible to see all of the machine state at once…
Such is the seductive trap of relying too much on emulators…
Pretty sad the state of things for the N64, that these critically important examples are buried this deep in text files written a long time ago if they exist at all. Almost no one seems confident in their own understanding of the system too. But, try to understand everything and you might never get around to teaching anyone, so makes sense why this is the best we can do.
Wouldn’t it be nice if someone got an SGI Indy emulator up and running? So we could dev the “right” way.
It has to be noted, it’s an extremely complex product! From reddit:
Consider the SNES. 3.58MHz CPU, clocked from a 21.3MHz signal, implemented in something like 22,000 transistors in the WDC65C816 CPU it’s ultimately based on (plus some support hardware; let’s call it 30,000 transistors for a round number). That leaves out the PPU and audio hardware because I couldn’t find the numbers, but I’d guess under 100,000 transistors for the system?
The N64’s CPU is clocked at 93.75MHz, and is a derivative of the MIPS R4200, which had 1.3 million transistors. The RCP (which handles graphics and audio for the N64) has about 2.6 million transistors.
Yeah well it sounds like we will not be getting an FPGA GameCube anytime soon.
Still, the fact that games need to be able to poll the controller is the existence proof that it works. Reverse engineering a simple menu that waits for you to press A or something is probably a good way to see the “right” way to do it.
PIF officially stands for “Peripheral Interface” (see Sheet 2 of 57 of U.S. Patent 6,139,433)
I have another theory on what might have gone wrong. From the tutorial:
We’re defining ‘PIF_JoyState’ in our ROM, but it’s changed during the program, that’s because the ROM is actually copied to RAM at execution time by the firmware, so it’s actually changeable at run time!
If the firmware simply didn’t do this for some reason, well, that would certainly explain the (lack of) results I’m seeing. I wouldn’t expect the assembler to translate ROM addresses to RAM addresses either, but one appears to be used that way.
I have one of these on order now for retrocomputing purposes, based partly on native software for Linux and adjustable thresholds (although I have a slight regret now for not lashing out on the 32 bit version). I’ll try to remember to write a review here when it shows up.