I built a cartridge, which I call the Vectrex32 SmartCart, based on the Microchip PIC32. It's a 32 bit microcontroller that runs at 200 MHz, has a floating point unit, 2MB of flash, and 512KB of RAM. By comparison, the Vectrex's 6809 is an 8/16 bit processor with 8KB of ROM and 1K of RAM.
The BASIC interpreter and the game run on the PIC32. There's a dual-port memory chip readable and writable by both the PIC32 and the 6809. The PIC32 writes 6809 machine code into the dual-port memory and the 6809 runs it. Thirty times per second, the PIC32 writes the instructions needed to draw the screen, play sounds, and read the controller. Since the game logic is running on the PIC32, games can be far more sophisticated than anything the Vectrex could do alone.
The SmartCart also has a USB interface. When connected to a PC, it appears as a mass storage drive and a serial port. The drive holds BASIC programs and the serial port can be used with a terminal emulator. You can interactively debug a BASIC program (my version of BASIC supports breakpoints, single-stepping, printing out variables, and more). You can also interactively change things on the screen, e.g. you can experiment to get your shapes looking right and moving right.
So basically: he took the 1982-vintage Vectrex and wrote a cartridge for it that turns it into a simple I/O device, with the real program running elsewhere. But, to avoid letting things get too modern, he made the controlling computer (which also fits inside the cartridge) be of 1992-vintage instead of something modern.
Today I learned that BASIC can have breakpoints. Apparently these neo-retro BASICs have advanced beyond what I'm used to: when CLOADM $C000 fails because your cassette stretched, you just type it all in again.
I feel like this must have been what game development was like during those heady, accelerating days toward the end of the 19A0s.
Previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously.
There is precedent for cartridges similar to this in retail games. Starfox for the SNES had a 10 MHz RISC CPU and RAM. Much of the game ran on the cartridge, and rendered into local RAM. That buffer was then copied to the main system's frame buffer to display on the screen.
Though there weren't many Super FX games because it wasn't cost effective to sell an additional computer with each game.
Sega also made a Virtua Racing game for the Mega Drive/Genesis that included an additional CPU to do most of the rendering work. That game initially retailed for $100US.
Fun fact: that Star Fox CPU is the architecture of one of the the Really Helpful Supervisory SystemInAChip built into all new Intel CPUs for ring -3 rootkits^H^H^H^H^H^H^H^Hremote management features...
2009 article
Oops, looks like the mobile UI doesn't like <a> tags.
Articles (2009):
http://theinvisiblethings.blogspot.com/2009/06/quest-to-core.html
http://boingboing.net/2016/06/15/intel-x86-processors-ship-with.html
Chip architecture:
https://en.wikipedia.org/wiki/ARC_(processor)
Also known as DEITYBOUNCE.
And of course, I got rid of my Vectrex a few months ago...
Have you seen the emulator that lets you modify the BASIC program on the fly while it's currently running?
https://www.youtube.com/watch?v=RP0RBa1PX7s
Huh. The intrinsic limitations of the Vectrex CPU were always what prevented it from doing solid versions of any of the more popular arcade vector games; I wonder if this means we'll finally see a decent Tempest or Quantum implementation for it.
Well, Trammell got MAME running on a Vectrex monitor, so there's that. Very interesting interview about it:
AHA! That explains the provenance of some black+white Tempest screenshots that I'd seen floating around. I'd always wondered.