Odd behaviour with screen banks

While toying around with BASIC, I noticed that screen banks are not handled correctly:

MODE 800,600,16:REM Make some room for screen banks
MODE 640,480,8:OFF
ORIGIN 240,80
FOR bank%=1 TO 6
  SYS6,112,bank%:REM Change VDU bank
  REM If the display bank is changed as well, the output is correct
  VDU 5:MOVE -240,820
  PRINTSTRING$(16,"Test "):REM This should never be seen
  VDU 4
  CLS:CLG
  GCOL 200-bank%*16,200-bank%*16,200-bank%*16
  FILL 0,0
  FOR x%=0 TO 7
    FOR y%=0 TO 7
      GCOL x%*32,y%*32,bank%*32
      REM Seems to depend on the colour whether the rectangle is drawn
      REM on the display bank or the VDU bank
      RECTANGLE FILL x%*100,y%*100,99,99
      GCOL 255,255,255
      LINE 0,y%*100,800,y%*100
    NEXT y%
    LINE 0,y%*100,800,y%*100
    LINE x%*100,0,x%*100,800
  NEXT x%
  LINE x%*100,0,x%*100,800
  PRINTTAB(0,1);"Bank: ";bank%:REM Should be on all screens
NEXT bank%
FOR bank%=1 TO 6
  SYS6,113,bank%:REM Change display bank
  t=GET
NEXT bank%

BASIC isn’t to blame, if I use the ROOL interpreter on my RISC PC, the program works as intended.

Martin Bazley’s game Magic Mushrooms illustrates this behavior, too.

I use an BeagleBoard xM. This bug appears on the RISC OS builds of the 27th June 2011, the 28th February 2011 and some earlier build as well.

To celebrate the 100th silent view of my post, I present two animations of the output of the above (slightly modified) program:

This shows the correct output.
What the BeagleBoard makes of it, is shown here .

Seriously, I wonder if the silence means that this bug doesn’t bother anyone or if my BeagleBoard is the only one experiencing it.

EDIT: Here is the program for download

I can confirm that I get very similar effects to you on my BB-xM too.

Seriously, I wonder if the silence means that this bug doesn’t bother anyone or if my BeagleBoard is the only one experiencing it.

Or possibly I forgot about this thread before finding the time to look into the bug :-)

I’ve now checked in a fix for the bug (the OMAP video driver was doing the hardware accelerated copies/fills to the wrong screen bank), so assuming Steve hasn’t already started building the updated ROM that I asked him to build an hour or two ago, this fix should appear in an updated OMAP ROM download some time in the next day or two. And if he has already started the build then I guess I’ll have to hurry up and fix some more bugs just to justify me asking him to do two builds in one week ;-)

Thanks for the animations & sample code, by the way – I was able to guess what the problem was even before I ran anything!

Good news – the fix made it in to the ROM image that’s now available from the downloads page.

Ah ha, this might explain a few odd things I was getting when running some tests on the BB XM using multiple display banks from BASIC. Excellent!

Great, everything works as expected. Thanks, Jeffrey!