Click Here To Go To The Your Computer Archive



Written By Fintan Culwin


Cover Art
Click Here To Enlarge Loading Screen

Loading Screen
Click Here To Enlarge Opening Screen

Opening Screen
Click Here To Enlarge Screenshot

Game Screenshot

Virtual Screens

Fintan Culwin with a routine that implements two or more independent screens on the BBC

In this article I will explain the concept of virtual screens and explain how the facility can be implemented on the BBC by a combination of in-built firmware and the machine-code utility presented. In order to do this it will be necessary to address screen memory directly. I will explain the basis of what I believe to be the best method of calculating a screen memory address.

Virtual screens can be configured on some other machines. The basis of the screen is to allow a multi-coloured mode to be used as two or more independent screens. Each virtual screen will have a lower number of colours, but the division does not take up any more memory. Applications for virtual screens include: having a permanent "help" screen on one virtual screen which can be accessed . immediately from another virtual screen; allowing each user in a multi-user application to have an independent screen area; producing a screenful of information without the user seeing it; and revealing it instantaneously.

This last use of virtual screens is already partly catered for in the BBC's firmware. By using the VDU 19 command a logical colour can be assigned to the current background colour. Information can then be put on to the screen in this colour, without actually visible. A second use of the VDU 19 command will then reveal the information - see User Guide page 164. What is not present in the BBC's firmware is a straight-forward method of removing the information so presented per-manently from the screen.

This system will allow a four-colour mode to be used as two two-colour virtual screens. The 16-colour mode can be configured as two four colour screens, four two-colour screens, or a two-colour screen combined with an eight colour screen.

In order to explain how virtual screens can be produced it will be necessary to look at how colour information is coded in screen memory. In a four-colour mode each pixel is controlled by two bits in memory, this gives four possible combinations - 00 01 10 II; corresponding to the four permissible colours. In the 16-colour mode each pixel is controlled by four bits; giving the 16 possible combinations.

To return to the four-colour mode, if the left-hand and right-hand bits can be set and cleared independently in combination with the VDU 19 command then two independent screens can occupy the same memory space. It is possible to set the bits by using logical colours I and 2 respectively. Logical colour 0 is the background colour naturally and colour 3 will be displayed or set according to both bits and has to be ignored as a physical colour with virtual screens.

An example may make this clearer: If a pixel is to be displayed in virtual screen one then the right-hand bit has to be set. If it has to be displayed in virtual screen two then the left-hand bit has to be set. If both bits are set then the pixel will be displayed in both screens one and two. Consequently, when logical colours are assigned to display a virtual screen; colour three has to be assigned to the same colour as colour one or two. Similar considerations apply to the 16-colour mode working on four rather than two bits.#

For a logical colour to be removed from the screen the bits which control it have to be cleared. To clear logical colour one the right-hand bit has to be cleared. This will have no effect on logical colour two controlled by the left-hand bit; but will affect logical colour three controlled by both bits. The effect will be to reset the pixel from logical colour 3 to 2, which is exactly what is required. The facility to clear just one bit in screen memory is not catered for in the firmware. The routines included here do just this. A set of procedures for controlling 16-colour mode virtual screens are given in listing 2.

Having outlined how colour information is controlled by two or four bits, before presenting the utility, it will be necessary to show how these bits are organised in memory.

Screen memory occupies space between HIMEM for any mode and location 8000 hex. For a four-colour mode each byte will control four pixels. For the 16-colour mode each byte will control two pixels.

The relationship berween where a byte appears on the screen and where it exists in memory is equally complex. For all modes apart from Mode 7 the first eight bytes from HIMEM onwards control an area of pixels on the top left-hand side of the screen. The next eight pixels control an area to the right of this. This continues until the right-hand side of the screen is met. The next byte either HIMEM + 320 or HIMEM + 640 and the subsequent seven bytes control an area underneath the area controlled by HIMEM to HIMEM + 7.

Each complete set of 320 or 640 bytes corres-ponds to one row of characters on the screen. If we want to calculate a memory address from the X, Y text co-ordinates, each X co-ordinate will increase the memory address by 640 or 320 from HIMEM. All the published algorithms which I have seen concentrate on ingenious methods of multiplying by 320 or 640, in order to obtain the address.

This is totally unnecessary as a faster method is available within the firmware. Within the operating system Rom two tables are maintained - one for multiplying by 640 used for Modes 0 to 6 and one for multiplying by 40 for Mode 7. In order to find out the increase in memory address above HIMEM, all that is necessary is to use the X co-ordinate as an index into this table.

Once the virtual utility is installed in memory, either by assembling it from the code presented, or by loading a previously assembled version into memory, it can be used in one of two ways. Both methods require it to be called with the first integer parameter indicating the virtual screen to be cleared. If this is the only parameter then the whole screen will be affected.

The second method will allow only a section of the screen to be cleared. The Call must now be accompanied by five integer parameters, the first is the virtual screen as before, the next four are the X left, X right, Y high and Y low co-ordinates defining the area to be cleared.

The X co-ordinates are based on a 80-column screen for Modes I and 2. A 40-column resolution is available for Mode 5. No range checking is performed on these co-ordinates; any outside the range will cause unexpected and possibly dramatic effects. If an incorrect number of parameters are passed then a "virtual error" error message will be given.

To use the assembler code an assembly address will have to be given and the screen mode selected. After the code has been assembled, a test routine will be initiated and information given to allow the code to be saved. As conditional assembly is involved the precise length of the code cannot be given. It will assemble in its longest version into less than two pages of memory (/K). A different version of the code will have to be assembled for each screen mode. The notes that follow should help you understand what each section is doing.

The first procedure met is Proc-Options which selects the mode to be configured and the assembly address. Various flags are then set according to the mode chosen.

Within the actual assembly loop Proc-Data is used to set up a data block. Most of these are used within the program. The location labelled "table" is a page zero address initialised to point to the *640 table at address &C375. The location labelled "rnowdc" contains the mode the code is assembled for, and "bitlen" contains 320 or 640 depending on the mode chosen.

The parameters are processed by the code assembled by Proc-Pararneters. This contains the entry point to the code labelled "entry". It commences by testing the current mode of the machine and branching to the error message if this is incorrect. The number of parameters passed is then tested and the error message used if this is inappropriate - see User Guide page 214 for an explanation of how the parameters are picked up. The parameters are then either picked up from the information given in page 6 or set to the default, whole screen mode. This section exits to "main". The production of a basic error message, from a machine-code routine, is explained in the User Guide page 446.

Main commences by obtaining the virtual screen colour to be cleared and setting a mask according to four or 16 colour needs. The base screen address is then calculated from the formula HIMEM + Ylow*(320 or 640) + Xleft*8. Each row is then processed in "one-row", the base address updated by "bitlen" and a check made to see if all rows have been processed. The main return terminates this routine.

Proc-Screen contains the routines which actually control the screen. The routine labelled "one-row" processes one row of the screen. A copy of the value in xleft, and address are taken. One character is processed, the copy of xleft and the copy of the address updated, and a return is made if all the characters in that row have been done. "One-char" processes an eight byte block pointed to by "taddress" using the . mask previously calculated.