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. 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. I 'direct draw' by calculating the color I want for each block, then looking up the tile with those 4 blocks from my bank. 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. 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. 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. Fractals, by definition, are much friendlier to draw when you have individual control over the color of every pixel. 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. 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.

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?). IMO, consoles are designed to play games, which is what makes it more impressive when people write console apps for other things.

Apologies for the long post, but you guys are giving me a lot to work with here

Super mario 64 full screen monitor two