Frame Buffer FAQ

Last Updated: 23rd November 1998
Copyright 1994-98 Sun Microsystems, Inc.

I maintain this FAQ as a public service, because if I didn't it probably wouldn't get done. If you've found it helpful, please let me know. Or better still, tell my manager Kenneth.Kadonaga@Corp.Sun.COM.

I am keen to receive any corrections, updates, suggestions, etc. I can be contacted by email as David.Tong@Corp.Sun.COM or by post at
UMTV16-218, 901 San Antonio Road Palo Alto, California 94303

I do try to maintain the accuracy of the information; your assistance is appreciated. However no responsibility is taken - either by me or by Sun Microsystems Inc. - for any inaccuracies, or for any damage that may occur as a result of applying this information.

Get informed of updates automatically

The Frame Buffer FAQ is updated frequently. By registering this URL with NetMind you will receive an email notification when the page is updated. This service is free. I have no connection with NetMind.

Note for Sun Internal users: You will have to register one of the mirror sites.

Can You Help?

If you find any useful information that isn't included here, please forward it to me. If any of the information is out of date or any of the links are broken, please tell me. I try to keep this up to date, but I need your help.

Hey! Where did the utilities go?

I moved them into the main body of the FAQ. Check out fbinfo the Frame Buffer Info script, fbconf the Frame Buffer configuration utility and the latest addition libnoflash, a library to help prevent colormap flashing on 8 bit frame buffers.

Contents

Click on the "?" logo to get back to here
Where do I get the latest copy of the FAQ? (Updated Oct 98)

So what is a frame buffer anyway?

Introduce me to Sun's frame buffers.

What's this frame buffer on the motherboard of my SS20?

What's the bottom line on 1280 x 1024 on the SX?

How do I start OpenWindows in a dual-headed configuration?

How do I set the resolution of the primary frame buffer?

How do I set the resolution of a second frame buffer?

So, given that I can control all the parameters, can I program the TGX/TGX+ with an arbitrary resolution?

How do I find what frame buffers I have available? (Updated Oct 98)

What are the restrictions on multi-headed machines?

Can I drag a window from one screen to another?

What resolutions do the various frame buffers support?

What is the default resolution for each frame buffer?

How do I change the console frame buffer?

Will 4.1.3 run on a SS20/SX, SS5/S24 or SS4/TCX?

How do I change the default depth or visual class in OpenWindows?

Why does the screen look paler or darker in 24 bit mode?

How can I display the same tool on multiple windows?

Can I replace the monitor with an LCD display?

What special purpose products are available from third parties?

Why does the Xsun server process appear to be so large?

Can I use a Sun monitor with my PC?

What frame buffers are/are not supported in the Ultra machines?

Why are 24 bit Frame Buffers so expensive compared to a PC?

How do I change the resolution on the SparcStation 4?

How can I tell whether I have the 4Mb or 8Mb SX VSIMM installed?

What is different about the "new" TGX and TGX+?

What set of resolutions do the FFB series support?

Can the FFB1 be used with the new 24" HDTV monitor?

What resolutions does the FFB2/2+ support with the new 24" HDTV monitor?

What set of visuals does the FFB support?

I'm confused by all these Creator boards. What's the story, Morning Glory?

There are two speeds of Creator 3D Series 1. Which one do I need?

Can I run two different window managers together on a dual headed machine?

How can I capture the video output from a frame buffer?

Can I drive a TV from any of the frame buffers?

Why does the console not sync correctly after using Stereo mode?

How can I write to the frame buffer directly?

What is gamma correction?

What's that little round socket for on the back of the FFB2/2+?

What's the story on PCI support?

So can I take a PCI card from my Sun and plug it in my PC (or vice-versa)?

How do the FFB2/2+ and the PGX determine their default resolutions?

Can I use a PC monitor on an Ultra 5 or Ultra 10?

What are the pinouts for the 13W3 connectors?

Useful Part Numbers

Cables and adapters

What utilities have you written that I might be interested in?

Other Useful Resources

The Sci.Electronics.Repair FAQ

The Sci.Electronics.Repair FAQ maintained by Samuel M Goldwasser at http://www.paranoia.com/~filipg/HTML/REPAIR/F_fix_freq.html has some useful information on using fixed-frequency (ie non-multisync) monitiors on PCs.

Gamma Correction

Robert W. Berger has provided an excellent page discussing Gamma Correction at http://www.vtiscan.com/~rwb/gamma.html.

Charles Poynton has also written some excellent FAQs and articles on the subjects of gamma and colour correction.

Where do I get the latest copy of the FAQ?

Getting the latest copy of the FAQ

>From within Sun, go to >From outside Sun, try these official mirror sites: Glowing letters of praise should be addressed to my manager and/or to the Webmaster at this site.

So what is a frame buffer anyway?

In its simplest meaning, and as far as the Graphics hardware engineers are concerned, a frame buffer is simply that; the video memory that holds the pixels from which the video display (frame) is refreshed.

In the early days, Sun provided seperate "Graphics Processor" or "Graphics Accelerator" and "Graphics Buffer" boards - the processor/accelerator was an add-on (sometimes optional) that provided efficient, tuned hardware pipelines to support graphics functions normally done in software, for example shading, Z-buffering, picking and hidden surface removal.

Nowadays with ever-improving manufacturing techniques, the two are tightly linked on the same board. Since every graphics device incorporates a frame buffer, but not all have graphics processors, the term "frame buffer" has become synonymous (outside Engineering at least) for a graphics device of any type.

It is perhaps better to talk about "dumb" or unaccelerated frame buffers - devices such as the cgthree, which perform no real action other than to provide a video signal to a monitor - and "smart" frame buffers, which include additional hardware and/or microcode to accelerate 2D and 3D graphics, etc. But once again, advancement in technology means that dumb frame buffers are the exception rather than the rule, and hardware acceleration is taken for granted.

So applying the rule of common usage, today's definition of a "frame buffer" is a graphics output device that provides accelerated 2D or 3D graphics, and a "dumb frame buffer" is a graphics output device that does not provide any acceleration.

As an aside, the PC world tends to refer to graphics devices as "video cards". In the workstation world, a Video card implies full-motion video, either in (as with Sun's VideoPix or SunVideo products) or out (as in Parallax's XVideo products).

Introduce me to Sun's frame buffers.

Note: This section does not deal with the older VME bus frame buffers.

bwtwo

The bwtwo was the monochrome frame buffer found in the old Sun3 machines (remember those?). It was also available as an SBus card for Sparc machines up to the SS20. The MG1 (Monochrome Graphics) was capable of driving a high resolution (1600x1280) display, and looks similar to a cgthree.

501-1419 - MG1 bwtwo with D type connector
501-1455 - MG2 bwtwo with 13W3 connector

cgthree

When this document talks about the cgthree it refers to an un-accelerated 8 bit SBus frame buffer. It is recognisable by a row of 8 SIL chips (Single In Line) which provide the Video memory and look rather like a heatsink.

The cgthree was built onto the motherboard of some entry level machines.

501-1415 - cgthree with 13W3 connector
501-1718 - cgthree with 13W3 connector. Distinguishable from 501-1415 by having 2 crystals (metal oblongs) instead of 1.

cgsix

Sometimes known as LEGO for Low End Graphics Option, the cgsix family includes the GX, GX+, TGX and TGX+ boards. These are accelerated 2D 8 bit frame buffers. They are the reference point for graphics support, and are supported in all Sparc machines, subject to some restrictions on size and revision; for example the older GX/GX+ cards are not supported in the newest Ultra hardware.

The early GX boards were double-width, as were the GX+ boards. To distinguish the two visually, the double-width GX has several rows (2x16) of SIL chips, whereas the GX+ has convential DIL chips.

The TGX and TGX+ bear a large LSI chip and 8 RAM chips, and have the names of the design team printed above the SBus connector. While there have been at least two versions of the TGX, the chip rev number has not changed. The TGX+ can be distinguished by the characters TGXA printed next to the 13W3 connector, and by having a row of 8 very low profile surface-mounted chips down one side, compared with the larger chips in an L configuration on the TGX and GX.

The TGX/TGX+ are compatible with the GX/GX+ but are faster and support more resolutions. (The T stands for Turbo). The GX/TGX have 1Mb of on-board memory, which gives them a maximum resolution of 1152x900. The GX+/TGX+ have 4Mb of memory, which is used for double-buffering and optimisation, and has a maximum supported resolution of 1600x1280. Note that unlike some PC graphics adaptors this memory CANNOT be used to give more than 8 bit colour.

The SparcStation LX has an on-board GX with a slot for a 1Mb VSIMM. This optional extra memory can be used to support higher display resolutions or for double-buffering.

For information on identifying the cgsix from software, see elsewhere or use fbinfo.

501-1481 - Double width GX: Rev 1
501-1645 - Double width GX: Rev 2
501-1672 - Single width GX: Rev 8
501-1996 - Single width GX
501-2325 - TGX - Older model. Chip sometimes printed with Sun logo and TURBO XGX.
501-2922 - TGX - Newer model. New names (mixed case).
501-2253 - TGX Plus. Older model. Same chip and names as TGX (501-2325)
501-2955 - TGX Plus. Newer model.
There is no functional difference between the older and newer versions of the TGX and TGXplus - see Question 20.

cgtwelve

The cgtwelve is also known as the GS. This is a large card that takes up 3 SBus slots, and thus can only be used in machines that have 3 slots horizontally, such as SparcStations 1, 1+ and 2. It provides 8 or 24 bit graphics, but is fairly slow. It is not supported in 2.5 or later.

GT

The Graphics Tower is a 24 bit accelerated 3D graphics system. The tower itself is a seperate box, which is connected to the Sun through a single-width SBus interface card. As a console frame buffer it is unbearably slow. It is not supported in Solaris 2.5 and beyond, or in newer Sun machines.

cgfourteen

Also known as the SX and spam, this is a very different kind of frame buffer. Built in to the motherboard on the SS20, it is also available as an add-on card for SS10 and SS20 (only one add-on card is allowed). For each display a VSIMM is required; two types are available, 4Mb or 8Mb. The 8Mb VSIMM allows a resolution of 1280x1024 at a depth of 24 bits; the 4Mb VSIMM allows up to 1280x1024 at 8 bits or 1152x900 at 24 bits. (For the reason why see below.) System memory can be reserved for use by the SX to improve performance using the command sxconfig.

It is not supported in SunOs 4.x, except as a console.

leo

Also known as the ZX or T(urbo)ZX, this is a 24 bit accelerated 3D graphics card. Both cards are double-width, but the TZX also requires extra cooling in the form of an additional double-width fan card, so effectively takes up 4 SBus slots.

tcx

These frame buffers attach to the AFX bus rather than the SBus, and are only supported in the SparcStation 4 and 5. The version for the Sparc 5 is also known as the S24 and is a 24 bit frame buffer. The version for the Sparc 4 is 8 bits only.

FFB family

The FFB was the first 24 bit frame buffer available for the Ultra machines. Several models exist; the FFB1 is available in single buffered (known as the Creator) and double buffered (known as the Creator 3D) formats; additionally the original Creator 3D is available in 66MHz and 75MHz forms. The FFB2/2+ is also available in single and double buffered configs, and also in two physical packages, depending on whether it is mounted horizontally (for SBus based systems) or vertically (for PCI based systems).

PGX family

The first PGX was based on the ATI Rage II chipset. It was built onto the motherboard of the Ultra 5 and 10, and was also available as a PCI card. Partly due to its heritage in the "Wintel" arena, the first version that was released had only 2Mb SGRAM and only supported 8 bit graphics.

The second generation Ultras 5 and 10 (code-named Darwin Plus) have a revised version of the PGX based on the ATI Rage Pro chipset. Known as the PGX24 it has 4Mb of SGRAM memory and supports both seperate and composite sync formats. When in seperate sync mode they drive the VESA standard resolutions from 640x480 to 1280x1024.

The card supports both 8 and 24 bit visuals, but due to the architecture of the chipset the card it cannot support both simultaneously. Thus any legacy applications that require an 8-bit color visual will be required to run in the 8-bit mode (disabling 24-bit visuals). Such applications need to be updated to take advantage of 24 bit visuals; users should contact the software vendor and request a patch.

AFB family

The AFB or Elite 3D series is the current high-end 3D graphics card. It supports all the features of the Creator 3D and adds such features as hardware-accelerated lighting.

What's this frame buffer on the motherboard of my SS20?

The on-board frame buffer is called the SX. It's a 24 bit frame buffer, but in order to use it you need to order the SS20/SX or purchase some video memory. For details see the section on the cgfourteen, above.

The advantages of SX over TGX?
The SX can have more video memory - up to 8Mb, compared to 1Mb on the TGX or 4Mb on the TGX+.
It can display 24 bit TrueColor
The on-board frame buffer does not take up an SBus slot.

The advantages of TGX over SX?
The TGX is supported under 4.x, the SX is not.
Each SX takes up a SIMM slot, which reduces the maximum amount of system memory possible, but unless you really need to max out your RAM (and if you do, you should think about upgrading) this isn't a problem.
The TGX has fractionally better performance on some 2D operations, but by and large there's not much in it. Unless the system is running 4.x I'd choose the SX. Or, better still, dual headed with the SX *and* a TGX+.

What's the bottom line on 1280 x 1024 on the SX?

1280x1024x76

As detailed elsewhere in this document, the SX does support 1280x1024@76 resolution, but it's tricky to get. This is due to a restriction in the SX's prom. Under 2.3 you had to set the resolution in the EEPROM using the command: You could not use cg14config as the version supplied with 2.3 did not allow this resolution.

This was supposed to be fixed in 2.4 - early versions allowed both 1280x1024x76 and 1280x1024x76m, but only 1280x1024x76m actually works. Unfortunately, this was broken at some stage, and not spotted until later in the beta phase. Bug ID 1164703 was logged, but at a low priority (4), so it was not fixed in time for FCS. This was fixed for 2.5 - see Bug ID 1187375. For earlier releases you must set the resolution in the EEPROM.

24 bits at 1280x1024

Elementary mathematics says that a resolution of 1280 x 1024 and a depth of 24 bits per pixel takes 3.75 Mb. So why is it necessary to get the 8M VSIMM to support this depth?

Well, the main problem is that we need to provide 8 bit and 24 bit windows side by side. The most reasonable way of doing this is to have control plane(s) that identify a pixel as being 8 or 24 bits. This means you need at least 25 bits per pixel. Now 1280 x 1024 x 25 is exactly 4Mb, which leaves no space at all for any other overhead, such as lookup tables.

How do I start OpenWindows in a dual-headed configuration?

You will need a machine that has two frame buffers correctly installed, together with matching monitors. The frame buffers do not need to be identical; there are several advantages in having each screen running on entirely different frame buffers.

The component that controls the screen is the X server, Xsun. This is started automatically when you invoke openwin. Openwin will pass flags and options down to Xsun to tell it how to configure the displays. The flags needed are detailed in the Xsun manual page.

Take as an example a machine which has two GX's installed. Looking in /dev you should see the following:

To start up a multi headed configuration you must specify each device you wish to use using the option -dev, thus: 
    openwin -dev /dev/fb0 -dev/dev/fb1
The order that you give them is important for two reasons; display zero machinename:0.0 comes first, then display one machinename:0.1 and so on. By default they are ordered left to right; to change the order you can use the keywords left, right, top or bottom. Thus the commands: 
    openwin -dev /dev/fb0 -dev/dev/fb1 left
    openwin -dev /dev/fb1 -dev/dev/fb0
will start up OpenWindows with fb1 on the left and fb0 on the right, but in the first instance fb0 will be logical screen 0, and in the second it will be screen 1.

The keyword tells the server where to position the current display relative to the previous one, so any keyword placed after the first device is ignored. If no keyword is given, the default is right. Thus the command: 

    openwin -dev /dev/fb0 top -dev/dev/fb1
will not have the desired effect; you would need to use: 
    openwin -dev /dev/fb0 -dev/dev/fb1 bottom
Other keywords can be used after the device name to control such things as default depth or visual; these are discussed in the manual page and elsewhere in this document.

How do I set the resolution of the primary frame buffer?

First, verify that the resolution is supported - see Question 5.
The resolution is specified as rHORIZxVERTxFREQ - the r and x characters are significant.

To set the resolution, run the following command as root:

then reboot. Alternatively, halt the machine and type Some frame buffers have their own configuration programs; for the ZX you should use leoconfig: while for the SX you should use cg14config:

How do I set the resolution of a second frame buffer?

For the SX use the command You should NOT reboot, as this will reset the resolution. To ensure that the resolution is set each time, place the command somewhere that it will be run each time you reboot (/etc/init.d) or start OpenWindows ($HOME/.xinitrc). Be aware that the resolutions supported by cg14config differ between Solaris 2.3 and 2.4. For further details, see the SX section in Question 5.

Note to Solaris 2.3 users: Because of Bug 1119523 you need a patched version of both the cgfourteen driver and the cg14config program. The driver is available as part of patch 101318 (the kernel jumbo patch) but at the time of writing the modified cg14config doesn't seem to be available as part of any patch. The bug is fixed in Solaris 2.4

I have copies of the binaries available. Note that this is NOT AN OFFICIAL PATCH! To download, select the Load to local disk option, then click here for cg14config, cgfourteen and a script written by Antoine Garric to automatically set the resolution at boot time.

For other frame buffers, it is a little trickier. You have to set the resolution at boot time in the nvramrc. Here is a script that will set up the nvramrc so that it initialises the resolution to 1280x1024 @ 76Hz.

Note: This script is modified from one in Sun document No: 802-5011-10 Platform Notes: SMCC Frame Buffers, available in the Answerbook volume Solaris 2.5 on Sun Hardware - search for the string "TurboGXplus Frame Buffer". To download a PostScript copy of the document (1.75M) click here.

The script presumes sun4m architecture; for sun4c change /iommu/sbus to /sbus
The other information you will need to run the script is which sbus slot the second frame buffer card resides in - ie the one that will be used as the second head. In this instance, it assumes a cgsix frame buffer in sbus slot 3.

The script has the disadvantage that it makes the second TGX+ the console frame buffer. You may not want this; for example if you have a SS20/SX or Ultra Creator with an additional TGX+, you may wish to set the resolution of the TGX+ while maintaining the SX or FFB as the console.

In which case, try this script instead. It should set the resolution of the TGX+ to 1280x1024@76 while maintaining the default console.

Note that the number 4 in vsetup 4 refers to the sense code of the monitor. For an incomplete list of sense codes, see below.

Here is the appropriate voodoo for several supported resolutions. Note also that this will only work for the TGX or TGX+.

And this is what the numbers actually mean, taking 1280x1024@67 as an example:

So, given that I can control all the parameters, can I program the TGX/TGX+ with an arbitrary resolution?

Kinda-sorta. The pixel clock is not a freely configurable parameter - you can only use certain predefined values. I believe that the list given above is comprehensive, but cannot guarantee this. Given that limitation it is possible to program custom resolutions. For example, here are some suggested values for 1280x1024 @60Hz. (NB: To the best of my knowledge this has not been tested or authorised by anyone at Sun.) 
108.0   # pixel clock in MHz
48      # horiz front porch in pixels
112     # horiz sync width in pixels
248     # horiz back porch in pixels
1280    # horizontal visible in pixels
1576    # horiz sync width during vertical sync in pixels
1       # vertical front porch in lines
3       # vertical sync in lines
38      # vertical back porch in lines
1024    # vertical visible in lines
At the risk of starting to sound like a physics textbook, the Horizontal time is the time taken to draw one row of pixels - ie the number of pixels drawn divided by the pixel clock. The Horizontal frequency is the inverse of the horizontal time. So for this example, 
Horiz freq = 1/(Horiz Time)
           = (Pixel Clock) / (Horizontal pixel count)
           = (Pixel Clock) / (Pixels + both porches + sync width)
           = 108.0MHz / (1280 + 48 + 112 + 248)
           = 63.98KHz

How do I find what frame buffers I have available?

You can usually find out what frame buffers are available by looking in the directory /dev/fbs, or examining the output from dmesg. Most frame buffers announce themselves as cgnumber0, eg cgthree0, cgsix0, cgtwelve0. A digit other than zero indicates that either a second frame buffer is present or it has been moved from its original sbus slot.

cgthree Boring old unaccelerated cgthree. May also be a symlink to a more sophisticated device that is masquerading as a cgthree for backward compatibility.
cgsix GX family. See below.
cgtwelve GS. Older 24 bit frame buffer
cgfourteen SX. Newer, on-board 24 bit frame buffer
There are others, such as the cgeight, but they are by and large obsolete.

The exceptions to this rule are:
bwtwo the old monochrome buffer. Found in Sun3s, SLC, ELC, IPC and also available as an SBus card.
leo the ZX or Turbo ZX 24 bit accelerated 3D graphics card. It's not possible to tell the ZX and Turbo ZX apart from software.
gt and gt0 the GT - Graphics Tower. Very old, slow 3D graphics pipeline.
tcx Can refer to the S24 24 bit frame buffer which runs on a SS5 or the 8 bit frame buffer on a SS4.

Another option is to use fbinfo, the Frame Buffer Info script. This uses the prtconf program to interrogate the system configuration. It displays information about all the frame buffers that the system knows about.

A third option is to interrogate the frame buffer using IOCTL calls.
WARNING! This is not recommended for several reasons:

If you still want to go ahead, the approved method is to call VIS_GETIDENTIFIER to identify framebuffer. If VIS_GETIDENTIFIER fails you have an older framebuffer. Call FBIOGATTR or FBIOGTYPE and use the type field to identify the framebuffer using the #defines in fbio.h. Here is a sample program. Use at your own risk.

How do I work out if I have a GX, GX+, TGX or TGX+?

Run the following command: You should see messages similar to this: If the rev number of the board is 11 or more then the board is a TGX/TGX+
If the rev number is 9 or less, then it is a GX/GX+
If you see the text single buffered, 1M mappable then it is a GX/TGX
if you see double buffered, 4M mappable then it is a GX+/TGX+

Thus, in the example above, cgsix0 is a TGX, while cgsix1 is a GX+

Note: On a SPARCstation LX with the optional VSIMM, one will actually see 2M mappable. This is equivalent to a TGX+.

What are the restrictions on multi-headed machines?

As far as software restrictions go, until OpenWindows V3.2 (Solaris 2.2) you were limited to a maximum of 4 heads by the xnews server. For 3.2 this limit was raised to 16, so now you are effectively limited by how many frame buffers the machine can physically support. This is particularly true in the case of the PCI bus; there should be no reason why you cannot fill every PCI slot (except any PCI66 slots) with PGX or 3rd party PCI frame buffers.

I've recently heard from Rich Pedano who has configured a system using a SparcStation 20 with six TGX+ boards. This was accomplished using an SBus expansion unit. He was even able to get 8 heads running successfully. He reported that the system worked fine with all heads configured at 1152x900, but not at 1280x1024. The system used XbigX to manage the screen as a single unit.

(For SUN internal users, Rich has published some information on his web page.)

The latest news (Feb 98) is that SMCC are planning to support up to 8 (eight) Elite 3D (AFB) frame buffers in the Ex000 series.

SparcStation 5

The SS5 will support 3 heads - (2 SBus cards + 1 Afx or 3 SBus cards)
You cannot have more than 1 S24 card in an SS5 system because the S24 card requires an AFX bus and the SS5 only has one AFX bus connector.

SparcStation 10

The SS10 can have 4 heads - (4 SBus cards)

SparcStation 20

Document 801-6186-10 states that "Due to configuration restraints, a limit of two TGX or TGXplus SBus cards are permitted in a SPARCstation 20". Additionally, the document states that double-width GX cards (which implies, but may not necessarily include the GX+) are not supported.

According to Ken Won the limitation is due to "capacitance loading issues". Some (un-named) SBus cards have a high capacitance rating, which - in conjunction with 3 TGX/TGX+ cards - can overload the bus. 4 TGX/TGX+ cards should not cause a problem, but if 3 are used the 4th slot should be left vacant.

As far as I am aware there are no other limits on the number of heads that are supported beyond the number of SBus slots. Thus supported 5 headed configurations are obtained by using additional SX and GX frame buffers (up to 2 TGX/TGX+ with up to 2 SX and up to 4 GX) For the SX, the first SX head simply requires a 4Mb or 8Mb VSIMM. The second SX head requires a VSIMM and an auxiliary video board, 501-2488 that takes the place of one SBus card.

Ultra 1 and 2

The Ultra 1 can have up to 3 heads. The Ultra 2 can have up to 5. This has been tested and is fully supported. The Elite 3D M6 is supported only in the Ultra 2.

Ultra 5

The Ultra 5 can support up to 4 heads - 3 PCI cards and the on-board PGX. For a 24 bit display you currently need a 3rd party graphics card, such as the Raptor GFX.

Ultra 5 and 10

The Ultra 10 can support up to 6 heads - 4 PCI cards, one FFB and the on-board PGX.

TechSource contacted me to confirm that they support multi-headed configurations on the Ultra 5 and 10 using their Raptor GFX cards.

Ultra 30 and 60

Up to 2 FFBs plus up to 3 PGXs (8-bit PCI graphics cards) are supported. You could add a 4th PCI graphics card if the card is a 3 volt ('universal') PCI card type. Although Sun do not currently provide such a card, one may be available from third parties.

Ultra 150

I believe that only one TGX is supported, but it has 3 SBus slots, and can therefore theoretically take up to 3 heads.

Ultra 450

In the server configuration, only one PGX is supported. However in the workstation configuration there is no limit to the number of PGX cards that you can install. Only the Elite 3D m6 is supported in the Ultra 450 - you can have up to two of them. The FFB series is NOT supported.

High End Servers

The latest news (Feb 98) is that SMCC are planning to support up to 8 (eight) Elite 3D (AFB) frame buffers in the Ex000 series.

Up to 4 Frame Buffers are supported in a SS1000 or Ex000. Only one Frame Buffer is supported in the SS2000. The Starfire E10K doesn't support any - it's all done via the SSP.

These configurations have been tested and are supported by Sun. It would be possible to create configurations with more frame buffers and there is no obvious reason why these configurations would not work. In fact, given the success reported with the SBus expander box (above) I would be very surprised indeed if it did not work. I would be grateful for any feedback from customers who have tried this.

ZX and Turbo ZX

The ZX series cards impose their own set of restrictions on a machine. Because of the amount of power the ZX consumes, and consequently the heat that it produces, you can only have one ZX in a machine, which takes up two slots, though the remaining slots may be available for use by other SBUS cards, depending on cooling and power factors. The ZX is not supported in the SBus expansion unit.

The Turbo ZX card uses more power and produces even more heat than the ZX. As a result, two fan cards are needed. This takes up a total of 4 slots. Additionally, on a Sparc 20, the side vents must be replaced to improve the cooling. This is detailed in the TurboZX Graphics Accelerator installation manual, part number 801-7829-10.

Can I drag a window from one screen to another?

Not under OpenWindows or CDE. You can copy and paste across heads, or drag and drop text, but you can't move windows. Each display is handled individually.

A third-party product called X/bigX is available from X/software. It combines multiple screens to form a larger display area.

There is also a free product called Xmove, which lets you move windows from one display to another, but not drag them. Xmove is available from ftp://ftp.cs.columbia.edu/.

What resolutions do the various frame buffers support?

PGX

The PGX is the first of the new generation PCI frame buffers - for details on PCI see below.

It supports a very wide range of resolutions and can only be configured using the utility m64config, not using the boot NVRAM. Obviously having this software-configurable in this way means that support for resolutions can be added (or removed) very easily. At the last count, m64config reported the following supported resolutions: 

 640 x  480 @ 60   640 x  480 @ 67   640 x  480 @ 72   640 x  480 @ 75      
 720 x  400 @ 70   720 x  400 @ 88      
 800 x  600 @ 56   800 x  600 @ 60   800 x  600 @ 72   800 x  600 @ 75      
 832 x  624 @ 75      
1024 x  768 @ 87  1024 x  768 @ 60  1024 x  768 @ 70  1024 x  768 @ 75     
1152 x  870 @ 75     
1152 x  900 @ 66  1152 x  900 @ 76     
1280 x  800 @ 76     
1280 x 1024 @ 60  1280 x 1024 @ 67  1280 x 1024 @ 75  1280 x 1024 @ 76
1440 x  900 @ 76     
1600 x 1280 @ 76    
1600 x 1000 @ 66  1600 x 1000 @ 76    
1920 x 1080 @ 72  
1920 x 1200 @ 70    

Stereo:            960 x  680 @112   960 x  680 @108    
Interlaced:        640 x  480 @ 60   
				   768 x  575 @ 50
NB: the PGX only has 2Mb of on-board memory, so 1920 x 1200 is obviously unattainable.

PGX24

The newer Ultras 5 and 10 (code-named Darwin Plus) have a revised version of the PGX based on the ATI Rage Pro chipset. Known as the PGX24 it has 4Mb of SGRAM memory and support BOTH seperate and composite sync formats. When in seperate sync mode they drive the VESA standard resolutions from 640x480 to 1280x1024. The following chart shows the resolutions and available colour depths. Note that when in 24 bit mode the PGX24 only provides a 24 bit visual, so applications that *require* an 8 bit PseudoColor visual will not work. 

Resolution       Sync format      Color Depth
-----------      -----------      ----------
640x480x60       separate         8 or 24
800x600x75       separate         8 or 24
1024x768x60      separate         8 or 24
1024x768x70      separate         8 or 24
1024x768x75      separate         8 or 24
1024x768x77      composite        8 or 24
1024x800x84      composite        8 or 24
1152x900x66      composite        8 or 24
1152x900x76      composite        8 or 24
1280x800x76      composite        8
1280x1024x60     separate         8
1280x1024x67     composite        8
1280x1024x76     composite        8
1280x1024x75     separate         8
1280x1024x85     separate         8
The following resolution values are all taken from the Field Engineer's Handbook, except where stated otherwise.

These are supported resolutions. For ways to customise other resolutions see the note in Question 2.

Turbo GX

1024 x  768 @ 60	1024 x  768 @ 70	1024 x  768 @ 76
1024 x  800 @ 74	1024 x  800 @ 85
1152 x  900 @ 66	1152 x  900 @ 76

Turbo GXplus

1024 x  768 @ 60	1024 x  768 @ 70	1024 x  768 @ 76
1024 x  800 @ 74	1024 x  800 @ 85
1152 x  900 @ 66	1152 x  900 @ 76
1280 x 1024 @ 67	1280 x 1024 @ 76
1600 x 1280 @ 76

CG3

1024 x  768 @ 77
1152 x  900 @ 66	1152 x  900 @ 76
The first boards (501-1415, 501-8044) only support 1152x900@66. Later boards (501-1718, 501-1909) support 1152x900@76 as well. On these boards, 76Hz is the default.

Furthermore there is another CG3 board, 501-2691 which only supports 1024x768 @ 77Hz - it does not support 1152x900. This board is only supported in the SparcStation 5.

The on-board frame buffer in the SparcClassic is also a CG3. It supports all the resolutions listed above. 



GX
1022 x 1000 @ 76			IPX only
1024 x  800 @ 85			IPX only
1024 x  768 @ 77			LX only
1152 x  900 @ 66  1152 x  900 @ 76
1280 x 1024 @ 67  1280 x 1024 @ 76	LX with 1Mb VSIMM only
1600 x 1280 @ 76			LX with 1Mb VSIMM only

Double width boards (501-1481, 501-1645) only support 1152x900@66. The 
single-slot boards (501-1672, 501-1996) support 1152x900@76 as well. On these 
boards, 76Hz is the default.

The on-board frame buffers in the IPX and LX are also GX. Each supports 
additional resolutions, as noted above.



GXplus
1024 x  800 @ 85
1152 x  900 @ 66	1152 x  900 @ 76
1280 x 1024 @ 67 Default

1600 x 1280 is not a supported resolution (but may work). 



GS (CG12)
1152 x  900 @ 76



GT
1280 x  1024 @ 67	1280 x  1024 @ 76 Default



ZX (Leo)
 640 x  480 @ 60
 770 x  575 @ 50
 960 x  680 @108	 960 x  680 @112
1024 x  768 @ 60	1024 x  768 @ 76
1152 x  900 @ 66	1152 x  900 @ 76
1280 x 1024 @ 67	1280 x 1024 @ 76



TCX
The default resolution for the TCX is 1152x900 unless you are using 
the 17" 
entry level monitor, which defaults to 1024x768. By adding an optional 1Mb 
VSIMM to the slot on the motherboard this can be increased to 1280x1024.

The supported resolutions for the SS4 are: 
1024 x  768 @ 66  1024 x  768 @ 76
1152 x  900 @ 66  1152 x  900 @ 76
1280 x 1024 @ 66  1280 x 1024 @ 76

For a SPARCStation 4, the commands used to set the resolution are slightly 
different since they address each resolution by the dot clock instead of the 
refresh rate. 
For 1152x 900@66 use 1152x900x94
For 1152x 900@76 use 1152x900x108
For 1280x1024@66 use 1280x1024x117
For 1280x1024@76 use 1280x1024x135



S24
The FE Handbook simply quotes a maximum resolution of 1152x900. No 
frequency is given. See also Question 
6.



SX (CG14)


There is an element of confusion as to what resolutions the SX is capable of. 
The cg14config manual page for Solaris 2.3 agrees with the FE Handbook, whereas 
the cg14config manual page for Solaris 2.4 differs. See 
note.

1024 x  768 @ 60	1024 x  768 @ 66	1024 x  768 @ 70
1024 x  800 @ 84
1152 x  900 @ 66	1152 x  900 @ 76
1280 x 1024 @ 66	1280 x 1024 @ 76
1600 x 1280 @ 66
1920 x 1080 @ 72

(1) Cgfourteen will support 1280x1024@76 but the tricky 
part is in telling it how to do it. You have to set the resolution with the 
command

# /usr/sbin/eeprom output-device=screen:r1280x1024x76m 

ok setenv output-device=screen:r1280x1024x76m 

and reboot. Note the m after the 76 - this is significant, and 
allegedly stands for mutant(!)

(2) 1024x768, 1024x800, 1600x1280 and 1920x1080 are 
available but are unsupported. There is conflicting documentation on the 
subject. Although some of these are listed in the FE Handbook as supported there 
are a number of documents which state that they are not. One customer has 
reported that he was running an 8Mb SX clone at 1600x1280@66HZ on a Hitachi 
Accuvue UX6821, and in 24 bit mode he noticed pixels "flickering" or 
"shimmering" when using some of the CDE backgrounds or viewing certain images.

(3) The cg14config man page under Solaris 2.4 reflects 
what values are supported in the cgfourteen driver. However it's still up to the 
prom to recognize them because the driver simply takes user's request and passes 
it to the prom to change the prom variable 'output-device'. Under 2.4 
1024x800@84 was taken out and 1920x1080@72 added, for reasons unknown. Any 
information would be appreciated.



Voyager
The monochrome display has a resolution of 1152x900 and is 
manufactured by Hosiden Electronics. 

The colour display has a resolution of 1024x768 and is manufactured by Sharp.



 What is the 
default resolution for each frame buffer?
The default resolution depends 
on the attached monitor. Dave Kehlet has supplied the following 
table which shows the resolution that will be selected for each detected sense 
code.

NB: See below for how the FFB2/2+ and 
PGX determine their default resolution. 

FRAMEBUFFER DEFAULT RESOLUTIONS BY SENSE CODE
December 6th 1994, David 
C. Kehlet

Code	TGXplus(1)	TGX(2)		GXplus		GX (LSC chip)
-------------------------------------------------------------------
7 	1152x900x66 	1152x900x66 	1152x900x66 	1152x900x66 	
6	1152x900x76	1152x900x76	1152x900x76	1152x900x76	
5	1024x768x60	1024x768x60	1152x900x66	1152x900x66
4	1152x900x76	1152x900x76	1280x1024x67	1152x900x76	
3	1152x900x66	1152x900x66	1152x900x66	1152x900x66	
2	1280x1024x76	1152x900x66     mutant(3)	mutant(3)
1	1600x1280x76	1152x900x66     mutant(4)	mutant(4)
0	1024x768x77	1024x768x77	1152x900x66	1152x900x66

(1) SSLX with the extra VRAM SIMM is the same as the TGXplus.

(2) SSLX is the same as the TGX. SS Voyager is the same as the TGX, 
except that code 7 is used to tell the system to use the internal LCD display.

(3) Sync timing matches 1280x1024x76, actual pixels displayed are 
less. Use is not recommended.

(4) Sync timing matches 1600x1280x76, actual pixels displayed are 
less. Use is not recommended.

Code	SX		ZX		S24		
------------------------------------------------------
7	1152x900x66	1152x900x66	1152x900x66	
6	1152x900x76	1152x900x76	1152x900x76
5	1024x768x60	1152x900x66	1024x768x70
4	1152x900x76	1280x1024x67	1152x900x76
3	1152x900x66	1152x900x66	1152x900x66
2	1280x1024x76(5)	1280x1024x76	1152x900x76
1	1600x1280x76(5)	1152x900x66	1152x900x66
0	1024x768x60	1024x768x76	1152x900x66

(5) The 4Mbyte VSIMM drops to 8 bits per pixel in these modes.

(13w3 
pin 7). 
Code	Creator	and Creator3D
-----------------------------
7	1152x900x66
6	1152x900x76
5	1024x768x60
4	1280x1024 (6)
3	1152x900x66
2	1280x1024x76
1	1152x900x66
0	1024x768x77

(6) Early models of the Creator and Creator3D examined a 4th sense 
bit - 13w3 pin 7. If this bit was 1 (unconnected) then the resolution was set to 
1280x1024x67. If the bit was 0 then the resolution was set to 
1280x1024x76.



 How do I change 
the console frame buffer?
The console is chosen from the set of devices 
whose device-type is "display". The first such device encountered during 
OpenBoot probing is chosen. SBus devices are probed in the order specified by 
the OpenBoot configuration parameter sbus-probe-list, and the 
conventional way to select one device over another as the console is to: 
However neither of these will work to choose an SBus device as the 
console device in an SX-equipped system because the MBus-based SX is probed 
before any SBus slots.

A solution is to explicitly specify the console device in NVRAM. You can 
leave the SX VSIMM in place and still select your device to be the system 
console by making a few definitions in NVRAM: 

Assume, for example, that there is a ZX in SBus slot 
2 of a sun4m machine. First get into the OpenBoot monitor (L1-A), and 
	ok  show-sbus

Look at the list of devices and make sure you really have a ZX (leo) in 
SBus Slot 2. This is not really needed if you know what you have already. 
 
	ok  nvalias  zx-screen  /iommu/sbus/SUNW,leo@2,0
	ok  setenv  output-device  zx-screen
	ok  reset

After the reset, the console output will go the ZX in SBus slot 2. In this 
scenario, The nvalias OpenBoot command creates the devalias (for zx-screen in 
this case) and sets use-nvramrc? to true. The setenv command changes the console 
output device from the default "screen" to the explicitly-specified "zx-screen".

If you want to delete the devalias zx-screen and revert to the default 
console just type: 
	ok  nvunalias zx-screen
	ok  set-default output-device



 Will 4.1.3 run 
on a SS20/SX or SS4/TCX?


SS20/SX
NO. The SX frame buffer is only supported under Solaris 
2.3 or greater. There is no support for it in SunOs 4.x/Solaris 1.1.1
You can 
install 4.x on a 20SX, using the head as a console only, but you will not be 
able to start OpenWindows unless you add another frame buffer and use that 
instead (see earlier questions for details of how to do this).



SS4/TCX
Yes, but you don't want to. The TCX frame buffer will appear to 
the system to be an unaccelerated frame buffer, similar to a cgthree. To get the 
benefit of the accelerated graphics you wil need to run Solaris 2.4 or later.



SS5/S24
Yes, but you really don't want to. As with the 
SS4, the S24 frame buffer will appear to the system to be an unaccelerated 
cgthree. That means no accelerated graphics plus no 24 bit visuals.

Theoretically you might be able to get it to behave as a cg8 instead of a 
cgthree, which would provide 24 bit visuals, but this has never been tested and 
obviously is unsupportable.

There is a known bug in the cg3 emulation. Apparently a real cg3 also 
emulates a cg4 for the benefit of old statically-linked software. Although the 
TCX and S24 emulate a cg3, they do not emulate a cg3 emulating a cg4.

The standard MIT X11R5 and R6 do not have support for the TCX or S24 frame 
buffers. As a workaround, I am told that you can create a symbolic link from 
/dev/cgthree0 to /dev/tcx0 but this is of course unsupported. Note that Solaris 
2.6 is based on X11R6, and does have support.



 How do I change 
the default depth or visual class in OpenWindows?
In the past, 
OpenWindows would always use 8 bit PseudoColor as the default visual, even when 
a 24 bit frame buffer is being used. However this rule is now changing. Starting 
with the S24, OpenWindows will default to 24 bit TrueColor. This rule is 
expected to continue as new graphics products are developed, however 8 bit 
PseudoColor will remain the default visual for the existing 24 bit frame 
buffers, such as the SX, ZX, GT and GS.

A 24-bit TrueColor default reduces colormap flashing. DeskSet and other 
applications that are really visual-independent then don't take up entries in 
the colormap. Thus those applications that do care have more available.

It is expected that most applications will be able to use 24-bit TrueColor. 
Fewer and fewer people should have to play colormap tricks such as 4/4 double 
buffering or wierd plane masking as screen update rates go up. Also, the data 
copy advantage of 8-bit pixels is going away with SX, S24 and future Frame 
Buffers.

You can alter the default depth or class by using the defdepth 
or defclass options to the server, thus: 
	openwin -dev /dev/fb0 defdepth 24
	openwin -dev /dev/fb0 defclass TrueColor

Acceptable depths are 8 or 24; you cannot set a depth of 1. The nearest 
you can get to simulating a monochrome display is to select a greyscale visual 
(see below) and specifying the -2d flag to olwm.

Acceptable classes are: GrayScale StaticGray PseudoColor StaticColor 
DirectColor and TrueColor.

NB: 24 bit DirectColor visual is only supported on the S24 or ZX, and 
only under OpenWindows 3.4
There is a bug logged, reference number 1168007 
which highlights colormap problems when this visual is used. In brief, areas 
that should be white appear black, notably the background of shelltool and 
cmdtool windows. As a workaround, use the option -whitepixel 1 
thus: 
	openwin -dev /dev/leo0 defclass TrueColor defdepth 24 -whitepixel 1



 Why does the 
screen look paler or darker in 24 bit mode?
If the screen appears pale 
and washed out, or too dark, you may wish to alter the gamma 
correction level. For the SX the default is 2.2; for the ZX it is 2.22 Use 
the -g option to cg14config or leoconfig to find level 
that is acceptable for your monitor. Increasing the value will make the screen 
lighter; decreasing it will make it darker.



 How can I 
display the same tool on multiple windows?
There are two options: the 
hardware solution and the software solution.

The hardware solution involves taking the signal from the frame buffer, 
amplifying it, then splitting it and sending it to multiple monitors. 
Amplification is necessary since the signal from the frame buffer is only 
designed to drive one monitor.

At least two software solutions are available: ShowMe, available from Sun, 
and XMX, a Public Domain product available from Brown University. These tools 
work by interposing a handler between the X client and server, and sending 
copies of the information to other remote screens.

Information on ShowMe is readily available from Sun.

XMX is available by FTP from a number of sites; use `Archie' to find the most 
convenient site, or try Brown University directly: 
	wilma.cs.brown.edu:/pub:xmx.tar.Z

Note that this information may be out of date.

A ReadMe for 
XMX V1.0 is available.



 Can I replace 
the monitor with an LCD display?
LCD panels are a lot like CRTs, but 
have stricter timing. They usually require a digital interface; the analog 
outputs from Sun's frame buffers probably won't work.

In addition, many LCD displays are designed to be driven by PC frame buffers 
which use very different timings, and therefore cannot be used with any of SUN's 
products.

Both PC format and Digital frame buffers are available from third party 
vendors.

Note: Since this analysis was originally written, companies such as RDI and 
PixelVision 
have announced flat screens which can be driven by Sun's frame buffers.

See Question 
13 for information on graphics products available from third parties.



 What special 
purpose products are available from third parties? 


NB: This is not an exhaustive list, and no recommendation is implied or 
should be inferred by the presence or absence of any vendor.


Quantum 3D (formerly Southland Media 
Systems)
1200 Crossman Ave., Suite 200, Sunnyvale, California 
94089
Phone: 408 747-1020
Fax: 408 747-1510
Quantum 3D produce the MGX, family of 24 bit PCI and SBus 
frame buffers.



Integrix
1200 Lawrence Drive, Suite 
150 Newbury Park, California 91230
Phone: 800 300-8288
Email: sales@integrix.com

Integrix sell various SBus 
cards including the S20 series that will display at 640x480 at 60 or 72Hz. 
They have a flat panel display which 
can be connected to a SPARC20. They also sell digital frame buffers which will 
drive Sharp and NEC flat panel displays.



VisiCom
10052 Mesa Ridge Ct., San 
Diego, CA 94947
Tel: (619) 457-2111
Fax: (619) 457-7080
email: sales@visicom.com or support@visicom.com

In Europe: Worting House, Basingstoke, Hants, RG23 8PY UK
Tel: +44 1256 
330030
Fax: +44 1256 816978
Vigra and RasterFlex are both now owned by 
VisiCom. The RasterFlex and Vigra product line names have been retained. The 
RasterOps product was not acquired by VisiCom and is no longer available.



PixelVision
43 Nagog Park, 
Acton, MA 01720
Phone: 508-264-9443 X7211
Email: pvision@ultranet.com, jallen@pvision.com

PixelVision produce LCD displays capable of up to 1280x1024 @ 76Hz, that can 
be driven from Sun's frame buffers.



RDI Computer Corp
Little Haining, 
Brockenhurst Rd., Ascot, Berks, SL5 9HB, UK
Phone: 01344-25999
2300 
Faraday Avenue, Carlsbad, CA 92008
Phone: 619 929 0992

RDI produce a 12" 1024x768 LCD monitor which can be driven by Sun's frame 
buffers.



Tech Source Inc.
442 S. North 
Lake Blvd., Altamonte Springs, FL 32701 U.S.A.
Phone: 407 262-7100
FAX: 
407 339-2554
Email: mailto:%20sales@techsource.com

TechSource manufacture a number of Sparc compatible graphics cards.
The 
Raptor GFX range are SunReady 8 or 24 
bit PCI cards for the Ultra range, with resolutions up to 1920x1200.
The 
STARS 2K range are PCI cards that provide 2048 x 2048 resolution (check http://www.sun.com/pci/pci.cards.ihv.html#cat20 
for the latest information on whether this product has been verified by 
Sun)
The GXTRA range are 8 bit SBus cards providing 2D acceleration and 8 bit 
overlays.



ViewSonic
Phone: 909 
869-7976
Email: mis@viewsonic.com

ViewSonic say they have tested some of their monitors, model numbers 21PS, 
17PS and 20G with the TGX+ at 1600x1280 resolution. They believe that models 
PT810 and PT770 should also work. A SW1152 adaptor is needed, costing $15. 



Ultra Spec Cables
170 Oberlin 
Avenue North, Lakewood, New Jersey 08701-4548
Phone: 1 800 622 2537 (1 800 6 
CABLES)
Fax: 1 800 222 5337 (1 800 CABLEES) Email: sales@ultraspec.com

Ultra Spec manufacture a range of cables, including monitor cables and PC to 
13W3 adaptors.



Photon


Mirage


Software Integrators Inc.
51 
Evergreen Drive, Suite A, Bozeman, MT 59715
Phone: 800-547-2349, 406-586-8866

Photon, Mirage and Software Integrators all manufacturers graphics cards 
which allow Sun and other fixed-frequency workstation monitors to run on a PC.



Parallax
Parallax provide high 
quality full motion, full resolution, 24 bit video cards.



Extron
Extron provide a range of 
scan converters and trans converters, allowing you to take the output from a 
frame buffer and feed it into a TV or VCR, or VGA/SVGA device.



StereoGraphics
StereoGraphics sell 
Stereo (3D) viewing equipment for use with the FFB (1 & 2) and ZX. The 
system comes in 3 pieces: glasses, an IR emitter box, and a cable to hook up to 
the frame buffer.

For the FFB2/2+ the cable+emitter is StereoGraphics part number ESUN. For 
just the cable to hook FFB2/2+ to your existing emitter this is StereoGraphics 
part number 69967. The glasses are part number CE2.

Incidentally, StereoGraphics made prototypes of lower cost glasses that have 
a wire that connects to the framebuffer (no cordless IR transmission). It is 
unclear if this ever made it into production.



Dome Imaging Systems
Dome manufacture 
very high resolution video cards - up to 5 Megapixels - for medical imaging and 
other applications.



 Why does the 
Xsun server appear to be so large? 
This information is taken from SRDB 
11507, logged by Phil Race

The "ps" command shows the Xsun server process to be very large on some 
systems. This is particularly noticeable on: 

The latter two share a common device 
driver (tcx). Users may think that they are seeing performance degradation, and 
consider the problem a bug. In most cases there is NOT a problem.

What is happening is that ps is showing the sum 
of the mapped parts of the process's address space, and this does not have to 
correspond to either real memory, or to allocated swap space. That is what 
ps does - it tells you about a particular process.

Access to many devices is often memory-mapped into the address space of a 
process. This is a common technique, and means that applications need not know 
the details of the device, instead they just do what they consider to be regular 
memory writes.

A process has a virtual address space, and cannot write into "real" memory at 
all - instead the kernel intercepts all such requests and handles them together 
with the MMU. The sx and tcx drivers use a particularly large amount of the 
process address space.

This phenonmenon is not new, nor specific to these framebuffers. The cgsix, 
the mouse, the keyboard, are all mapped in the same way, but the amount of 
address space mapped for these devices is smaller and so is less noticeable.

NB: The SX and S24 are 24-bit devices, and if you run 
OpenWindows in 24 bit mode, then they WILL use more swap than in 8 bit mode. In 
such circumstances you may see unavoidable paging until you add more memory to 
compensate for your increased demands.



 Can I use a 
Sun monitor with my PC?
Newer Sun monitors have multiscan capability 
which allow them to be used with PC graphics cards. The latest monitors 
[Mid-1998], including the 24" [T-Rex], 21" [Hurricane] and 19" [Cyclone] have 
dual inputs and accept both 13W3 (SUN) and HD15 (PC) type connections. Some 
older monitors, notably the 17" and 20" N2 monitors will work, but require a 
13W3 to HD15 adaptor.

SunExpress have such an adaptor, 
part number 530-2357-01. This has been tested with the following monitors in 
both DOS and Windows modes:



Ultra 
Spec Cables manufacture two different adaptors. The part numbers are 
1396 and 1397; the catalog lists them as 
13W3 Female to HD15 Male converters. The 1397 is identical to 
the one sold by SunExpress, and 
works with the same monitors.

Ultra's catalog states that the 1396 is for use with three monitors; these 
are part numbers 365-1286, 365-1316 and 365-1324. These are all Sony monitors 
with the remote control, however this style of monitor also carries several 
other part numbers, such as 365-1330 and 365-1167; Ultra have not claimed to 
support these monitors.

These monitors support Windows hi-res drivers only. They do not work 
in DOS mode which is something like 640x480@60Hz. (According to 
Ben Myers this is actually the very old CGA mode 3, defined as 80 
characters wide x 25 lines high, with vertical scan not too well defined. But 
most graphics cards, VGA and beyond, use 60Hz.) The monitors will not sync so 
low. The editor has tried using a 365-1324 in 1024x768 and 1280x1024 mode with a 
S3 chipset PCI video card without success, but has heard positive reports from 
other users.

One user reported that it was possible to use a 17" Sony GDM17E10 monitor; he 
used a standard 13W3 to HD15 cable with a small piece of wire inserted into the 
HD15 to short pins 13 and 14 - this provided the necessary sync signals. If you 
wish to use any other Sun monitor with a PC there are third party PCI/ISA card 
available. These work with windows but require drivers for DOS (that ship with 
them). Consult your favourite WWW search engine or check Photon, 
Mirage or Software Integrators in the 3rd party 
vendors list.

For an introduction to the issues of using fixed frequency monitors on PCs, 
consult the 
sci.electronics.repair FAQ maintained by Samuel M. Goldwasser.



 What frame 
buffers are/are not supported in the Ultra machines?
This information is 
taken from the Sun Ultra 1 Creator Series System Product Notes Part no: 
802-4149-10, Rev A, January 1996. This document contains the 
following information: 
Not listed above, but 
also unsupported, are the CG3 and the SX expander card.



8 bit frame buffers
The TGX and TGX+ are definitely supported in the 
Ultra series, and are the preferred solution for multi headed machines.



24 bit frame buffers
The preferred option for 24 bit graphics on Ultra 
is the FFB. If users need a second 24 bit display they should look at the Rasterflex-32 
card, which is available through SunExpress or from VisiCom.

As of October 1996, the ZX frame buffer will be supported in Ultra 1 and 
Ultra 2 machines. This is primarily intended to allow customers who are 
upgrading from older sun4m machines to keep the ZX; it is highly unlikely that 
new Ultra systems will be sold with ZXs.

The ZX is not a low cost alternative to the Creator; on the contrary, ZX is a 
much more expensive graphics option than the Creator graphics and has less than 
half the Creator graphics 3D performance and none of its image processing and 
video playback capabilities. Customers should be encouraged to upgrade to 
Creator graphics if at all possible.

In order to install the ZX in an Ultra 1 system you will need the ZX 
Ultra 1 Kit part #595-4072. This includes a flexible power cable that 
goes from the bottom SBus connector on the ZX to the lower SBus slot in the 
Ultra 1. There is also a ferrite cable clamp that needs to be placed at the end 
of cables plugging into the stereo port in order to pass FCC Class B 
certification. 

(The ZX kit is not required in Ultra 2 systems as Ultra 2 has side by side 
SBus slots and passes FCC Class B without the ferrite connector.)

Note that the Turbo ZX will not be supported in either Ultra 
1 or Ultra 2 systems, since it requires additional power and cooling.



 Why are 24 bit 
Frame Buffers so expensive compared to a PC?
An often-heard complaint is 
"Why can't Sun sell a 24 bit frame buffer for $200 like I can get for my 
PC?". Regular viewers will remember that this section of the document had 
a detailed explanation of why this wasn't a fair comparison. However Sun's 
announcement of support for PCI bus architecture should change all that. It will 
now be possible for manufacturers to release Sun versions of their graphics 
products. Whether this boost to competition in the marketplace will result in a 
$200 24 bit frame buffer remains to be seen.



 How do I 
change the resolution on the SparcStation 4?
The SparcStation 4 with the 
17" entry level monitor has a default screen resolution of 1024x768. Both the 
monitor and the frame buffer will support 1152x900. With an additional VSIMM the 
TCX will support 1280x1024, but I'm not certain that the monitor will.

As noted above, 
the timing parameters are different for the TCX. Here's an example of how to set 
the resolution to 1152x900 on the entry level monitor. Halt the machine and 
type: 
    ok> setenv output-device screen:r1152x900x94
    ok> setenv fcode-debug? true
    ok> reset

The following script was used to set a dual headed SparcStation 4 with the 
extra VSIMM and a TGX+ to 1280x1024. The system used two 20" premium monitors. 
#!/bin/sh
#
#
#
/usr/sbin/eeprom nvramrc='devalias hightcx /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@2,800000:r1280x1024x135
probe-sbus
" /iommu/sbus/cgsix@0" select-dev
r1280x1024x76
" /iommu/sbus/cgsix@0" " set-resolution" execute-device-method drop
device-end
install-console
banner
'
/usr/sbin/eeprom output-device=hightcx



 How can I tell 
whether I have the 4Mb or 8Mb SX VSIMM installed?
The easy way is to 
take the lid off - if the VSIMM has chips on both sides then it's 8Mb, if the 
chips are on one side only it's 4Mb.

However if you can't take the lid off you have more of a problem. dmesg, 
sxconfig and cg14config don't tell you anything useful about the VSIMM. The only 
way to get this information is to analyse the output from prtconf, 
thus:

% prtconf -vp
. . .
            reg:  00000002.00000000.00010000.00000004.00000000.00400000
            device_type:  'display'
            name:  'cgfourteen'
. . .

The important value is the final value on the reg: line. In 
this case the value is 00400000, which indicates a 4Mb VSIMM is present. If an 
8Mb VSIMM is present the value will be 00800000.



 What is 
different about the "new" TGX and TGX+?
There's a line you're supposed 
to quote at this point that goes something like "In accordance with Sun's policy 
of constant improvement..."

The "old" TGX had the part number 501-2325; the new one has the part number 
501-2922. The only difference between them is that the packaging of the ASIC has 
changed from Ceramic PGA to Plastic BGA. There is no logic or performance change 
and it uses the same PROM which reports the old part and chip rev numbers. 

Similarly, the old TGX+ had part number 501-2253, while the new one has part 
number 501-2955. Once again, only the packaging of the chips - in this case both 
the ASIC and the RAMDAC - has changed.

The only way to tell the difference is to visually inspect the boards. The 
new style has a smaller sleeker green and black package; the older style is the 
obvious purple-brown ceramic square.

These changes provide a significant cost reduction without impacting quality.



 What set of 
resolutions do the FFB series support?
The supported resolutions for FFB 
can be found by the command /usr/sbin/ffbconfig -res \?

The values will vary according to the card and driver in use. To set the 
resolution, run the ffbconfig program and restart OpenWindows or CDE. You do not 
need to reboot.



 Can the FFB1 
be used with the new 24" HDTV monitor?
The FFB is supported on the 24" 
monitor at 1280x800 resolution. You should install the latest FFB patch (for 
Solaris 2.5.1 this is 103796). Higher resolutions (such as 1900x1080@72) can be 
achieved but do not work well and are not recommended or supported.



 What 
resolutions does the FFB2/2+ support with the new 24" HDTV monitor?
With 
the new 24" HDTV monitor the FFB2/2+ Creator 3D will support these additional 
resolutions: 
	1920 x 1200 single-buffered
	1600 x 1000 single-buffered
	1440 x  900 single-buffered
	1280 x  800 single-buffered or double-buffered

This frame buffer has 15Mb RAM on board, normally used to provide 96 bits 
per pixel. That's roughly 32 bits each for each of the double buffers plus 32 
for the Z buffer (it's more complex than that, but bear with me).

The two display buffers can be combined to give 10Mb to use as a single 
display buffer. However the Z buffer memory cannot be combined in this way, 
which is why you can't have double buffering at higher resolutions.

Be aware that the 24" monitor uses the same sense code as the regular 20"/21" 
monitors. (Sense codes use just 3 bits, and there are no unused combinations 
left.) Consequently the system may be unable to determine whether a specified 
resolution is supported by the monitor. If you are unsure as to whether the 
resolution you need is supported, use the "try" parameter to ffbconfig.

More information on this subject is available on the Sun Internal Only FAQ.



 What set of 
visuals does the FFB support?
The FFB supports the usual set of 8 and 24 
bit visuals, namely GrayScale StaticGray PseudoColor StaticColor 
DirectColor and TrueColor. 24 bit DirectColor visual is 
supported.

It also supports a complex set of 8 and 24 bit overlays/underlays, and both 
linear and nonlinear gamma correction. More information is needed.



 I'm confused 
by all these Creator boards. What's the story, Morning Glory?
You're not 
the only one. The difference between Creator and Creator 3D is the amount of 
on-board memory. Creator 3D has 15 MB of 3DRAM whereas Creator has only 5MB. 
This makes no difference to the raw geometry rendering speed, but double 
buffering and Z-buffering will be performed in software on the plain Creator, 
whereas Creator 3D will be hardware-assisted as it has the extra bit-planes to 
store this data.

The Series 2 has a 50% performance speedup and supports 1920x1200 in single 
buffer mode, YCC->BGR conversion and OpenGL depth cueing.

The Series 3 has programmable gamma correction, has multiple hardware 
colormaps and management software and has hardware stencil support.



Graphics part number and system support matrix.



  
  

    
    Horizontal Form Factor
    Vertical Form Factor

  

    Creator Series 1
    Ultra1, Ultra2
501-2634		
    NO

  

    Creator Series 1
Server compatible		
    Ultra1, Ultra2, Ex000
501-4127		
    NO

  

    Creator 3D Series 1
    Ultra1, Ultra2
501-2633		
    NO

  

    Creator 3D Series 1
Server compatible		
    Ultra1, Ultra2, Ex000
501-4126		
    NO

  

    Creator 3D Series 1
75 MHz		
    Ultra2, Ex000
501-3129		
    NO

  

    Creator Series 2
    NO
    Ultra30
501-4174

  

    Creator 3D Series 2
    Ultra2, Ex000
501-4173		
    Ultra30
501-4172

  

    Creator Series 3
    NO
    Ultra10, 30, 60
501-4789

  

    Creator 3D Series 3
    Ultra450, Ultra2, Ex000
501-4790		
    Ultra10, 30, 60
501-4788

  

    Elite 3D m3
    NO
    Ultra30, 60
595-4871

  

    Elite 3D m6
    Ultra450, Ultra2
595-4878		
    Ultra30, 60
595-4870
Note that this table only 
shows the configurations that are supported - ie have been 
formally qualified after extensive testing. Other configurations may work, for 
example FFB2/2+ or AFB in an Ultra 1, but are not officially supported.



 There are two 
speeds of Creator 3D Series 1. Which one do I need?
For Ultra 1 and 
Ultra 2 machines with CPUs less than 200MHz (including dual CPU models) you 
should use the 66MHz model. For 200MHz and above and for all Ex000 series 
machines use the 75MHz model.



 Can I run two 
different window managers together on a dual headed machine?
Although 
not a frame buffer question, this one pops up time and again.

Yes, it is possible to run a different window manager on each display. The 
most common combination is to have CDE and OpenWindows side-by-side, thus 
achieving the best of both worlds. To do this, you must first set the resource 
Dtwm*multiScreen to False in your 
.Xdefaults file. You then add the following line to the file 
$HOME/.dt/sessions/sessionetc 
	/usr/openwin/bin/olwm -single -display :0.1 &

If the file did not exist before, create it, and make sure that it is 
executable. It may also be necessary to copy the file to 
$HOME/.dt/sessionetc. Now restart dtlogin and you should have olwm 
on the second screen.

There is a drawback to this; attempting to change some of the properties 
using the Style Manager can cause the server to die.



 How can I 
capture the video output from a frame buffer?
The Creator and ZX frame 
buffers support "PAL" and "NTSC" resolutions, and provide Composite Sync with 
the appropriate timings. However converting from RGB + CSYNC to Composite Video 
may need additional equipment.

If your TV/VCR has a SCART connector (common enough in Europe, but very rare 
in North America) then it is fairly easy to make a cable to accomplish this. 
There is a web page at http://www.ts.go.dlr.de/~bob/scart/scart.html 
that gives instructions on how to do this; it is written in German, but is not 
difficult to understand. There is also a GIF image 
that shows the wiring.

Other Sun frame buffers do not support PAL or NTSC resolutions, so a 
converter of some kind is required. SunExpress sells the 
"HyperConverter-1280" (PCV-HYPER-1280) - contact them on 1 800 USE SUNX. Extron 
also market a range of scan converters and "trans converters".

As far as 3rd party video cards go, the Parallax 
XVideo product seems to be well regarded.



 Can I drive a 
TV from any of the frame buffers?
See the previous 
answer. Yes you can, but only with the high-end products or an expensive 
converter. If you're trying to drive a TV then cost is probably a strong 
consideration, and Ultras with FFBs probably aren't what you're after. You might 
want to look at Quantum 
3D's MGX product line or other third party cards.

There have been quite a few recent PC products that can change a 640x480x60 
resolution screen into a tv viewable signal. These are readily availible at 
local pc stores and are cheap. The problem is that these devices generally 
require seperate sync (h/vsync) and Sun frame buffers use combined sync (csync).

There exists a utility for the FFB2+ (Creator series 3) which allows it to 
provide dual sync. However this is not a supported Sun product and all the usual 
disclaimers and caveats apply - use at your own risk. The source is not 
available. The utility can be downloaded 
from here.



 Why does the 
ZX console not sync correctly after using Stereo mode?
There appears to 
be a problem with the ZX console after using Stereo mode. After reverting to 
Mono mode and exiting OpenWindows the console screen appears not to sync 
correctly.

This is due to the prom thinking the machine is in stereo mode (the prom 
draws the console mode text) and the machine really being in standard mode. 

When you leoconfig the machine into stereo mode, the prom can detect the 
change from normal->stereo. However it does not detect the change from 
stereo->normal. The kernel always know what is going on, which is why 
OpenWindows comes up correctly regardless.

The solution is to keep the machine in stereo mode or to re-boot.

The root cause is that there is inadequate communication of this information 
to the prom. ZX has implemented this one way, FFB another, and other 
framebuffers do yet other ways. TGX by the way avoids the whole problem by not 
providing a config program! Our engineering is proposing a mechanism from kernel 
to prom; still it will be a long time before our whole product line deals with 
this.

As an aside, Windows avoids all this because "console mode" is always VGA. 
When the BIOS has to write something it knows to switch the screen to VGA mode.



 How can I 
write to the frame buffer directly?
This question comes up regularly, in 
various forms. Sun does not support direct access to ANY of our frame buffers. 
The frame buffer device drivers and interfaces are considered proprietary and 
are not publicly documented. The only supported way for a customer to access a 
frame buffer is through one of our foundation libraries: X, XIL, XGL or OpenGL. 
There are simply too many problems in allowing direct access by customers, most 
significantly the fact that the code will break whenever the hardware changes. 
By supporting a number of low-level interfaces, Sun performs any porting for 
you, so your code should continue to work regardless of the actual platform.

The supplementary question here is: 

Why aren't programming docs for Sun frame buffers at least available on a 
NDA basis?
And the answer is: Programming docs for Sun frame buffers don't 
exist, full stop. The level of support and documentation needed to do this 
across the product line would be significant. There are several very subtle 
rules and restrictions for each device - all have individual differences beyond 
the register definitions. Many of these restrictions are not well documented 
except in the driver code. Some of them may hang the system if violated.



 What is gamma 
correction?
For a detailed explanation of gamma correction see the 
references by Robert W. 
Berger and Charles Poynton in 
the Other 
Useful Resources section.

In simple terms, normal CRT monitors do not have a linear relationship 
between input voltage and output brightness. Consequently there is not a linear 
relationship between RGB values and the brightness of the colour on the screen. 
There are simple ways to demonstrate this in the references cited above.

Most 24 bit frame buffers provide a means to apply gamma correction. For the 
SX or ZX it is done by giving a -g flag to the appropriate configuration 
program, whereas on the FFB there is a seperate gamma corrected TrueColor 
visual, used by toolkits such as XGL and OpenGL.

The latter poses a problem in itself; since the same RGB value produces two 
completely different colours in different visuals, how can tools such as 
snapshot and imagetool know what the "correct" value is? 

If your application has an image that you wish to apply gamma correction to, 
here is a simple algorithm to create a lookup table: 
short gamma_table[256];

void create_gamma_table(gamma_factor)
double gamma_factor;
{
    int i;
    double new;

    for (i = 0; i < 256; i++) {
        new = 255.0 * pow((i / 255.0), 1.0 / gamma_factor);
        gamma_table[i] = (int) floor (new + 0.5);
    }
}

How the lookup table is applied to the image will depend on the visual. 
For 8 bit PseudoColor a transformation will be applied to the colormap; for 24 
bit TrueColor it can be applied to the image itself. The 24 bit DirectColor case 
is left as an excercise for the reader.



8 bit case:
NB: This code is incomplete; it's adapted from an example in 
the Colormap FAQ. It's here to demonstrate the principle. 
	/* Create new colormap */
	xcmap = XCreateColormap(display, win,
        DefaultVisual(display, scrn), AllocNone);

    ycmap = DefaultColormap(display, DefaultScreen(display));

	/* Get all colours in default colormap */
    for (n = 0; n < 256; n++)
        xcolours[n].pixel = (long) n;
    XQueryColors(display, ycmap, &xcolours[0], OFFSET);

	/* Allocate colours in new colormap */
	if (!XAllocColorCells(display, xcmap, TRUE, NULL, 0,
                        pixels, 256))
		printf("Failed to allocate colour map info\n");

	/* NB: Ordering of Red, Green and Blue *IS SIGNIFICANT* */
	i = 0;
    for (n = 0; n < 256; n++) {
        xcolours[n].red = gamma_table[cmap[i++] << 8];
        xcolours[n].blue = gamma_table[cmap[i++] << 8];
        xcolours[n].green = gamma_table[cmap[i++] << 8];
        xcolours[n].flags = DoRed | DoGreen | DoBlue;
    }

	XStoreColors(display, xcmap, &xcolours[0], 256);



24 bit case
Here's an example performing correction on a 24 bit XImage: 
    if (ximage->depth == 24) {
        int i, j;
        long pixel;
        int r, g, b;

        for (j = 0; j < ximage->height; j++) {
            for (i = 0; i < ximage->width; i++) {
                pixel = ximage->f.get_pixel(ximage, i, j);
				/* Ordering of r,g,b is not significant */
				/* so long as the order is maintained */
                r = pixel & 0xff;
                g = (pixel >> 8) & 0xff;
                b = (pixel >> 16) & 0xff;
                pixel = gamma_table[r] + (gamma_table[g] << 8)
                                         + (gamma_table[b] << 16);
                ximage->f.put_pixel(xim, i, j, pixel);
            }
        }
    }



 What's that 
little round socket for on the back of the FFB2/2+?
That's the new 
stereo connector. With FFB2/2+ we moved to a DIN connector instead of the old 
RCA type connector. Here's a diagram showing the pinouts just in case you need 
to setup the cable to connect Quark FFB2/2+ Stereo connector to the infra-red 
emitter. All the usual disclaimers apply.

    Quark FFB2/2+                                    Stereo Emitter
7 pin mini-din male                             DB9-S 9 pin female  
                                                        __
   _________                                           |  \
 _|         |                6 FT +/-2"                |   \
| |         |==========================================|    |
|_|   P1    |==========================================|P2  |
  |_________|                                          |   /
                                                       |__/

           CONNECTOR PIN ASSIGNMENT

+===========+===================+==========+
|   signal  |       from P1     |   to P2  |
|           |   7 pin mini-din  |   DB9-S  |
+===========+===================+==========+
|    12V    |         3         |     6    |
+===========+===================+==========+
|    DV     |         1         |     7    |
+===========+===================+==========+
|    SYNC   |         4         |     8    |
+===========+===================+==========+
|    SHIELD |     P1 HOOD       | P2 HOOD  |
+===========+===================+==========+

On P1 Connector: Pins 2,5,6,7 NOT USED
On P2 Connector: Pins 
1,2,3,4,5,9 NOT USED
StereoGraphics sells a setup that 
comes in 3 pieces: glasses, an IR emitter box, and a cable to hook up to the 
framebuffer. For the FFB2/2+ the cable+emitter is StereoGraphics part number 
ESUN. They also make versions that works with the FFB1 and the ZX.

For just the cable to hook FFB2/2+ to your existing emitter this is 
StereoGraphics part number 69967. The glasses are part number CE2.

Incidentally, StereoGraphics made prototypes of lower cost glasses that have 
a wire that connects to the framebuffer (no cordless IR transmission). It is 
unclear if this ever made it into production. 

 What's the 
story on PCI?
PCI is a platform independent hardware standard; for 
details visit the PCI Special Interest Group at http://www.pcisig.com/. The intention is that 
future machines will be developed with PCI interfaces only. However this doesn't 
mean that SBus is going away - there is still a massive installed base which 
will be supported for many years to come.

The first PCI frame buffer from Sun is the PGX. This is an 8 bit device with 
features and performance comparable to the TGX. It supports a wide range of 
resolutions, and is configured using a program called m64config rather than the 
old prom-value method required by the TGX. Also unlike previous frame buffers it 
does not use sense codes to determine the resolution.

For full details of PCI cards that are supported in the Ultra 30 series, 
including graphics and other products, see http://www.sun.com/pci.



 So can I take 
a PCI card from my Sun and plug it in my PC (or vice-versa)?
As stated 
above, PCI is a HARDWARE standard. This doesn't mean that you can buy an Ultra 
30 and plug in the video card from your PC; Nor can you take a PGX or other PCI 
card developed for an UltraSparc machine and plug it into a PC and expect it to 
work. Although the physical connections may be the same the Sun will require 
different device drivers and on-board firmware.

Having said that, I know of people who have developed basic drivers for PC 
cards, notably the Matrox Milennium II. And before anyone asks, they are not 
available for download. Because the card doesn't have OBP (Open Boot Prom) 
firmware it cannot be used as a console device, only as a second head, and 
without further information from the manufacturer it isn't possible to enable 
the advanced acceleration features.



 How do the 
FFB2/2+ and the PGX determine their default resolutions?
Until recently, 
all frame buffers read a "sense code" from the 13W3 connector or adaptor to 
determine what resolution the monitor supported.

This mechanism has now been superceded by a system called DDC (Display Data 
Channel). DDC is a Vesa standard which allows the frame buffer to read 
information known as EDID (Extended Display Identification Data) from the 
monitor. This information includes resolutions supported, max width, max 
refresh, sync type and so forth.

After reading the EDID upon bootup, the firmware looks at the EDID Standard 
Timing Identifiers. It compares each value against the list of supported 
resolutions. If there is a match, that resolution is set and the resolution 
selection process is complete. If not, this process continues until all of the 
Standard Timing Identifiers have been tested. At this point a resolution of 
1152x900x66 is chosen.

The first Sun monitor to support DDC was the Sony "N2" or GDM 20E20.



 Can I use a PC 
monitor on an Ultra 5 or Ultra 10?
Any PC monitor that is "Plug And 
Play" should work with the PGX. Older multisync monitors that do not support 
"Plug and Play" can be used, but it may be necessary to reconfigure the card 
manually using m64config, since the default resolution (1152x900) may not be 
supported by a PC SVGA Monitor and the PGX does not support the 
"setenv output-device" EPROM command.



 What are the 
pinouts for the 13W3 connectors? 
NB: This interface is 
NOT formally documented or committed to. It is subject to change without notice.

	  1   2   3   4   5
	  o   o   o   o   o
  (o)                         (o)   (o)
   A1   o   o   o   o   o      A2    A3
	6   7   8   9   10

Pins A1, A2 and A3 carry the Red, Green and Blue signals respectively. On 
a monochrome frame buffer the signal is carried on Pin A2 (Green).

The following is the configuration for the Creator and Creator 3D and all 
future Frame Buffers. 
	1	SCL			 6	SDA
	2	+5V			 7	Reserved [VSYNCH]
	3	SENSE2			 8	SENSE1
	4	Ground			 9	SENSE0
	5	CSYNCH			10	Ground