Programming

C. Plain old low-level "portable assembly" C.

In particular I'd recommend a Game Boy game, because GBDK uses SDCC and is fairly low-bullshit. With scanline interrupts, you have a surprising amount of time to do clever visual effects, flexing the machines one-and-a-half background layers. The machine is sufficiently explained in about forty-five minutes via the Ultimate Game Boy Talk.

(NES is also an option, but - don't. I say this with my NES homebrew project open in the other monitor. It's a miracle this thing ever caught on. You need a decent understanding of the hardware, C, and 6502 assembly, just to put stuff onscreen efficiently. And then the fillrate still blows. The Game Boy can blast the whole tilemap in a fraction of a frame if you cheat hard enough.)

If you want more power, the GBA supports C and C++, and that little fucker runs Doom. It's intended as a super-flexible sprites-and-tilemaps affair, like an SNES with an upgraded graphics chip. (And a downgraded sound chip.) You can scale and rotate dozens of sprites at 60 Hz, atop two scaled-and-rotated backgrounds. Or use fullscreen bitmaps in 8-bit or 16-bit color. (Well, 15-bit.) The homebrew scene for the GBA started before the console even launched, because it has a pretty standard ARM chip and will do anything the Genesis could without breaking a sweat. There was nearly a voxel heightmap version of Banjo Pilot that looked pretty damn close to Diddy Kong Racing on N64.

I recommend C and retro consoles because they're suited to one another - and they offer control. You are in command of every single byte on these machines. C is the ideal language for that. It offers familiar high-level structures. It supports familiar syntax. But it runs very close to the metal, and if you want to get even closer, it will let you.