Date   : Tue, 06 Jan 2015 19:26:05 +0000
From   : etljwk@... (John Kenyon)
Subject: Serial console active at power-on

Apologies in advance for the lack of attribution/mis-attribution...

On 06/01/2015 12:55, Peter Coghlan wrote:
>>> Something to be careful about - if your remotely-controlled Beeb issues 
>>> a VDU 14 you will have to somehow manually press the SHIFT key to get 
>>> the display to scroll! It's worth putting an intercept on WRCHV to 
>>> always disable VDU 14.
>>>
> Also, be careful not to just discard every attempt to send 14 through WRCHV.
> It could be part of a multi byte VDU sequence such as VDU 1 or VDU 31 for
> example.  Unfortunately, it is necessary to keep track of which VDU sequence
> is being sent and ignore the correct number of bytes for the sequence in
> question.
>

My first thought was to exploit a counter somewhere in the VDU workspace
to keep track of whether this was
"VDU 14" or "VDU 17,14".
A quick google brought me to http://mdfs.net/Docs/Comp/BBC/OS1-20/ and
then to
http://mdfs.net/Docs/Comp/BBC/OS1-20/C300

The search for the counter was cut short when I saw the VDU status byte
at D0.

If you keep bit 2 of this byte reset, you'll never go into paged mode.

PHA
LDA #&FB
AND &D0
STA &D0
PLA
JMP (&wherever you stored the old WRCH vector)

would do the trick - the LDA/AND/STA is stolen from the OS1.2 VDU 15 code.
The new WRCH resets the bit and then hands off the character to the old
routine with no attempt made to
intercept VDU 14. If VDU 14 is issued, then the next character would
reset the flag anyway.
This method also thwarts any non-OSWRCH attempts to enable page mode.

The idea is to block the undesired behaviour (entering paged mode),
rather than the undesired VDU code.

Not sure if this would work on a Master though...

/John