Yeah, same thing happens if you access VRAM while screen is being displayed; you get random pixels and/or streaks of color. Best solution is probably to mark palette/vram buffer area as needing updated, and then doing the actual update immediately after a vsync. You have a few blanks lines there where it won't affect the display.
Accessing vram during active display isn't going to get you snow or stretched pixels. You might get 'tearing' effect akin to early PC animation if the beam is somewhere in the area you're updating. If you're writing to the BAT, that's a different story. There's an 8 pixel dot clock the VDC divides access to for fetching BAT, tile planes, and cpu access (read/write). There's a dummy BAT read in there (marked as
in the docs). If you happen to change that BAT entry before it re-reads it (while it's onscreen), then you'll get a weird 8 tile pixel line with alternate colors. Other than that, you should be fine.
It's always better to chase the scanline/beam rather than race it anyways. Unless you're double buffering or writing to the BAT for offscreen areas, then it doesn't matter.
If you're really good, and can time things to the scanline; there's a small period at the end of each scanline where you can get away with updates, too. But timing updates then is really tricky...
If you're using your own clean hsync interrupt code, you can easily change up to 3 colors per line. Possibly 4 with a slight fringe on the overscan area of the left edge (clip it to 248 pixels wide and you'll be alright). Else, all other writes to VCE regs (color updates or
not), cause the VCE not to read the VDC pixel bus and you get pixel stretching (last color on the VDC output) :
. Might be something you want to do with timed code for an effect, or just want to avoid all together. Using cpu opcodes causes interesting jitter like in that video. But you can draw solid lines if you use the Txx instructions. Laser sprites and such
An area of hblank is off limited to vram read/writes as it's fetching all the sprite pixels for that line. It's fairly short amount of time though. Accessing VDC regs are fine, but touching the data port (read or write) will halt the cpu for about 10+ cycles during this time.
