GCOL 4 background colour

[Deleted User 9295]

I had always believed, or at least assumed, that in the GCOL 4,n statement the value of n was ignored (apart from the MSB of course) because GCOL 4 implies the colour - it is the inverse of the existing colour. So for example GCOL 4,129 and GCOL 4,130 would have an identical effect; Indeed all my BASICs which include VDU emulations behave this way.

However I've recently discovered that it's not true. On Acorn systems (and in Matrix Brandy) the colour number does have an effect in one specific case, the DEL character in VDU 5 mode:

Code: Select all

   10 MODE 2
   20 VDU 5,30
   30 d$ = CHR$&7F + CHR$&7F + CHR$&7F
   40 GCOL 4,129
   50 PRINT "GCOL 4,129:    " d$
   60 GCOL 4,130
   70 PRINT "GCOL 4,130:    " d$

I am surprised that for 30 years or so nobody has spotted that my BASICs get this 'wrong' (I still think my interpretation is logical, but it's not what the 'reference' systems do). I will fix this in future releases of BB4W and BBCSDL.

[joachim]

Interesting observation, lying as it does at the intersection of "when does graphics background colour matter?" and "when does GCOL4 colour matter?"

It seems that the analogue is true for other GCOL modes: when backspacing in VDU5 mode, a GCOL mode of 1, 2 or 3 is also ignored and the GCOL background colour just overwrites what was on the screen (as if the GCOL background mode were always GCOL0).

I agree with Richard that this feels like a bug in the reference implementation, as I can't think of any justification for why the VDU5 backspace behaviour should be different from CLG, which does correctly use the GCOL mode.

[Deleted User 9295]

I can't think of any justification for why the VDU5 backspace behaviour should be different from CLG, which does correctly use the GCOL mode.

If I was trying to justify it, I'd say that the purpose of DEL is to 'erase' the preceding character, and you're only guaranteed to 'erase' it if you plot in GCOL 0 mode. In any of the other modes the character may remain visible, albeit possibly in a different colour from what it was.

So I think you can argue for both behaviours: respecting the GCOL mode because that's what CLG and the 'PLOT background' codes do (e.g. PLOT 7), or not respecting it because you want to 'erase' the character.

[flaxcottage]

If I was trying to justify it, I'd say that the purpose of DEL is to 'erase' the preceding character, and you're only guaranteed to 'erase' it if you plot in GCOL 0 mode.

That has been my view for ages. Several of my programs have depended on the effect of DEL to erase the character when using text in a graphics mode.

[Deleted User 9295]

Several of my programs have depended on the effect of DEL to erase the character when using text in a graphics mode.

Same here, but in those programs I don't change the background GCOL mode so it doesn't make any difference (it's pretty rare for the background GCOL mode ever to be changed - plenty of people don't even know it's possible or what effect it has!).

Since nobody has spotted the difference in behaviour in 30 years it's not something that I consider requires changing urgently! But I will fix it in the next releases (which should be relatively soon for BBCSDL, but is likely to be some months away for BB4W).

[jgharston]

Yes, digging into the MOS 1.20 code it does do:
.LCAC7
LDA #&7F :\ for graphics cursor
JSR LD03E :\ set up character definition pointers
LDX &035A :\ Background graphics colour
LDY #&00 :\ GCOL plot action 0
JMP LCF63 :\ invert pattern data (to background colour)

It would have only needed one more byte to do LDY &035C ; VDUVAR_GCOLbgdaction.

I've never implemented VDU 5 mode in any of my VDU drivers, so I've not stumbled across this myself.

[Bobbi]

Maybe we will do VDU5 mode in Applecorn though?