tepples wrote:If you want to be able to do mosaic everywhere (as on certain SNES games) without the bus masking, then it'd take a quadrupling of CHR ROM size or specialized hardware to queue up CHR RAM rewrites and execute them during dead times in the scanline.
the second idea sounds ... involved. at that stage you might as well move to the SNES
"Bus masking" was my suggestion that you could get a vertical mosaic by applying a logical AND mask to the CHR-ROM address bus.
For instance, if you AND with %11111111111110 this means every second byte will be redirected to the previous byte. On CHR data this means every second line is a duplicate of the line above it. Mask another bit %11111111111100 and now you're duplicating 4 bytes at a time, etc.
For horizontal you would dupicate data lines instead. Duplicate every second bit in the fetched byte, every fourth bit, etc.. These aren't addressed, though, so instead of "bus masking" it'd be some kind of "multiplexing" operation, I suppose.
Edit: Actually, I guess if you didn't use the internal nametables and used your own on the cartridge, you could apply more masking for the nametable fetches to continue the mosaic beyond the 8x8 tile level?
Last edited by rainwarrior on Wed Oct 30, 2013 10:00 pm, edited 1 time in total.
What rainwarrior said. Specifically, one could pixelate the Y axis by having an AND or OR gate and three latched bits; something like CHRROM A[0..2] = AND(PPU A[0..2],LATCH0..2).
The X axis would be a much messier transformation; I don't see a way to do it short of a full multiplexer.
Yes, building a mapper that would allow mosaic of sizes 2, 4 and 8 both horizontally and vertically would actually be quite simple !
It's a shame this wasn't added to MMC5 for instance.
This can still easily be done in software (if CHR-RAM), though this will eat up CPU time and VRAM bandwith, or in hardware with CHR-ROM by wasting banks (Mega Man 5 does this). Not as cool as a mapper doing it !
Mosaic of other sizes would be hell of a nightmare to realize, even on a mapper.
Considering that modern SRAMs are normally 32K or larger, while a game with CHR RAM not often needs that much at once, extra CHR RAM banks could be used for the mozaic effect.
If you are animating any CHR RAM tiles, be they background or sprite, that quickly becomes impractical. Writing everything to CHR RAM four times just so that you can turn on mosaic when needed will cut CHR RAM update speed by a factor of four. That's what I meant by the update queue.