Date   : Wed, 07 Dec 1994 11:41:16 -0600
From   : barnett@... (David Barnett)
Subject: Re: BBC screen emulation

I wrote:
>
>;It is not surprising that screen emulation is time consuming.  What is
>;needed is a scheme to optimize the emulation while being as faithful as
>;possible.
>

and Chris Lam replied:
>
>The way the beeb screen is bit mapped is also horrible. I haven't come
>across any games which modify the CTRC registers in a video interrupt,
>they seem to modify the ULA video registers instead to change colours,
>modes etc.
>
>my graphics routine has 3 stages:-
>
> a) process beeb vram into pixel map (for Mac)
>
> b) this pixel map holds LOGICAL colours. convert to their PHYSICAL colours
>
> c) call the Mac OS routine to draw the pixel map.
>
>
>Stage c) is the time-eater but there's not much that can be done about that.
>

Here's a scheme which may reduce the cpu time routinely expended on the screen:

In b) store a palette code as part of the logical code and use the host's
palate settings to translate this extended logical code to the displayed
palate.  This would allow the flashing colours to be implemented by palette
switching just as the BBC does it now.

Why have an extended code?  If it weren't for Elite style switching I
shouldn't bother.  But Elite style switching defines regions where
different palates may be in effect.   These can be given labels.  For
example, let us suppose that the Host screen has 8-bit depth.  This allows
4-bits for BBC logical colour and up to 16 palate regions with the
extension (I doubt there is any game which has more than one or two palate
regions on the same screen).

Writes to the Vid.Proc.ULA would define the region boundaries as I wrote
before.  During nominal frame blanking one could examine the screen to see
if the palate had changed anywhere.  If the palate changes coincide with
existing regions, there is no need to do anything but redefine the
corresponding host palate for that region.  If a new region has emerged
then a free palate code must be assigned to that region and the extension
of the logical colour changed in those pixels.  This will be a rare
occurence.  For simple screens, the extension will always be zero.  Writes
to any given pixel will add the palate extension for the region in which it
lives.

As for c), one can block the screen into regions (say 16 or 256) and only
call the host pixel mapper for those regions which have changed.  There are
often long stretches when the screen changes little: it seems silly to
redraw the screen when nothing has changed.  Even many fast moving games
don't change everything on every one of the 50 fields per second.

David Barnett
U.T.Austin