Date : Sun, 10 May 2015 18:49:42 +0100
From : julianbrown99@... (Julian Brown)
Subject: The mythical chunky graphics mode
Hi,
A while ago I happened across a page that describes how to set up a
"chunky" graphics mode on the BBC micro:
http://modelb.bbcmicro.com/tech-chunky.html
I've been experimenting with this idea, but hitting some very strange
failures: basically "chunky" mode works fine in an emulator (b-em v2.2 on
Linux, to be specific), but on real hardware -- depending on the BBC model
-- it either doesn't work at all, or works only with some caveats. I'm
using the composite video outputs of my beebs (with colour burst enabled),
attached to an LCD TV/monitor.
On a Master:
* Initialising a "chunky" mode using the low-speed CRTC clock (modes 4/5/6)
works fine.
* Initialising a "chunky" mode using the high-speed CRTC clock (modes
0/1/2) gives the expected result for every other byte, but the in-between
bytes are scrambled: this is partially explained by
http://beebwiki.mdfs.net/Address_translation (the XOR'ing of the MA6 line
with the 1MHz clock), but the logic in the Master's CRTC MUX appears to be
more complicated: either MA6 or MA7 is toggled, depending on the value of
RA0. (Our supposition is that this is because there are more rows in the
Master's DRAM chips to refresh).
This is understandable (though not behaviour that is emulated correctly by
b-em!), but means that a true "high-resolution" chunky mode is impossible
on the Master.
So, I thought I'd try on a Model B instead, only to find that the technique
does not work *at all* there! I expected low-speed CRTC-clock "chunky" mode
to work as-is, as it does on the Master, and for high-speed CRTC-clock mode
to work also, albeit with the 6th address bit toggled on every other byte.
This would have given a usable result, if mildly awkward.
But, it seems that the horizontal and/or vertical sync pulses are getting
corrupted somehow, simply through asserting TTXVDU in a given mode.
You can try this yourself easily enough from BASIC (at your own risk!):
e.g. something like,
10 MODE4
20 VDU23,0,12,&28,0,0,0,0,0,0
30 FOR A%=&7C00 TO &7FFF
40 ?A%=255
50 NEXT
Rather than the expected solid-white screen, this gives a signal that my
monitor (at least) cannot lock onto.
A friend and I have been staring at the schematic for a while, and can't
make any sense of this! Does anyone know what's going on? Has anyone ever
got this working? Why does it work on the Master (even as far as it does),
if not the Model B?
(Possible ideas: IC15 sinks all the current from D0-D7, leaving IC6 (Video
ULA) in a strange state, or IC5 (SAA5050) emits non-zero nonsense on its
RGB outputs and IC6 just OR's them together with its own RGB values --
expecting the former to be zero when bit 1 of the video ULA control
register is zero -- instead of muxing them properly? Neither of those would
really explain why the syncs are getting broken though, I don't think.)
Thanks,
Julian