Apologies for the long post, but you guys are giving me a lot to work with here
IMO, consoles are designed to play games, which is what makes it more impressive when people write console apps for other things. Resource wastefulness is agreeably a big issue with old CPUs, but it's still an issue today (Did you know an X86 floating-point division can take up to 20 times as long as an addition? How many polygons the PS2 can render without chugging? What a 'page fault' even means?).
The bigger and more interesting challenge for me is making the hardware do things it was never intended to do precisely
because it was designed for games, even if those things are cheap enough to be done during games. For instance, as has been stated (and with apologies to those of you who know this cold), the NES and PCE use tile-based graphics systems, and have no official 'direct-draw' capacity. Fractals, by definition, are much friendlier to draw when you have individual control over the color of every pixel. For his Mandelbrot Set demo, ccovel knows some PCE tricks which, whether because I haven't tackled the architecture/terminology the same way he has, or because I'm just being stupid, I'm still wrapping my head around. They are allowing him to indirectly set the color of every pixel in VRAM in spite of seemingly only having direct control over which 8x8(?) tile from memory is copied to which 8x8 square of VRAM. The best I could manage for my Mandelbrot Set on on NES was to use 4x4-pixel blocks (as large as 1/4 CHR tile) as 'pixels', since conveniently 4 blocks per tile ^ 4 colors per block = 256, the total number of tile indeces in 1 CHR ROM bank. I 'direct draw' by calculating the color I want for each block, then looking up the tile with those 4 blocks from my bank. I suppose I could use individual writes through the PPU to edit actual tile memory, but to me that goes against the notion of how the "average" cartridge was set up- your CHR banks are in ROM, and unless you sacrifice a chunk of a bank to use as a writeable scratchpad (at added cost and headache for the hardware engineers), all you can do is copy existing tiles into your nametables. My earlier comment on how the NES architecture makes getting at your CHR data difficult revolved around precisely this- the CHR address space is not directly accessible by the CPU, only by reads/writes through the PPU, and even then writes to your actual pixel bitmaps are expected to fizzle under most circumstances.
Similarly, I acknowledge games like Battletoads, Kirby's Adventure, Final Fantasy III, Somari, and others are awesome games, but knowing what the NES "can" do, I can pick out pretty much exactly how the games are working their magic. Games like Recca are far more entertaining for me because I can't always tell how the system does what it's doing. Recca has got to be devoting some seriously anal timing loops to those full-screen raster waving effects, but moreover, I could swear I count more than 64 sprites going at once without much clipping or flicker, even on 'strict' emus like Nestopia. Heck, the train level in Little Nemo had me mildly stumped for a bit with its apparent multi-layered multi-directional scrolling/parallax. Even the MegaMan 2 title uses a vertical parallax effect that "shouldn't be possible." And porting SMB to the PCE? I can see how a good bit of the game code would be a straight shot, but the whole reason I've been curious about the graphics, sound and I/O is to see how much one would need to bend over backwards or come up with creative solutions to make the PCE do something it may not have been intended to.
For games I mean.