Sonic the Hedgehog for the Atari 2600
1morecastle.com
1morecastle.com
Looks like the major constraint is sprite inventory. There's only ever one other object on screen besides Sonic/Zippy. This covers enemies, springs, powerups, rings (which are done with a hardware register that repeats copies of a sprite.) So the levels look and feel really sparse.
The 2600 has only two hardware sprites, so that's not unexpected. To get more on screen, you have to reposition a hardware sprite in the middle of each TV frame while the electron beam is drawing it. The 2600 literally uses the phosphor on the TV screen as the frame buffer. So the 2600 can draw many sprites that march in vertical lockstep (Space Invaders, River Raid) but it's hard-to-impossible to draw sprites with full freedom of movement (famously Pac-man's flickery ghosts, which are each drawn only once every four frames.) It's possible with smart sharing algorithms - do reposition and reuse a sprite whenever it's possible, otherwise flicker when you must when sprites overlap. But doing that along with the fairly complicated playfield manipulation will run out of cycles very quickly. You only get 76 machine cycles per scanline -- just 20-some instructions in 6502 assembly.
"Nick Montfort and Ian Bogost discuss the Atari VCS itself and examine in detail six game cartridges: Combat, Adventure, Pac-Man, Yars' Revenge, Pitfall!, and Star Wars: The Empire Strikes Back. They describe the technical constraints and affordances of the system and track developments in programming, gameplay, interface, and aesthetics. Adventure, for example, was the first game to represent a virtual space larger than the screen (anticipating the boundless virtual spaces of such later games as World of Warcraft and Grand Theft Auto), by allowing the player to walk off one side into another space; and Star Wars: The Empire Strikes Back was an early instance of interaction between media properties and video games."
I know that the Atari has a certain pixel size due to how fast it can turn the beam on and off, but working with that constraint it seems with the above method you could still produce much more complicated games that rival the interactivity of say the SNES.
All this method could do is continually feed the 6507 a stream of instructions to write those registers. It would be like if you had enough ROM space to unroll every possible loop and inline every lookup. The cartridge still couldn't write to the TIA any faster than the 6507 CPU can. It couldn't hit a register any more often than every 18 pixels, which is how long it takes for a basic load/store pair of instructions.
The SNES Starfox chip works by drawing polygons into its own RAM then using DMA to copy them to the console's video memory. The Atari 2600 has no video memory beyond the TIA's registers, and no DMA to hit them any faster.
Unless... I don't know enough about the electrical side, but is it possible for a cartridge to disable or halt the 6507 CPU and directly drive the bus to the TIA? Then you could at least write to the TIA every cycle, yielding resolution of every three pixels. The Atari cartridge slot pinout is pretty plain though, just the 13 address and 8 data lines. Nothing fancy like a CPU halt or reset line or even a clock, and actually not even a read/write line that would be necessary to write to the TIA. It would require some motherboard hardware hacking, and by that point you're pretty much implementing an entirely new game console with an arbitrary CPU coupled to the 2600's TIA graphics chip.
(TIA is Television Interface Adaptor: http://en.wikipedia.org/wiki/Television_Interface_Adaptor )