Yes that's right, so far the only known way to stop the snow is to update the palette while outside the visible screen area or disable the screen totally (REG_ENVIDEO). Its a pity such a register does not exist on the MVS/AES.
There are a couple of areas where the NeoGeo shoots itself in the foot and the palette situation is one of them. It would have been of great benefit if the non active palette RAM bank was connected to the 68000 bus, say from 0x402000 to 0x403FFF. Then one could update palettes to this region with no adverse affect and then simply toggle it once complete. That is a bit of an oversight on the part of the designers of the hardware
Yes blaster its unfortunate but I believe you cannot disable video on the MVS/AES with 'REG_ENVIDEO' . There may be an undocumented way to do it however which has yet to be discovered. If there is one I would like to know what it is because it would come in handy in a few places for the unibios.
I think you require the palette update to complete in 40 scanlines on an NTSC (MVS/AES) system to avoid snow. The fastest way we found is 47 scanlines without adjusting the buffer more.
You can think about getting those last 7 scanlines by doing some of the move in the area between each scan line (hblank), The first movem.l from the buffer can happen in the visible area no problem. Its just a case of if the movem.l into palette ram can be timed to happen in the off screen area and if there is enough time for it to complete without coming into the next scanline. You'll again want to avoid interrupts (if possible for every scanline) because that's going to kill many cycles for nothing and I'm not even sure the interrupt will trigger in the optimal place.
On blank rasterlines, the current code updates about 5.2 palettes (3.7 with DMA as can clearly be seen in Blastar's screenshot). This would leave about 42 palettes to be written during the horizontal blank area.
The theoretical maximum amount of write cycles per blank area should be 128, barely enough for 32 colors or 2 palettes. If the screenshot is an indication, there might be some border pixels affected as well. The movem setup cycles (8 to 20 cycles in our variants) might already start in the display area. Assuming, that we now have enough time to prepare all registers in time even with the unmodified buffer, we'd at least need 21 additional rasterlines, more with the cycles lost while synchronizing with the border, etc.
Just tried this and it looks great. Well done Blastar . I like the way everyone collaborated to optimise the code. Would be amazing if someone could work out a Doom-style FPS on Neo Geo.
Hope someone can figure out how to get it working well on the AES/MVS.
Incidentally I read (direct from the programmer) that the tunnel section in Stardust (the original A500 version, not sure about the AGA version) was just an optical illusion. It doesn't actually alter perspective. It just appears too. It's really just a bigger-than-than-the-screen animated background.
How about the different pixel mappings used in this demo?