Interface between two different bus speeds?
There are 4 solutions (maybe a few others?), none of which are perfect.

a) Grab a video cycle. Simple, cheap, low hardware cost, snow on the screen. 

Build a simply synchroniser interface to the video RAM, and give the CPU prioroty. After all, it will only write at a max of one per uS, where the video is reading 12 or so per uS. Every video cycle, has the CPU written a word? If yes, perform a write, if not, read a pixel to display. Snow can be mitigated by repeating the last video output pixel, rather than outputting a fixed value.

b) Insert a write cycle. Simple, no snow, needs faster video RAM.

Arrange the video RAM timing so there are two cycles per pixel, a CPU write (most of which will be idle) and a pixel read.

c1) Save all writes for retrace intervals. No snow, needs a wide FIFO.

Write pixel values and addresses into a FIFO, burst the FIFO into the video RAM when the screen is dark

c2) only write during blanking intervals. No need for FIFO, but restricts CPU update speed. Saves a synchroniser.

Switch the video RAM bus over to the CPU during retrace, let it write randomly.

d) Double buffered. Simple, no snow, needs twice as much video RAM.

Have two RAM buffers, one outputting to screen, one being written from the CPU. Swap them over sufficiently often. RAM is cheap. You may want a hardware BLIT or some extra software to fast update the buffer that wasn't being updated by the CPU when you next get it.

e) (I thought there'd be more than 4!) Wide RAM.

This is one I implemented back at the start of the '80s, when RAM was slow and expensive. Full speed RAM is arranged 2 wide, so does one read of two successive pixels every 2 pixel times. A simple mux serialises the pixels out to the display, and that spare cycle is then available for a random CPU write. 2 could be generalised to N, if necessary.

f) (I'm sure I can't have listed them all!)