Screen bank selection kills the machine?

Hiya,

Interesting bug found using a RISC OS 5 image – works fine on non-RISC OS 5, as far as I can tell, but leaves a RISC OS 5 machine broken.

SYS "OS_Byte",&70, 3-255:REM Select invalid bank for VDU
PRINT "Bank INVALID (should leave us in bank 1)"
SYS "OS_Byte",&70, 1:REM Select bank 1 for VDU (default bank)
PRINT "Bank 1 again"

The ‘3-255’ was found due to a bug in my own code; I was using the wrong value when I called OS_Byte 251 (I should have been using OS_Byte 250).
The result of the above code is a dead machine, as far as I can tell – it might have aborted and printed a message somewhere else, but more likely it’s writing to invalid memory and aborting, and then reporting the error by writing to the screen… and repeat.

The correct behaviour is to select the bank if possible, and if not to ignore the request.

This also highlights a bug with OS_Byte 250/251. The Display bank is being returned as 0; it should be returned as 1. The banks in use, returned from OS_Byte are the actual bank numbers 1, 2, etc. The value 0 is an input value to OS_Byte 112/113 which means ‘use the standard shadow value for the mode you’re in’, because as we know, we’re running on a BBC Master and default Shadow Banks are a thing :-)

This can be observed with:

SYS "OS_Byte",&FA TO a,b,c
PRINT a,b,c
        250         0         0

The values should be 250, 1, 1 by default, or 250, 2, 2 if a shadow mode were selected.

You should use SYS “OS_Byte”, 250, 0, 255 as documented in the PRM.

Oops; that was an incorrect example then – one of the problems of having to retype the commands:

SYS "OS_Byte",&FA,0,255 TO a,b,c
PRINT a,b,c
        250        0        0

ie exactly the same as I stated, but I had omitted the X and Y parameters.

ie exactly the same as I stated, but I had omitted the X and Y parameters.

Is that introduced to RO5 at some point or a lingering bug from RO3.7 trickling through?
RO3.7 image in RPCEmu and RO5 in RPCEmu should give quick comparison.
(Bundle installs exist, although the Direct image is a tad over the top for testing)

BTW. When reporting RO5 bugs it is best to give the specific version number as the odd numbers are Dev and the bug might have been added/removed in a different version so even date strings are relevant.

Is that introduced to RO5 at some point or a lingering bug from RO3.7 trickling through?

Pass; I’m just reporting what I see. The equivalent does not happen on the Select image I use.
Regardless of where it was introduced, that it requires a reboot is undesireable.

I was using the RISC OS image supplied as part of the RISC OS bundle; the one you refer to, which is 5.27.

Given the ease with which it could be checked whether there is a problem or not, I didn’t bother posting the version numbers; apologies.

How I reproduce this case:

1. Obtain a linux or macOS machine with docker installed.
2. Run docker run -it --rm -p 5901:5901 gerph/rpcemu-5
3. Open a VNC session to localhost:5901
4. Select the RISC OS window.
5. F12; BASIC; SYS “OS_Byte”,112,3-255
6. Observe that the system is dead.

To reproduce on RISC OS 3.7:

1. Obtain a linux or macOS machine with docker installed.
2. Run docker run -it --rm -p 5901:5901 gerph/rpcemu-3.7
3. Open a VNC session to localhost:5901
4. Select the RISC OS window.
5. F12; BASIC; SYS “OS_Byte”,112,3-255
6. Observe that the system is not dead, and you can happily do things.

Or use whatever version of RISC OS you have to hand.

The equivalent does not happen on the Select image I use.

You’re probably using a late release of Select.
I forget how many different bug fixes were listed in the release information for the various iterations of Select.
Sadly, the politics of the time have echoes in this time in various aspects of RO5, not the least being bugs fixed there that still remain here.

I was using the RISC OS image supplied as part of the RISC OS bundle; the one you refer to, which is 5.27

I don’t recall offhand what date version that comes with but I do know that it works quite happily with the ROM from the 5.28 stable RO soft load – dig in the zip for the “riscos” file to drop into the RPCEmu “roms” directory.

Or you could use the current 5.29 stream “nightly” release labelled as Beta IOMD softload which is “bleeding edge” and once in a blue moon won’t work

Anyway, to the point:

Case 1 = RO5

6. Observe that the system is dead.

Case 2 = RO3.7

Observe that the system is not dead, and you can happily do things

It’s an introduced bug somewhere in the transition from 3.7 via 3.8 via PACE and into RO5, or even more recent.

It would need testing in versions like 5.22 and 5.24 to establish how far back (narrows the source revision search) further refinement would be from a “binary search” technique testing with mid-point jumps of a block of releases to home in on a period where specific affecting changes occurred.

Preaching to the converted? You’ve been through the sequence before, more times than me probably.

When was the GraphicsV stuff done?
Not blaming it, just seems to me that a known large modification to the way graphics stuff works might be a good split point for a test to see if the problem happens before/after.

BTW, Charles, there are numerous versions of the odd numbered releases, so when reporting stuff like this it can be useful to give a build date as well, if nothing else it can line up with something in the revision history.

Okay, a lot of stuff was done November 2018: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/commit/d87c22a426bf271fcc9fd2fcb3fc6dd1c8c900f0

Then more back in December 2013: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/commit/694750de01877246840ef6c9cd2a3abb1415f6d9

So those might be useful checkpoints to try?

Then more back in December 2013: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/commit/694750de01877246840ef6c9cd2a3abb1415f6d9

November 2013 kaput frozen display…

Same with 2012-03-18 ROM

Whatever the cause it’s been there a fair while.

Edit – that takes us back to RO5.19 BTW.