Determining Graphics Modes

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Determining Graphics Modes

Post by julie_m » Fri Sep 06, 2019 9:43 pm

Is there a proper way (e.g. an OSBYTE call) of determining the current screen mode which is portable across all the 6502-based BBC models?

I know about reading &355 on OS1.2 (model B), but does this also work on the Master 128 &c.? And what about running on a second processor, at the other end of the Tube?

Thanks in advance. J.

User avatar
dv8
Posts: 243
Joined: Mon Jun 22, 2009 9:07 pm
Contact:

Re: Determining Graphics Modes

Post by dv8 » Fri Sep 06, 2019 11:20 pm

OSBYTE &87 (135) returns the current screen mode in Y.

The value returned is always 0-7 regardless of whether a shadow mode (128-135) is in use.

&355 can be used on both the Model B and Master but only by code running on the i/o processor, it won't work across the Tube. The OSBYTE call should be used in preference to directly accessing the MOS variables.

tom_seddon
Posts: 326
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Determining Graphics Modes

Post by tom_seddon » Fri Sep 06, 2019 11:32 pm

$0355 is one of the VDU variables, which you can query using osbyte $a0. And on B+/M128, shadow RAM state is bit 4 of the VDU status byte, which you can query using osbyte $75. I assume that bit of the VDU status byte is always clear on the B? - might be worth checking the system type with osbyte $00, I don't know.

To restore the mode so detected, I think you just need to select modes 0-7 if shadow RAM off and modes 128-135 if shadow RAM on - then you'll always get the right result.

BeebWiki has a similar suggestion: http://beebwiki.mdfs.net/Reading_screen_mode - though it uses osbyte $87 to read the mode. That's an option, but I figure you might as well just read the VDU variables, the layout of which appears to be part of the API, judging by the Master Reference Manual part 1. (which is an excellent resource, being quite comprehensive, and about as modern and official a reference for the 8-bit Acorn MOS API as you'll find...)

--Tom
Last edited by tom_seddon on Fri Sep 06, 2019 11:34 pm, edited 1 time in total.

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: Determining Graphics Modes

Post by julie_m » Sat Sep 07, 2019 12:11 am

Brilliant. Thanks very much! I remember OSBYTE &87 on the BBC as being roughly equivalent to SCREEN$ on the Spectrum ..... forgot all about Y, though.

BCP (rather boringly) is not making any direct writes to screen memory, so it does not need to know if or not shadow memory is in use. I just need to know how many colours are available.

User avatar
jgharston
Posts: 3641
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Determining Graphics Modes

Post by jgharston » Sat Sep 07, 2019 9:17 am

tom_seddon wrote:
Fri Sep 06, 2019 11:32 pm
BeebWiki has a similar suggestion: http://beebwiki.mdfs.net/Reading_screen_mode - though it uses osbyte $87 to read the mode. That's an option, but I figure you might as well just read the VDU variables,
It's not an option, it's *THE* *SPECIFIED* API.

Use OSBYTE &87, as that is the defined API to ask for the screen mode. Reading the VDU variable is reading a VDU variable, &0355 just /happens/ to just happen to contain a number related to the current screen MODE. The OP *SPECIFICALLY* asked for compatibility across all platforms. If the platform you're running on has extra MODEs, it's close to impossible that &355 will contain the MODE number - and in fact will destroy the functioning of the VDU drivers if it doesn't contain 0-7 - but the defined API for asking for the screen MODE - OSBYTE &87 - is the one that is able to be intercepted and changed.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3641
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Determining Graphics Modes

Post by jgharston » Sat Sep 07, 2019 9:22 am

julie_m wrote:
Sat Sep 07, 2019 12:11 am
BCP (rather boringly) is not making any direct writes to screen memory, so it does not need to know if or not shadow memory is in use. I just need to know how many colours are available.
That's a different question. If you want to know how many colours are available, the question is "how many colours are available?" not "what is the current screen MODE?"

OSBYTE 160,96 returns the colour mask - the maximum number of colours minus 1 (which will be zero for MODE 7).

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Rich Talbot-Watkins
Posts: 1533
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Determining Graphics Modes

Post by Rich Talbot-Watkins » Sat Sep 07, 2019 11:37 am

jgharston wrote:
Sat Sep 07, 2019 9:22 am
OSBYTE 160,96 returns the colour mask - the maximum number of colours minus 1 (which will be zero for MODE 7).
Although that's also reading a VDU variable, so that's as tied to an Acorn 8-bit platform as reading the current mode via VDU variable &55. On RISC OS you'd do it via SWI OS_ReadModeVariable, 3 (or 9).

I think if you're specifically targeting an Acorn 8-bit platform, reading the current mode via the VDU variable is just as valid as using OSBYTE 135 (and certainly quicker).
Last edited by Rich Talbot-Watkins on Sat Sep 07, 2019 12:01 pm, edited 1 time in total.

Post Reply