Geminus aims to extend the graphics capabilities of your RISC OS computer by allowing the use of additional screens, rotatable LCD panels and, later, DVI outputs. It can also accelerate rendering and screen redraws making the desktop feel much slicker. These features can be purchased individually, as desired.
Geminus is a software layer that sits between the RISC OS 5 kernel and the graphics card drivers, allowing it to extend and optimise many operations.
Additional features will be released over time, demoes will be available and users may purchase only those features which they desire.
If you are only interested in the acceleration code, click here to skip the sections on multi-monitor and screen rotation features.
For faster JPEG decoding see here.
For the Red/Blue colour swapping feature (supporting unmodified NVIDIA graphics cards) click here.
The primary graphics card, ie. the one which will be used when Geminus is not running, will be the lowest one when fitted in the tower case. Since IYONIX pcs are supplied with their graphics card in a 64-bit slot, this will likely be your original card.
We believe there is an issue with the use of multiple recently-supplied (JATON) graphics cards in the Iyonix and another, unrelated issue with the use of older cards (as shipped with pre-production machines) in 32-bit slots. To avoid both of these issues, we recommend that you install the second graphics card in a 32-bit slot (either of the two righthand slots that have shorter, white sockets on the motherboard).
Also some users may find that it helps to swap over their original graphics card and the USB card/terminator pair if they are installing their new graphics card in the slot closest to the existing cards. This can give slightly better clearance between the cards and eliminates any chance of the USB card's metal pins contacting the new graphics card.
Lastly, RISC OS 5.09 and 5.10 are modified slightly with the setup of your graphics card(s) when they are programmed into the flash ROM so it is inadvisable to change the card positions after programming. This decision was taken by Castle to resolve startup problems but, since it can prevent the machine from booting with alternative cards/positions, we sincerely hope that are more workable solution will be found.
When you have downloaded Geminus you will have a zip file that contains an application called !GemConfig. This application can be run in the normal manner by double-clicking on its icon but it is also designed to be installed as a Configure plug-in by dragging it into the directory
!Boot.Resources.Configure. If you do this a Geminus icon should appear in the Configuration window (viewed by double-clicking on !Boot) allowing you to configure Geminus in the same way that you configure other aspects of your computer.
To configure Geminus, open the Configuration window by double-clicking on !Boot and then Geminus (Or just double-click on the !GemConfig application instead). The window that opens has four panes -
The first pane ('Info') just shows a few details about the version of Geminus that you're running and the features that you have purchased. You can also learn more about other features that are available or under development, and visit the website to purchase them or learn more about their progress.
The 'Modes' pane is used to define your screen modes, but first you must tell Geminus the type(s) of the monitor(s) you are using, so that it can use the correct Monitor Definition File(s) (hereafter referred to as MDFs). An MDF describes the capabilities of the monitor and it's important that you use the correct file for your monitor, where one is available.
First, you should tell Geminus the location of your 'primary' monitor. This is the one that RISC OS appears on when you first switch on your machine, before Geminus is running. You may have this screen positioned on either the left or the right, and then choose the appropriate option in the 'Monitors' pane so that Geminus can create suitable mode definitions.
You then need to tell Geminus the type of each screen that you are using, by choosing a monitor type or MDF from the menu that opens to the right of each section:
If you have purchased the Red/Blue colour swapping feature (or 'PC RGB format') then you also need to tell Geminus the RGB order of each graphics card/monitor. For the standard NVIDIA graphics card shipped with the IYONIX pc, you should leave the 'PC format RGB output' option unticked. For cards that you source yourself or which are purchased through Spellings Ltd as 'unmodified', this option should be ticked because the card expects the Red and Blue components to be in standard PC order, not the order used within RISC OS.
If you have not purchased this feature, the 'PC format RGB output' tickboxes will be shaded and have no effect.
We strongly recommend that people using the red/blue colour swapping feature also purchase the acceleration feature because this makes a significant difference to the speed of the desktop. There is an unavoidable performance overhead in swapping the colour components in all direct screen accesses made by the OS and applications. Geminus, however, is aware of the existence of PC format screens and is therefore able to access them directly and with much greater efficiency, eg. when plotting sprites it will simply use a modified palette rather than modify the value of each pixel that is plotted.
Certain applications, notably video players, will exhibit much lower performance on colour-swapped screens until they have been modified to accomodate them via the Geminus API. Cino, the DVD player application, is aware of Red/Blue swapped screens and can thus modify its own output appropriately, giving equal performance on either screen type. In fact, since the NVIDIA cards are designed for use with PC RGB order, the reproduction of colours is better on screens that employ Geminus's colour swapping capability.
Now that it knows the monitor type(s) being used, it can suggest some suitable mode definitions, so click on 'Modes' to open the modes pane which will be empty when you first use Geminus. You will see a button labelled 'Suggest modes' which, when clicked, displays a window showing some likely screen modes. You can select any number of modes from this list using the SELECT and ADJUST mouse buttons in the normal way.
To add any of these modes into your configuration, simply drag them into the mode list in the main window. If you then select a mode in this list by clicking on it, you will see a graphical representation of this mode in the top half of the pane. This picture shows you the position and resolution of the monitors that the mode uses, and the portion of your desktop that will appear on each of the monitors. The red line on each monitor indicates its bottom edge.
By double-clicking on any monitor in this picture you can change its resolution, rotation and frame rate using the pop-up menus as shown below:
To start with, we suggest creating a mode that uses all of your monitors in landscape mode and - if they are rotatable - another that uses them in portrait mode, eg. if you have two LCDs each capable of 1280 x 1024, then amongst the suggested modes you should see two modes akin to the following:
Once you have added the desired modes to the list in the Modes pane, you can try them out by selecting a mode and clicking on 'Try.'
If you select a mode and click on the 'Try' button, Geminus will switch the desktop into that screen mode and display a countdown timer with the message "Do you wish to stay in this new mode?" If you click 'No' or do not respond within the 8 second time limit, Geminus will automatically revert to the previous screen mode, allowing you to recover if - for some reason - the screen mode is unusable.
The most likely cause of a mode that doesn't produce a stable, usable picture, is that you have a mode definition in your MDF which the monitor cannot handle. If this is the case, you should edit or remove that definition from your MDF to avoid confusion, or - alternatively - tell Geminus to use a different MDF for that monitor.
Once you have a set of modes that you are happy with, just click on the 'Set' button and Geminus will remember the modes and settings for you.
Geminus makes its modes available to you via an icon on the right hand side of the icon bar. A separate icon and window are provided in addition to the standard DisplayManager because Geminus is much more flexible and can be used to define many different screen modes all having the same resolution. Wherever possible Geminus will also make its modes available via the normal DisplayManager icon.
In Geminus's own window, a pictorial representation of the selected screen mode is provided, allowing you to easily identify the screen mode, including the resolution and orientation of the monitors that it uses.
To select a screen mode, simply click SELECT on the desired mode, or use the cursor keys if the window has the input focus. Then choose the colour depth from the pop-up menu, if required, and click on the Change button.
If you want the machine to boot into a screen mode provided by Geminus (ie. not available via the DisplayManager) then, with the current release of Geminus, you will need to manually edit the file
!Boot.Choices.Boot.Configure.Monitorto specify the screen mode that you want to use, eg.
in place of the existing WimpMode command. Note that the EX1 EY1 suffix should be used with most modern modes/monitors to ensure that windows and text are displayed with the desired aspect ratio.
The Settings pane of the GemConfig application allows you to alter a few of the more obscure features of Geminus; you shouldn't need to use this often.
Geminus can take advantage of some specialised hardware present in the IYONIX pc, specifically the DMA channels (already implemented) and the Application Accelerator Unit (may be implemented in a later version of Geminus). The use of DMA makes scrolling and dragging between screens much faster, especially on rotated screens and it should therefore be enabled unless this is found to conflict with other new IYONIX software that takes advantage of this hardware.
Geminus needs to be told the maximum size of your desktop screen memory so that it can allocate a range of memory addresses for the virtual screen that it creates. Note that no actual memory is used for the virtual screen now (earlier versions of Geminus did reserve memory for this purpose, limiting the amount of other software that could be used).
This is the total size of all the screens you are using when driven at their maximum resolution and colour depth; normally, with two screens, you should find the default setting of 16MB is more than adequate. If, however, you have more screens or they are capable of very high resolutions then you may want to increase this limit to 24MB.
If you use Geminus with rotatable screen and rotate them often then you may find that your screens are in the wrong orientation when you switch on the computer. To help you change mode without using the mouse, which can be awkward, Geminus allows you to define a 'hot key' that opens its Mode changing window. You can then use the keyboard to choose a suitable mode and press Return to enter it.
The settings pane also holds a list of applications that require special treatment by the acceleration code, if that feature is available. See here for further details.
If you use Geminus with rotatable LCD displays then you'll probably want to use Geminus in just two modes - native landscape and native portrait. A handy way of switching between these two modes is to define two 'coloured keys' in the Keyboard settings of Configure so that they issue the appropriate *WimpMode commands, as illustrated below:
Oweing to the way that Geminus splits the screen display across multiple screens, the width of each screen image is constrained to a multiple of 1KB, ie. a multiple of
In practice this constraint isn't too onerous, because in 16 million colour modes, most of the standard resolutions are available (1024 x 768, 1280 x 1024, 1536 x 1152, 2048 x 1536).
Geminus is able to accelerate the desktop by using the NVIDIA graphics card hardware more extensively than RISC OS 5 does, and by reducing the amount of data that is transferred over the PCI bus bottleneck. This is achieved by remembering sprites and window contents in the off-screen memory of the NVIDIA card being used so that they can be redrawn straight from the card's memory. This is called 'cacheing.'
The NVIDIA card currently being shipped with the IYONIX pc, or available as an extra from Spellings, has 64MB of on-board video RAM yet the screen display can only consume 12MB of that memory even with a high resolution mode such as 2048 x 1536 x 32bpp. This leaves a lot of wasted memory that Geminus can put to good use cacheing frequently-plotted sprites and window contents.
Geminus contains its own sprite plotting code which uses the extra instructions and architectural features of the XScale CPU to accelerate plotting, especially on rotated and/or colour-swapped screens.
The OS sprite plotting code makes no attempt to accomodate the architecture of the IYONIX pc, which really requires prefetching of sprite data and burst writes to the PCI bus. When developing the video output stage of the Cino DVD player it was discovered the IOP321's DMA channel is capable of performing these transfers much more rapidly than the XScale CPU and Geminus puts this hardware to good use when plotting large sprites of the same bit depth as the screen.
Since most IYONIX pc users will be using 32bpp modes, the effect of DMA-accelerated plotting will be apparent when viewing large JPEGs in !ChangeFSI, large 32bpp sprites in !Paint and all large images in !NetSurf if the image settings are 'Use OS' in NetSurf's Choices window.
NetSurf and Firefox use a module called Tinct (written by Richard Wilson) to render images in their windows. When Sprite plotting is enabled for these applications Geminus will also intercept calls to the Tinct module and use DMA to accelerate the plotting of those images, leading to a smoother display in those web browsers, particularly with large images.
Cacheing of sprites is achieved by simply rendering the whole sprite to off-screen storage using Geminus's sprite plotting code (which is therefore also capable of the necessary rotations and colour swaps) and the visible portion of the sprite is then copied to the actual screen display using a hardware operation (or two hardware operations if the sprite must be masked). Subsequent plots of the same sprite will only perform the hardware operation requiring very little CPU involvement and PCI bus traffic.
The benefits of Geminus's sprite cacheing are especially noticable when working with large textured windows such as Filer windows or sprite files holding a lot of sprites in !Paint.
By far the slowest graphical operations that you will encounter on the RISC OS desktop are applications redrawing the contents of their windows. Sometimes this is because the application code hasn't been tuned extensively. Sometimes, as in the case of ArtWorks, it is simply because the complexity of the displayed image is essentially unbounded, so no sooner does a faster machine or more highly optimised rendering code become available than an artist creates a more photorealistic or complex image.
Geminus is able to remember the contents of windows using the off-screen memory so that when you later uncover the window by closing a window that was in front of it or by dragging another window across it, Geminus can render the uncovered area immediately using the graphics hardware rather than the much slower alternative of asking the application to redraw the unchanged contents of its window.
This makes a big difference to the fluidity of the desktop when working with large or complex vector graphics in ArtWorks. A future version of Geminus may be able to accelerate the initial rendering too, and not just subsequent redraws of the same area.
Geminus can employ the NVIDIA's hardware acceleration for rendering horizontal and vertical lines (eg. window borders and DrawFile rendering) to give a speed increase over the OS rendering routines. This will give a further boost in a future version of Geminus that can overlap graphics operations with CPU activity.
Inverting a rectangular area of the screen is a very slow operation on the IYONIX pc because it requires that a large amount of data be read over the PCI bus from the NVIDIA card, inverted by the CPU and then written back. The very poor performance of this operation is apparent when selecting rows and columns in !Paint, for example.
Geminus can use the NVIDIA hardware to perform this operation literally thousands of times faster, making these selections much slicker and far more pleasant to use.
Since Geminus provides its acceleration code, and particularly the cacheing of sprites and window contents, transparently for all applications rather than as a new OS API extension, it has the potential to give problems with some applications, typically displaying images that are out of date and have not changed when the application they should.
To circumvent such problems, Geminus allows you to specify a list of applications that require special treatment, and also the ability to disable sprite plotting , sprite cacheing and redraw cacheing globally if required.
Applications can be added to the list of special cases by choosing from the pop up menu to the right of 'Add application.' This menu shows the applications that are currently running, so you must have already started the application that you wish to add to the list.
You can then alter the on/off state of each of the three main accelerations as described above and click on 'Set' to apply the changes.
The 'All' and 'Clear' buttons manipulate which of the applications are selected (you can select individual applications in the normal manner by clicking with Select or Adjust over the application names)
The demo version of the Geminus acceleration code allows you to quickly see the benefits of acceleration by Adjust-clicking on the Geminus iconbar icon to turn the accelerations on and off. When temporarily disabled in this way the Geminus icon will be crossed out thus:
This disables all of the following: sprite plotting, sprite cacheing, redraw cacheing, line drawing and inversions, JPEG decoding and plotting.
Geminus can intercept JPEG-plotting calls to the SpriteExtend module from applications such as:
It then uses its more highly optimised JPEG decoding and plotting routines to provide rendering that is up to three times faster than the SpriteExtend routines. This can improve the usability of any image viewer such as Thump when manipulating a lot of large JPEGs.
The JPEG decoding/plotting can be disabled (or re-enabled) in the Settings pane of !GemConfig in the event that it causes problems with any of the applications that you use. If you find an application that it doesn't work with, please report the problem to us.
In addition to being faster than the SpriteExtend code, it is designed to allow music playback to continue whilst decoding and rendering large JPEGs (the SpriteExtend code executes in SVC mode and thus blocks ShareFS network traffic and audio playback from disc/network whilst it is rendering). By running in USR mode it also limits the effect of any coding errors. Note that for technical reasons if Geminus's decoder does fail it will disable itself until the next mode change.
The JPEG code in the OS's SpriteExtend module provides SWIs to perform rotated and transformed plotting of JPEGs, but this functionality was never implemented. Geminus implements those SWIs and provides, for the first time, full rotation and skewing of JPEGs in applications such as !Draw, illustrated below:
Some more advanced applications such as Ovation Pro and ArtWorks 2 are already able to rotate/skew JPEGs in this way by working around the incomplete API of the SpriteExtend module, however doing so is both slower and uses more memory.
Note: Some applications, including !Draw, will check for the ability to transform/rotate JPEGs only once when they start up or first render a JPEG, so you will need to make sure that Geminus is running with its JPEG feature enabled before starting them. OpenVector, which has recently been adapted to exploit this capability of Geminus, can adapt dynamically.
With !Draw you will see a message akin to the following if the feature is unavailable:
Lastly, although Geminus will render JPEGs in modes with 256 colours or fewer, it employs only a simple algorithm and does not (yet) implement dithering or error diffusion. 16bpp and 32bpp modes are considered to be much more useful nowadays and have received correspondingly more development effort. Geminus will therefore step aside and let the OS render the image if transformation is not being requested, hence there will be no speed increase in these low-colour modes for applications that just employ scaling.
Loading of JPEGs into ChangeFSI is difficult to accelerate because the way that it works is inherently inefficient. It invokes an open source utility called 'djpeg' which converts the JPEG to a large bitmap file and saves it to disc. ChangeFSI then loads this bitmap into memory (rather slowly) before rendering.
Geminus can only hope to accelerate the JPEG decoding, via a modified djpeg utility which will be made available, but this is not the slowest stage of the above process so the speed up will not be as great as with the JPEG viewers such as !Thump and !SwiftJPEG. ChangeFSI, however, is intended for processing images rather than merely viewing them.
A number of additional features are planned for release in later versions of Geminus, all of which have already been proven as prototype code but need completing and fully testing before they can be released.
Because the nVIDIA graphics card supplied with the IYONIX pc does not support screens with fewer than 256 colours, these screen modes have to be emulated. This is only an issue for older, 26-bit software and this feature is therefore currently included in Aemulor Pro. Moving this emulation into Geminus, by combining it with the emulation required to support rotated screens, provides a considerable performance increase and it is therefore anticipated that a later version of Geminus will replace Aemulor Pro's screen emulation.
Geminus is Copyright (C) Adrian Lees 2004-6