32X was a similar concept, with the idea of packaging up and reusing enhancement chips in a base cartridge that would add 3D support to the Genesis. The Genesis VDP is still used in 32X games, usually to render the background while the 32X's VDP renders flat shaded polygons on top.
The Saturn uses a similar architecture of using two VDPs, with one mainly dedicated to rendering the background.
I'm surprised this concept died out. Take the next-gen consoles, they're supporting games at 120fps/120hz. They could target 60fps (what the vast majority of users will use) and daisy-chain another console for the serious gamers who 'need' 120fps. This could be done through the HDMI cable (which supports ethernet in addition to video & sound), it could even be enhanced to support 8k.
Yes, this is essentially SLI/ CrossFire, something that has been around for some time, and support would be described as patchy at best. I believe the main issue is that it's left to game developers to implement, rather than something abstracted away to the graphics drivers/ GPUs.
Games are often CPU limited these days: updating game state from one frame to the next is one of the hard problems of modern game development. I don't think splitting the work between two consoles connected by such a slow link would work very well.
The other hard problem is building the instruction chain (the term is escaping me at the moment) which gets sent to the GPU. This would have to be duplicated on each system.
The most workable solution would be to have one system do nothing but update game state and send it to the other system, which just does rendering. Limit yourself as much as possible to one way communication. Hopefully the game state system would do a lot of GPU compute for physics etc, otherwise its GPU would be idle. Furthermore, there are a lot of single threaded bottlenecks in both game state and render, so you'd lose out in parallelism. (Many modern systems fix this problem by rendering frame N (which is read only on state N) while simultaneously computing game state for frame N+1. (which is also read only on state N) Since both operations are read only, their single thread bottlenecks are different single thread bottlenecks, which helps parallelism dramatically.) Overall you'd be getting a very minor boost in performance from doubling the hardware commitment; certainly no better than 50%, but I'd ballpark probably closer to 25%.
It's an interesting idea, but one which is ultimately destroyed by the unrelenting iron fist of Amdahl's Law.
The one place you could potentially win is VR: each console could run the same codebase, independently, to generate the left and right eye views - whatever one console can do for one display, two can do for two; the amount of information required to keep the two game simulations in sync would be relatively small (world/view transforms and frame timing from master to slave console to let the two simulations stay in lockstep).
People would balk at having to buy two consoles for VR though.
Hindsight is always 20/20. At the time, and even on paper, 32X did not sound like that bad of an idea. The 32X even sold well initially. I wanted one at launch, and bought one a few years ago (it truly is terrible). At launch it was a relatively cheap entry into 3D gaming. Keep in mind the only alternatives were multi thousand dollar PCs and the $800 3DO, not adjusted for inflation.
But the announcement of the Saturn soon after killed the 32X.
And programming for two VDPs was incredibly difficult. Especially considering games were still being written in assembly even at that point in the industry.
Plus the economics didn't make sense. It is cheaper to manufacture a single console instead of a base system and add-on separately. You end up confusing the consumer, and limiting market reach because your add-on market is a subset of your base unit's market size.
And the games were bad for the most part. Really bad. I have played the majority of home consoles. Even the likes of the 3DO, Jaguar, Virtual Boy, Sega CD, etc. The 32X is easily one of the worst consoles, ever, period.
IIRC the PlayStation VR helmet has a lot of onboard processing to help it generate two high-framerate screens. I’m not too up on its specs as I am really not at a place in my life where I’m willing to dedicate a room to VR and spend the cost of another console on the thing.
Really though I feel that the response of any console manufacturer to “hey let’s bring back the 32x” would be “do you know how much money that thing lost Sega”. Just update the specs a bit and sell a “Pro” or “Plus” model for the same cost as the original launch cost, and sell the old design for less.
You can get external FireWire boxes to cram graphics cards in for your computer; my general impression of the market is that “serious gamers” who “need” 120fps are pouring lots of money into Windows machines with pricey graphics cards.
According to Sony, the PSVR breakout box isn't doing much in the way of processing. It just handles 3D audio and warping 2D video for the headset (and the opposite for TV display of what the headset displays if the game doesn't provide its own feed).
The Saturn uses a similar architecture of using two VDPs, with one mainly dedicated to rendering the background.