Cartridge -> "Radio Cart Slot" that sits atop a wireless charging pad, transmits the cartridge's data at a fast rate to a pass-thru cart plugged into the system. The pass-thru intercepts/interprets the data and pushes it to the console to execute in real-time. If the idea works, it could be built upon quite a bit if, say.. the pass-thru (in the form of a Raspberry Pi) had an emulator of the system it is middlemanning for (let's say SNES), that would greatly increase the native system's overall capabilities. The additional power of the pass-thru tech (especially if it could it be programmed to interrupt/override native ops through a button combo) and it's emulator could allow for things like real-time cheat codes, multi-cart "soft" hot swapping on real hardware, even (perhaps through the emulator bit) a dedicated Netplay interface. Could this be a feasible thing?
Technically it'd be possible, but in the same way it's technically possible to move a whole mountain by hand. You'd have additional latency on every. single. cpu. instruction. that gets fetched/executed from the cartridge.
If you want a netplay interface, why don't you hook the pass-through up to the controller slot rather than the cartridge slot? Just have a dongle that drives the controller pins based on input from your wireless network. There's still the matter of actually writing the software, but you'd have to do that either way.
I could see just sending controller input being an issue due to the games not being synced in time as well as things within the games that use a random number generator being different between the two carts.
If only Yu Gong had a taste for classic video games, huh? You are absolutely right. A major question would be how to reduce this latency as much as possible. Most current-day wireless networks would be too slow to see this through, it seems. One option would be to (pain-stakingly) debug each game and analyze it's typical path/predictions and behavior as it's running to form something along the lines of a hi-speed buffer. The other would be to wait for something like Li-Fi (maybe quantum data teleportation will do the trick!) Good call, that's been proven to work before. The solution I was thinking of was more along the lines of XBAND. I wonder if there is anything to gain from combining the two schools of thought (running the controller line into a pass-thru J-Cart). Sending out immediate instructions to two systems in parallel would make things difficult. What could make it easier would be synchronizing the systems over a network to the same clock and then sending instructions out for each system to download at asynchronous times to execute at designated, synced times. Rather then sending out a Reset signal directly from the server, which would make one system reset at say.. 19:03:05.2 and the other system reset at, 19:03:07.1.. The server would send instructions out to a dormant buffer on each system, where both are instructed to be idle until 19:03:09.0. Once that time hits, they jointly Reset.
