Quote:
I doubt that sprite multiplexing or raster effects are possibly on the NES, or reliable at least. Even simplest code that sets position of a sprite directly, without DMA, leads to problems on the HW.
I'm getting off topic, but all that the DMA does is do 256 writes to $2004, technically. So if DMA works, direct writes to $2004 should work too ? I have never tried it as there is no advantages in doing it this way (it just takes more time), but if you perform the writes before the end of VBlank (which should be easy with an unrolled loop) then I can't see how it could fail and how it differs from DMA.
Back on the topic, I think you can do odd things with $2004
reading during the frame. This was quite obscure as the behavior was different depending on the model of the NES/Famicom you used and the PPU revision. Most people doesn't have 20 different NESes/Famicoms to test their programs on it for exact behavior of different revisions so this is highly problematic to test.
On some systems like the C64, sprite mulitplexing is common and even essential if you want to display more than 8 sprites at all. I remember writing a cool multiplexing engine for it then loosing both the source code and the compiled result
The C64 however is very different as VRAM is shared with RAM (it's the same memory chip, VRAM is just a part of normal RAM) and the acesses are interleaved between the video chip and the CPU, so you can write to any register anytime and it takes effect immediately. Also sprites are part of normal VRAM, there is no such thing as OAM. The price for this is a very slow CPU (1 MHz only).