Date   : Sun, 10 May 2015 21:31:23 +0100
From   : julianbrown99@... (Julian Brown)
Subject: The mythical chunky graphics mode

On 10 May 2015@..., J.G.Harston <jgh@...> wrote:

> Try:
> 10 MODE4:VDU 28,0,31,39,0
> 20 VDU23,0,12,&28,0,0,0,0,0,0
> 30 FOR B%=1 TO 10
> 40 FOR A%=32 TO 126:VDU A%:NEXT A%
> 50 NEXT B%
>
> This defines a text window to stop hardware scrolling reprogramming the
> CTRC registers, and prints lots of characters to demonstrate what is
> happening.
>
> MODE 4 puts the display into bitmap mode, but VDU 23,0,12,&28,etc sets
> MA13 which tells the video hardware to address memory as though in
> teletext mode, so scans through &7C00-&7FFF to fetch the bitmap, with
> the same byte read for every scan line.
>
> Oddly, there's a bit in the video ULA that selects the teletext RGB
> source, and the bit from the CRTC that selects the teletext memory
> addressing. You would have thought there would have been a single
> hardware flag that both selected the MODE 7 memory map and told the
> video ULA to read RGB from the teletext IC. Though it does allow you to
> program the system to display teletext data from anywhere in the bitmap
> memory.


The split enable bits are precisely what enables the "chunky" mode to work:
you program the video start such that MA13 is set, but leave the ULA
displaying the "raw" bytes read from memory, rather than the data as
processed by the teletext chip.

Your program does the same thing as mine on my Model B over composite
video, of course -- causes the screen to lose synchronisation.

Our suspicion is that something's breaking the display-enable signal coming
out of the CRTC and fed into the video ULA via IC38/IC41: that might mean
that RGB data is being output whilst the sync pulses are being emitted,
when for correct operation it must be zero (i.e., black). With the RGB
output, it's not so important if those channels are non-black, because the
combined sync signal is separate from the colour information anyway.

But why would that be happening?

Julian