Date   : Tue, 06 Dec 1994 11:47:11 -0600
From   : barnett@... (David Barnett)
Subject: BBC screen emulation

Hi all,

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.

If all programs used simple modes, then simple trapping all writes to the
screen and duplicating them to the host would be OK and the overhead would
be small.

However, some games (such as Elite) made ingenious use of timers to achieve
multiple screen modes.  Even so, a full simulation of the hardware is not
needed because the best they could do was change the mode at a line
boundary (it was impractical to do multiple switches every 64us).

Suggestions:

1a.  Maintain a line by line list (256) of Vid.Proc. register settings.
1b.  Better - maintain a list of lines where the vid.Proc. changes and
their values.  At a mode change you would be working hard (but for a
limited time).

In either 1a or 1b above, the effect of the programming in Elite and
similar games would be to set the boundaries.  since the emulator would
know what was being sent to the Vid.proc control registers it would know
whether it needed to add or subtract changes to its list.  1b. is better
because a setting high on the screen affects what happens lower.

2a.  Limit updates of the real screen to the nominal frame blanking period
on the BBC.
2b.  Because much of the time much of the screen is static, it would be
good to avoid rewriting the real screen when nothing has changed. One could
maintain a list of screen regions (perhaps lines) to which the BBC has
written (but which have not been transferred to the real screen) and only
send those.  During a major screen update things would slow again but then
the BBC could only operate so fast anyway.

I haven't worked out all the issues like rapid palette changes affecting
the whole screen.  Any ideas?

David Barnett
barnett@...