Two 30 MHz oscillators arrived, and I replaced the 29.5 MHz one I was using. I didn't think it will make much difference, but it did. The 30 MHz oscillator caused the display to keep blinking!
Maybe it wants more current. Data sheet says 40 mA, about normal for legacy modules.

I restored the 29.5 MHz oscillator, display is stable. Maybe could do with more decoupling there.

There are times when a logic probe just won't cut it, and this is one of them.
Time to get the big guns out, in the shape of my 500MSPS logic analyser.

Having a look at the outputs of the timing GAL, things look as expected. The 15 MHz clock in is divided to 7.5 and 3.75 MHz. This is divided again to 1.875 MHz, slightly delayed, to be the CRTC character clock (CCLK). 

The /RAS, /CASL, /CASU and /LP signals have the right timing relationship. The image below shows the video accesses reading upper and lower bytes at the falling edge of CLCK. It is okay for /RAS to rise before /CAS, this does not end the cycle early.

/DTACK is only used to tell the CPU that data is ready. The CRTC is synchronous and runs whether data is ready or no. So /DTACK is idle for video access.

Video cycles only:

Now let's set the trigger to /DTACK, which is the timing GAL telling the CPU that data are ready.

CPU cycles:

Here we can see CPU accesses taking place. Again this looks good, /DTACK is low during /RAS and /CAS of the CPU access.

Both cycles:

Here we can see both CPU and video accesses taking place. Again this looks good, /DTACK is low during /RAS and /CAS of the CPU access.

DRAM Data Bus Enables

Sometimes they are long, like this:

I'd say these were normal. This looks like a CPU reading 16 bits.

Often they are very short, like this:

In the image above, only /CASL is asserted, so the CPU is accessing a lower byte. And writing, because /BDRE (U28 pin 1) is high. The data bit are written to the RAM while /CAS is low, so the brief /BDRE pulse should cause no conflict. I'd say these are glitches, but harmless ones. 

Replacing the NMOS SCC with a CMOS SCC did not improve things, apart from reducing the current drain to 1.1 amps.

I fitted a 1000u cap in C2, it did not fix anything but it did allow the 30 MHz oscillator to be fitted and run without glitching. I also noticed the screen would sometimes resemble (with many errors) the proper sign-on screen or formatted output (before being overwritten).

Decoupling seems to be very sparse. There are no 100n decouplers for the CRTC and SCC which are the most current-hungry chips, judging by their warmth. The CPU and the 6522 VIA have only one 100n cap between them. U16 and U24 have no decoupler at all.

These caps added underneath:

This cap added on top:

This did not cure the problems. Usually just crashed with random garbage on screen.

Sometimes I got what looks like a top line of garbage:

Possibly text:

Or several lines of text:

I'm guessing this one is some kind of register dump. Registers on the 3rd and 4th rows, flag dump on the right of the 2nd row. Perhaps users with working machines can recognise what this screen is. AI suggested it to be a Motorola 68000 exception crash dump screen with something like this kind of text:

Exception: Address Error      SR=$2700  PC=$00014B20
Vector: 03  Instruction: 4E73   (Note: S=Supervisor, I-L... )
D0-D7: 00000000 0000FFFF 00000000 00000000 0001C120 000021A4 00000000 00001000
A0-A7: 00FF0000 00001F24 00000000 00000000 0001D1A2 00FFFFFF 0000E000 00FFFE00

Stack Frame:
00FFFE00: 0000 0001 4B26 0003 4E73 0000 0000 0000    [ ....K....Ns.... ]
00FFFE10: 0000 1F24 00FF 0000 0001 C120 0000 21A4    [ ...$....... .!. ]
00FFFE20: 0000 0000 0000 1000 0001 D1A2 00FF FFFF    [ ............... ]
00FFFE30: 0000 E000 00FF FE00 0000 0000 0000 0000    [ ............... ]
00FFFE40: 0000 0000 0000 0000 0000 0000 0000 0000    [ ............... ]
00FFFE50: 0000 0000 0000 0000 0000 0000 0000 0000    [ ............... ]
00FFFE60: 0000 0000 0000 0000 0000 FFFF FFFF 0000    [ ............... ]
00FFFE70: 0000 FFFF FFFF 0000 0000 FFFF FFFF 0000    [ ............... ]
00FFFE80: 0000 FFFF FFFF 0000 0000 FFFF FFFF 0000    [ ............... ]
00FFFE90: 0000 FFFF FFFF 0000 0000 FFFF FFFF 0000    [ ............... ]
00FFFEA0: 0000 FFFF FFFF 0000 0000 FFFF FFFF 0000    [ ............... ]
00FFFEB0: 0000 FFFF FFFF 0000 0000 FFFF FFFF 0000    [ ............... ]

Blurry text is probably due to the TV, it is not the camera. My video connection was not ideal, taking video from the jumper and ground from pin 5 of J2. I cobbled a connection to the D-type connector J7, which gave a very slight improvement but still not readable text. It is 80 column, so not surprising. 

The video transistor is a BC337 which is pretty good. Transition frequency is 100 MHz, gain is 100 to 630, so it should not be struggling at all.

I should get a scope on the video signal to see how square the edges are. I suspect this is a dead end; displays with 64 us lines do not have bandwidth for 80 column, and those that have the bandwidth have 32 us lines. Unless you have the kind of monitor that forthnutter has.

I wonder if my baseband to HDMI up-converter has the bandwidth for this project?