Ah nostalgia. I started in the games industry doing N64 programming, and our devkits looked similar to those flash carts but there was a big SCSI cable connector that went to the host PC.
Later on we had some "debug" cartridges that sat in between the console and a flash cartridge and intercepted reads/writes to a single address and replaced the data with whatever came in over a serial port back to the PC. That was enough of a backdoor to implement very basic dynamic reloading of art assets - I wrote a Photoshop plugin that added a "send to N64" button and some game-side support code and the cycle time for artists trying to see their work on a TV went from 30 minutes to 10 seconds.
Might be worth checking your network for malware to make sure you're not unwittingly running a residential proxy network. Most often these come from things like free games, which your kids may have installed and "agreed" to the ToS for. AI companies use residential proxy networks, created from things like free games with strings attached, to circumvent blanket datacentre blocks that obstruct AI scraping.
It's fascinating to see how much tooling and reverse engineering fans have managed to create for various systems. This looks very good and tools like emulators and TAS systems are incredible.
It's also interesting to see how much of the developer only systems and documentation has been recreated via reverse engineering. For some consoles I've worked with professionally it's a lot more than I would have thought.
The article mentioned this needed a modified N64 to route the extra debug signals from the cartridge to the CPU. That got me wondering since afaik there are no unused cartridge pins on the N64.
Turns out it's actually a bit more complicated. The Partner-N64 uses some little-used analog input pins (LAUDIO, RAUDIO, VIDEO_SYNC) for this. The modification also requires cutting the lines to the system's DAC chip to work.
I always thought the image from it was blurry and washed out.
At the end I wasn't even wow by it anymore and through the PS had had largely caught up graphically or at least was good enough with its better library.
Later on we had some "debug" cartridges that sat in between the console and a flash cartridge and intercepted reads/writes to a single address and replaced the data with whatever came in over a serial port back to the PC. That was enough of a backdoor to implement very basic dynamic reloading of art assets - I wrote a Photoshop plugin that added a "send to N64" button and some game-side support code and the cycle time for artists trying to see their work on a TV went from 30 minutes to 10 seconds.
This whole system feels so quirky and fiddly to work with compared to modern dev kits.
https://github.com/HailToDodongo/pyrite64
It's also interesting to see how much of the developer only systems and documentation has been recreated via reverse engineering. For some consoles I've worked with professionally it's a lot more than I would have thought.
Turns out it's actually a bit more complicated. The Partner-N64 uses some little-used analog input pins (LAUDIO, RAUDIO, VIDEO_SYNC) for this. The modification also requires cutting the lines to the system's DAC chip to work.
https://ultra64.ca/tutorials/make-your-own-partner-n64-conso...
Right. On Mobile Safari on first attempt to view the site
https://archive.is/WCnLA