|
LegacyScreen
Introduction
The LegacyScreen module provides a limited amount of compatibility for applications which are not aware of the changes introduced to graphics system. It cannot ensure complete compatibility with all applications, but should allow many to function unaffected. There are three functions that the module provides, each of which is intended to avert problems seen with earlier applications :
- Dummy screen dynamic area
- Direct loading of files to screen memory
- Force use of double banking
Dummy screen dynamic area
With the introduction of multiple screen drivers it is no longer sensible to use a single dynamic area for the frame buffer. Dynamic area 2 (screen memory) has therefore been removed from the Kernel. Many applications will attempt to resize dynamic area 2 in order to ensure that there is sufficient memory available for a mode, or the banks within a mode. The LegacyScreen module allocates dynamic area 2, with a maximum size of 2MB, for this purpose. This ensures that the changes in size which the application applies will succeed. The content of the area is undefined.
To check whether sufficient memory is available for a mode, OS_CheckModeValid can be used.
To check whether multiple screen banks can be used, one of two methods may be employed. The application may select the necessary number of banks and at each stage confirm that the bank requested has been selected (see OS_Byte 112 in PRM 1). Alternatively, OS_ScreenMode 7 may be used to count the number of available banks for the hardware. Note, however, that it is still necessary to select the banks before accessing them in order to read their base address and to inform the driver that multiple banks will be used.
Direct loading of files to screen memory
Many applications will, after locating the frame buffer with OS_ReadVduVariables, attempt to load files directly into the buffer with an OS_File operation. The frame buffer is, in general, a physically mapped dynamic area. Physically mapped dynamic areas are not validated as being accessible with OS_ValidateAddress (see MemoryManagement.OSValidateAddress). This means that the OS_File operation would fail due to checking first whether the memory was valid. The LegacyScreen module will explicitly allow the loading of data to the screen in this way. It is not recommended that clients rely on this.
Force use of double banking
A number of applications will assume that the previous conditions regarding bank location and allocation remain in place. In particular, that resizing Dynamic Area 2 ensures that memory following the first bank will be free for use as a second bank, and that the second bank will start immediately after the first. Neither of these conditions are true any longer. Because of hardware limitations, it may not be possible to place the second bank immediately after the first, and the driver may wish to use the unused space for cached data such as sprites, internal workspace or pointer images.
The LegacyScreen module attempts to avoid these problems in numbered modes by forcing a second bank to be allocated when the mode is selected. This should ensure that applications which assume they may write to the memory immediately following the first bank will not corrupt internal data, at the expense of an extra bank being allocated from the video memory. This only applies to numbered modes.
The other problem - that of the second bank not being contiguous with the first - cannot be addressed by any means. The existing video drivers do not at present require any additional alignment, so the simple allocation of the second buffer is sufficient to allow many applications to function.
|
![[Select]](../imgs/seldoc.png)
