When developing homebrew or ROM hacks for an N64, an emulator like CEN64 can be used to get a feel for whether it will run on actual hardware. It is also possible to create a CI pipeline to build on each check-in and feedback compiler warnings etc. However, there is nothing like testing and gaining feedback from the actual hardware, which generally means that you need to be in front of it.
To this extent, I have set out to build a fully automated test rig, that allows me to work remotely, whilst still ensuring that what I build is still able to run successfully.
Progress so far:
Computer OS – Since I had one “lying around”, I decided to use a Lenovo ThinkCentre M700. This is powerful enough, compact, efficient and has enough USB inputs for what I currently need. I also decided on Windows 10 running WSL2, partly because it is easier to get to grips with what I actually require, and secondly because I know that some of the hardware I have lying around and plan to use doesn’t play as nice with linux. Once the prototype is fully working, it will be easier to judge if a linux distribution would be a better choice.
Providing access – VNC with a secure password and networked with direct access to the internet is quite a simple task, and so this was setup fairly quickly. I also decided that it was probably a good idea to totally separate this PC from my main LAN in case I let someone borrow its facilities, due to my network mainly using Ubiquiti Unifi, this should have been an easy process, however my network switches are multiple brands, and it took a while to make them play nice with the necessary VLAN’s.
Facilitating the ability to load the ROM onto the cart – I currently have an ED64 V3 and an X7, which both provide a USB interface for loading ROM’s via PC software. I have much more control over the source for the ED64 V3, so for the time being, I decided to use it for the first rig. If required, the flash cart swapped out for a period to provide a specific need, or a second rig could be setup subject to costs. There are a few different implementations of loader software out there, but for the time being I will use my own (available on GitHub), unless it is necessary to swap to a different one.
Returning the output (screen and debug messages) – For the first version (since I had one lying around) I decided to use a Hauppauge 1975 with WinTV 8.5. The S-Video output from the N64 was used to provide the best possible picture. In the future an UltraHDMI mod paired with an Elgato could be used for really good screenshots (or possibly run easier on Linux), but there is a downside, that the picture is more lenient when it comes to displaying NTSC through a PAL console, so might not give the tester the right feedback. It will also be necessary to find a way to take a screenshot or short video via a script.
Controlling the input – this has proved to be quite difficult with bits and pieces I have lying around. It will be reinvestigated in a future revision.
Rebooting the N64 – Seemingly the N64 doesn’t have an ability to reboot, other than using the hard button on the console itself. It would be quite easy to solder a wire to the reset button and control it via GPIO on something like an Arduino (or use later revisions of the UltraHDMI mod). However, it would probably be better to control the N64 power via a network-controlled mains adapter. This provides the added benefit of the N64 being off when no test is taking place (so the PSU does less work given the age of the console) and also ensures a clean slate when booting the ROM. A smart wifi plug has been ordered and will be added to the prototype once it arrives.
The next attempt will make improvements on the above and also consider:
- Further details on controlling power to the N64
- Use an N360 mod paired with GIMX (although another solution would be possible using the N64 controller input, my console is already modded with an N360)
- Azure devops build agent and associated scripts
Switch to using a Raspberry Pi