
                          clgen v1.3 (12-Jan-98)
                  A generic driver for Cirrus Logic based
               graphic boards for the Amiga under Linux/m68k

                  Copyright (c) 1997,1998 by Frank Neumann

------------------------------------------------------------------------

This document describes installation and usage of the framebuffer device
driver for Cirrus Logic based graphic boards for the Amiga under Linux/m68k.

IT IS IMPORTANT THAT YOU READ ALL OF THIS BEFORE EVEN ATTEMPTING TO USE
THE DRIVER! DON'T EXPECT X11 TO WORK AS ON INTEL LINUX BOXES!

0) Changes since v1.2
   - some bugfixes
   - now accepts monitorcap: and mode: on command line

   Changes since v1.0
   - text consoles on your graphic board! Just start the kernel with
     amiboot [..] video=clgen
   - For 8 bpp (standard case), console scrolling&filling is accelerated
   - Picasso IV support
   - no more need to use the "tog" tool
   - correct standard VGA color palette
   - uses the FB_ACTIVATE_* flags correctly now
   - correct behaviour when used with fbset

   Important! The driver now sits in fb0*, so you can remove the old fb1*
   entries from /dev. Though, you'll either have to rename your fb0*
   entries to more meaningful names ("fb0pal" is a bit irritating for
   1024x768 :-), or create additional symlinks with meaningful names;
   see below in "Creating /dev entries".


1) Supported hardware
---------------------

This driver supports the following graphic boards:
- Piccolo SD64 (Ingenieurbuero Helfrich)
- Piccolo      (Ingenieurbuero Helfrich)
- EGS Spectrum (GVP)
- Picasso II   (Villagetronic)
- Picasso IV   (Villagetronic)

The Picasso II is only supported in linear (non-segmented) mode. Please
make sure that the switch on the rear of the board is set to linear mode.

All other boards only do linear mode, and should thus work out of the box.
It shouldn't matter whether you use them in Z2 or Z3 mode; the only
difference probably being that throughput into the Z2 area is not as fast as
into Z3 memory.


2) Features
-----------

- Variable resolutions: The user can create his own resolutions if he knows
  what he is doing. The driver comes with some pre-generated resolutions, 
  though:
  640x480, 31.25 kHz, 60 Hz, 25 MHz PixClock (startup mode)
  800x600, 48 kHz, 72 Hz, 50 MHz PixClock
  1024x768, 55.8 kHz, 70 Hz, 80 MHz PixClock
  320x200, 31.4 kHz, 70 Hz, 25 MHz PixClock (Super-LoRes ;-)
  1024x768i (interlaced), 31.5 kHz, 77 Hz, 44.9 MHz PixClock
  1024x768hi (interlaced), 46.5 kHz, 113 Hz, 66.2 MHz PixClock
  1280x1024i (interlaced), 51 kHz, 87 Hz, 80 MHz PixClock

  Interlaced modes should not exceed 1024 lines; this is a "Todo" item.

- Color depth: Right now, only 1 bit (monochrome) and 8 bit PseudoColor
  (256 colors, using a LookUp table) are supported. There is already
  code for 16 bit HiColor and 24/32 bit TrueColor in the driver, but it is
  still disabled because the XF68_FBDev Xserver doesn't yet support these 
  modes correctly.

- Virtual screens: Supports "AutoScroll" resolutions larger than the visible
  screen area, e.g. when used with the Xserver. For example, on a 4 MB
  SD64 board using 8 bits per pixel, you can create a workspace as large
  as 2048x2048 pixels. Moving the cursor towards one of the screen borders
  will scroll the display in that direction.
  Please note that in monochrome modes you can only use 1/4 of the display 
  memory due to hardware limitations; for that reason, on a 4 MB board
  the maximum virtual resolution in monochrome is also limited to
  2048x2048 pixels.

- DoubleScan mode: For extra LowRes modes, the driver uses the "doublescan"
  feature of the vga controller which outputs every scanline twice. The
  supplied 320x200 mode uses this. Amaze your friends with a game like
  Thrust filling the entire screen! :-)
  Please note that this mode is not yet available with fbset, as it misses
  a little option I have to add. It's still in the kernel, though.

- Supports multiple boards in one computer: While probably not many users
  will ever need this feature, I found it very helpful while developing. :-)
  At startup, the driver looks for all boards it supports, and initializes
  and registers each of them.
  TODO: This does currently NOT work (v1.2) due to the number of changes
  I had to put in for console support.

- Should correctly determine the amount of DRAM available on the board
  (please mail me if this does not work on your board!)

- Allows to set the maximum vertical/horizontal frequencies with regard to
  the connected monitor. This is done either at the amiboot command line
  (recommended) or via a little program "freq" (see below).

- Allows larger consoles than the default right at kernel startup time;
  no PC-ish hassle with something like svgatextmode!

3) Installing the driver
------------------------
If you received this text file together with a precompiled kernel 
containing the clgen driver, you are ready to go; you can then safely
skip this section and go to the next, "Creating /dev entries".

Otherwise, you will have to compile a kernel of your own. This, of course,
requires a working Linux system complete with gcc, binutils and everything
else that is needed to compile&link a kernel.

You will now have to apply the clgen source patch to the kernel source tree.
The file containing the patch is named "clgen_diffs" and should be in the
archive you unpacked. However, it might also already have been applied
to the kernel source tree; if that is so, I forgot to update this text
file in time; in that case bug me to update it. :-)
I used a 2.0.33 kernel source tree. Adapting the driver for 2.1.xx kernels
will be the next thing to do. Please be patient.

Applying source patches should be something you know about; in a nutshell:
(cd /usr/src/linux; patch -p0 -s < "path_to_clgen_diffs" )

After that, copy the driver main files (clgen.c and clgen.h) to their
destination in "arch/m68k/amiga/" in the kernel source tree.

Next, start the configuration with 
# make config

When asked for the CLGEN driver, answer with "y":
[..]
Amiga Cirrus Logic boards support (CONFIG_FB_CLGEN) [Y/n]: y

After this you can do the usual
# make clean; make dep; make

and have one or maybe even LOTS of cups of coffee while you wait for the
compiler to finish. You should end up with a "vmlinux" kernel binary in
/usr/src/linux containing the clgen driver. Copy it to the usual location
where you keep kernel images on the AmigaOS side.


4) Creating /dev entries
------------------------

To allow any application program to communicate with the (kernel-based) 
driver (I write "any", although the mostly used application is going to
be the Xserver of the X Window System), you now have to create some entries 
in /dev. Usually, you already have a couple of fb0* nodes in there which 
are associated with the built-in video hardware of the Amiga (OCS, ECS or 
AGA).

Now, when starting the kernel with the console on the graphic board, the
fb0 framebuffer device is not used by the Amiga's video chipset (OCS/ECS/AGA),
but by the graphic board. This means you still use the fb0* entries in
/dev, but the video modes "behind" the names have changed (they are now
the predefined modes in the clgen driver). 

You could now either remove the old fb0* devices and create new ones with
the same major/minor device number, but with more meaningful names, or
(what I recommend) keep the old ones and create the new, meaningful names
as symlinks pointing to the old ones.

Here is what I suggest; these are sort-of telling names that correspond to 
the modes that come with the driver.

First, log in as root, go to /dev, check that there are already the
"typical" fb0 devices for Amiga; the following should exist:

crw-rw-rw-   1 root     root      29,   0 Aug  5  1996 fb0current
crw-rw-rw-   1 root     root      29,   1 Oct  1  1996 fb0autodetect
crw-rw-rw-   1 root     root      29,   2 Oct 21 20:11 fb0ntsc
crw-rw-rw-   1 root     root      29,   3 Oct 21 20:11 fb0ntsc-lace
crw-rw-rw-   1 root     root      29,   4 Oct 21 17:34 fb0pal
crw-rw-rw-   1 root     root      29,   5 Dec 31  1996 fb0pal-lace
crw-rw-rw-   1 root     root      29,   6 Dec  5  1996 fb0multiscan
crw-rw-rw-   1 root     root      29,   7 Dec  5  1996 fb0multiscan-lace
crw-rw-rw-   1 root     root      29,   8 Oct 21 17:34 fb0a2024-10

If they don't exist, get the fbset program source, compile and install
it; it contains a target in the Makefile to create those (and more) device
nodes for you.

Now, create the clgen device nodes as symlinks pointing to the old devices:
# ln -s fb0ntsc fb0cl-low
# ln -s fb0ntsc-lace fb0cl-med
# ln -s fb0pal fb0cl-high
# ln -s fb0multiscan fb0cl-highi
# ln -s fb0multiscan-lace fb0cl-highi+
# ln -s fb0a2024-10 fb0cl-vhigh

You should now see this:

root@colorpot:/dev> ll fb0cl*
lrwxrwxrwx   1 root        6 Dec 19 15:47 fb0cl-high -> fb0pal
lrwxrwxrwx   1 root       12 Dec 19 15:47 fb0cl-highi -> fb0multiscan
lrwxrwxrwx   1 root       17 Dec 19 15:47 fb0cl-highi+ -> fb0multiscan-lace
lrwxrwxrwx   1 root        7 Dec 19 15:47 fb0cl-low -> fb0ntsc
lrwxrwxrwx   1 root       12 Dec 19 15:47 fb0cl-med -> fb0ntsc-lace
lrwxrwxrwx   1 root       11 Dec 19 15:48 fb0cl-vhigh -> fb0a2024-10

Well, that's it. Now you can access the modes through meaningful (or so I
think :-) names, but still have the old Amiga video mode names around.

At this time you might wonder what video modes are actually behind those
names; here is a short list:

/dev name     resolution    line frequency (kHz)    frame frequency (Hz)
              x     y
fb0cl-low     640   480           31.25                   60
fb0cl-med     800   600           48.1                    72
fb0cl-high    1024  768           56                      70
fb0cl-highi   1024  768           31.3                    77   (*)
fb0cl-highi+  1024  768           46.3                    113  (*)
fb0cl-vhigh   1280  1024          51                      87   (*)

(*) interlaced video modes

Additionally, you might want to create one more symlink that will be used
for X11 at all times; for instance, I always use the 1024x768 non-interlaced
mode for X11 (which is named "fb0cl-high" in the example above).
So, I create a symlink:

# ln -s fb0cl-high fb0x11

And now I just tell the Xserver to use this mode when starting:
$ export FRAMEBUFFER=/dev/fb0x11
$ startx


5) Installing the utilities
---------------------------

[Please note: Now that it is possible to set the monitor limits immediately
at kernel-startup time, there is no more need for "freq" at all; but I
still include it for your convenience.
For information about setting the monitor limits on the amiboot command line,
see below in "Starting the kernel"].

This driver comes with a small tool for maintenance named "freq".
You get both sources and binaries (compiled for libc6 aka glibc).
For now, I suggest to copy the binary to your /sbin directory and having 
your PATH variable point at that location.

"freq" allows to inquire or set the current monitor limits for the driver,
on a per-board basis.

There used to be another tool named "tog", but this is not required
anymore and will do nothing when started against this driver version;
please delete it. Also, remove any invocations of it, like in your
$HOME/.xinitrc.


6) Checking the cabling
-----------------------

The cabling for the typical (one-monitor) system is just the same as you
might be used to from AmigaOS: The Amiga's output is connected to the VGA
board's 9-pin input with a short cable, and the VGA board's output is
connected to the monitor. This allows to either see the Amiga video signal
(by letting it pass through the board) or the VGA board's signal (by
switching the toggle). If you start the kernel with "video=clgen", though
(see below, under "Starting the kernel"), the board's own video output is
visible all the time and there is no Amiga display at all, so there is no
need to ever switch back to the Amiga signal.

If you have a 2-monitor-setup (one monitor connected to the Amiga, the other
connected to the VGA board), you will see that when you start the kernel
with "video=clgen", the Amiga's signal is just a gray blank screen. This
is so because the Amiga display subsystem is not initialized at all.
You can safely forget about the monitor connected to the Amiga's video
output now.

7) Starting the kernel
----------------------

Starting the kernel with its display on your graphics board works similar to
the way you used to start kernels before: To your list of options passed to 
either amiboot or amiga-lilo (I only use amiboot, so I can't explain what
exactly you have to do to the latter), add the following:

video=clgen[:suboption,suboption]

The suboptions allow you to set the monitor capabilities or startup video
mode right here, instead of having to use freq or fbset later. Here's
how they have to look like:

monitorcap:vmin;vmax;hmin;hmax

  where vmin and vmax are vertical minimum and maximum frequencies in Hz,
  and hmin and hmax are horizontal min/max frequencies in kHz(!).
  The default values are "monitorcap:50;90;30;38", which means vertical
  range from 50 to 90 Hz and horizontal range from 30 to 38 kHz.

mode:{low|med|high}
  This sets the startup (default) video mode for all consoles.

  Name    resolution[pixels]   hfreq[kHz]     vfreq[Hz]   columns  rows
  low        640x480            31.25           60           80     30
  med        800x600            48              72          100     37
  high      1024x768            55.8            70          128     48

So, here's as an example a complete line from MY current setup;
don't even think about using exactly this line in your setup:

   "video=clgen:monitorcap:50;120;30;86,mode:high"

PLEASE NOTE! The ";" character under AmigaOS has the meaning of a comment,
thereby discarding the rest of the line. Therefore, if you use the
"monitorcap:" suboption, don't forget to enclose the whole option in
double quotes (" ") to avoid this misinterpretation of ";". If the kernel
does not start in the way you expected, this is a possible reason; type
"cat /proc/cmdline" to see whether really the whole parameter list was
passed through.

When the kernel starts, you should see the clgen driver report its
version number and what hardware it has found, like this:

[..]
   0x42000000: Helfrich SD64 Graphics Board (RAM) (Z3, 16M)
   0x00e90000: Helfrich SD64 Graphics Board (REG) (Z2, 64K)
 clgen: Driver for Cirrus Logic based graphic boards, v1.3 (12-Jan-98)
 clgen: Monitor limits set to H: 30000 - 86000 Hz, V: 50 - 120 Hz
 clgen: SD64 board detected;  RAM (16384 KB) at $42000000,  REG at $e90000
 clgen: This board has 4194304 bytes of DRAM memory
[..]

Don't be confused by the different numbers for RAM amount (16 MB vs. 4 MB);
the first number is the Zorro address space usage, which is often larger
than the amount of RAM on the board. The number in the last line should
be the actual amount of RAM your board has.

At this point you can already open a bottle of champagne, because if you
can read the above messages, it means the driver works for you. The (default)
console looks pretty much like before on OCS/ECS/AGA, but it's now in 
60 Hz instead of 50 Hz (PAL), and it uses 256 colors. Of course, if you
immediately try to use one of the higher console sizes (mode:med or 
mode:high), it will look even better :-). But for a start it's probably
wise to begin with the default mode and make sure that it works.

If you attempt to start the kernel with a video mode that exceeds the
monitor limits, the driver will fall back to the standard "low" mode instead.
Also, if your "monitorcap:" suboption makes no sense, the driver will
switch back to the default of H:30-38 kHz, V:50-90 Hz.

The display might be misaligned now (like too wide or not centered).
If your monitor has the ability to store video mode settings (display
size and location), you can use its controls now to center the display.
Though, you can also use fbset to do that; see below, in "Using fbset
to adjust modes".


8) Setting/inquiring the monitor limits
---------------------------------------

It is possible that a graphic board can damage the connected monitor by
sending it a video signal with too high or too low line/frame frequencies.
To avoid this, the clgen driver will reject a video mode that would exceed
the specifications of the monitor. But how can the driver know the limits?
The answer is: You have to tell him.

By default, clgen assumes that the connected monitor is a "poor" model that
can only do 30 - 38 kHz line frequency and 50 - 90 Hz frame frequency. 
These should be "careful" defaults for most monitors in use nowadays.
Also, the video mode that the board produces at kernel startup is a
very "careful" mode using just 640x480 pixels with 31.5 kHz line frequency
and 60 Hz frame frequency - even fixed-frequency old VGA monitors should
be able to handle this.

If you try to activate a mode that exceeds your monitor's limits, you will
get a message from the clgen driver on the current console, like this:

      clgen: desired mode exceeds monitor limits (rejected)!

If your monitor CAN handle higher frequencies than the default, please look
up its limits in your monitor's manual, and set the corresponding values
in the kernel, using either the "monitorcap:" option as explained in the
previous chapter, or use the "freq" tool to tell the driver about it. 
I recommend using the "monitorcap:" option of amiboot, as your monitor limits
will probably rarely ever change in the near future, and most of the time
there is no need to change the limits during one Linux session.

The usage is:

Usage: freq [-q] [-f n] [-s minhor:maxhor:minvert:maxvert]
 -q                                queries the current monitor settings
 -f n                              chooses framebuffer driver #n
 -s minhor:maxhor:minvert:maxvert  sets new limits
    All min/max values are in Hertz (hz), e.g. 30000:38000:50:90

So, to get the current limits for framebuffer #0 (which is probably
your graphic board), type:

root@devuan:~> freq -f 0 -q
Current monitor limit settings for fb driver #0 [CLGen:SD64]:
Horizontal: 30000 - 38000 Hz
Vertical: 50 - 90 Hz

Let's assume your monitor can do 30 - 58 kHz line frequency, and 50 - 100
Hz frame frequency. Then, you'd type (as root):

root@devuan:~> freq -f 0 -s 30000:58000:50:100
Monitor limit settings for fb driver #0 [CLGen:SD64] have been set to:
Horizontal: 30000 - 58000 Hz
Vertical: 50 - 100 Hz

You see that the limits have been raised, and modes within the new limits
will not be rejected anymore. Please note that modifying the limits is
regarded as a "privileged" operation, and can thus only be executed
by root. Anyone can inquire the current settings, though.

PLEASE NOTE: Don't just enter some invented numbers - LOOK UP THE SPECS
IN YOUR MONITOR'S MANUAL! Otherwise you risk damaging your hardware.

PLEASE NOTE2: If you are upgrading from the 1.0 driver, check out any place
where you start freq; the framebuffer number is now 0 and not 1 anymore
(as it used to be)!

Personal suggestion: If you do not want to use the "monitorcap:" option
for whatever reason, I suggest to put the "freq" invocation into a startup
file like "/etc/init.d/boot" (or however it is called on your installation).
But note that by the time the program is started, your root partition is
probably the only one that is mounted - so keep the "freq" binary in a place
on the root partition (like /sbin).

PLEASE NOTE3: Once you have installed the "freq" invocation in a startup
file like suggested in the previous note, starting the kernel with an
Amiga console again ("video=pal-lace" or similar), you might run into
problems when trying to change a mode; this is so because some of the Amiga's
video modes just use 15 kHz line frequency (even if doubled by a hardware
flickerfixer; it's the number that counts), and your monitor can only do 
30 kHz or above. In that case, you will have to change the monitor limits
again before you can change video modes for it.


9) Using fbset to adjust modes
-------------------------------
You have probably 2 choices to center the display on your monitor:
You can either use the monitor itself (newer models are able to store
a lot of video mode settings and immediately activate a stored profile
whenever they recognize a certain frame format), or you use fbset.
fbset also allows to adjust a lot of other things - like, setting totally
new timing parameters. I will not explain the fbset usage in full detail
here; rather, I'll only give a little example of what might be a typical
usage of it for the clgen driver.

Let's assume you have sucessfully started the kernel, see the initial
640x480 image, but it is not centered. Now you can use fbset like this
to move the image around:

# fbset -move [left|right|up|down]

This will move the image in the corresponding directions (not every
invocation moves the display as the granularity of fbset is finer than
that of the VGA hardware; try invoking it several times to get a feeling
for it).
Similarly, you can set all timing values (-left, -right, -up, -down,
-hslen and -vslen) until you are satisfied. When done, you can ask
fbset to print out the current timing parameters of the "current"
video mode:

# fbset -i

and write the "mode" part of the output into your /etc/fb.modes file
where it is quickly available. Replace the "name" with a meaningful name
(I suugest to choose a naming scheme that start with "cl-", like "cl-high".
From now on, you can immediately set this mode with a command like
"fbset cl-high".

NOTE GPM USERS!
The "gpm" program which lets you do Cut&Paste operations on the console
will not notice when you change the console's video mode (size) and will
continue to use the columns/rows numbers it has determined when it started.
This can lead to two strange things:

a) You change to a higher-resolution console: The mouse cursor of gpm will
   not be able to access certain parts of the console (at the far right
   and bottom of the screen).

b) You change to a lower-resolution console: It is possible to move the
   mouse cursor out of the visible area.

These are no bugs of clgen. My solution suggestions are:
- to fix gpm's signal handling (if it's really the culprit)
- to not change the console size at all (and only use mode:xxx at startup)
- to restart gpm after a console size change

In section "Example of fb.modes entries" below you will find a list of
modes that you can append to your /etc/fb.modes file. The listed modes are
exactly the same as those found in the kernel driver (except for the
SuperLoRes mode).

All of this still doesn't really help you because the mode used by the kernel
at startup time is not taken from /etc/fb.modes, but from the driver itself;
if you have changed the video mode and want it to appear like that
immediately at kernel startup time, you still have the option to put your
new timings into the driver's mode database itself and compile your own
custom kernel. 


PLEASE NOTE: THE PARAMETER CHECKING IN THE DRIVER IS VERY INCOMPLETE;
YOU MIGHT BE ABLE TO CREATE A TIMING SETTING THAT CREATES AN UNUSABLE
DISPLAY (WHICH MIGHT EVEN LOCK UP THE COMPUTER). USE FBSET WITH CARE!

fbset is also used set an oversized ("autoscroll") display; here is
an example:

Let's assume you have a poor monitor that cannot do much better than
640x480 pixels, which is usually too little for reasonable working in X11.
So, to create a virtual workspace of, say, 1024x768 pixels, you'd
type:
# fbset -ofb /dev/fb0x11 -vxres 1024 -vyres 768

Now you just have to tell the Xserver which mode to use, and start it:
# export FRAMEBUFFER=/dev/fb0x11
# startx

When the Xserver has started, trying moving the mouse pointer against
the right or bottom border, and you should see the well-known autoscroll
effect.


10) Starting/using X11 with clgen
---------------------------------
The application that's (IMHO) going to be the most-used one is the X
Window System. Unfortunately, using it with the clgen driver is not quite
as easy as is with Linux on i386 machines, but it's very close by now.

The only thing you have to do before you can start X is to tell the Xserver
on which framebuffer device it has to work; using bash, this is typically
something like:

$ export FRAMEBUFFER=/dev/fb0x11
$ startx

Replace the "fb0x11" with whatever video mode device you want to use for X.

If you rather start an Xsession via xdm instead of "startx", you will have
to put the "export ..." line into something like /etc/init.d/boot (or 
wherever your xdm gets started). It's just important that FRAMEBUFFER
is set to the correct device name before the Xserver starts.


11) Example of fb.modes entries
-------------------------------

The following is an excerpt from my /etc/fb.modes file; it provides the
same video modes as those predefined in the clgen driver. Just append this
to your /etc/fb.modes file, and you can immediately switch to one of them
by feeding its name (from the "mode" line) to fbset, like so:

$ fbset cl-med

This will of course only work if:
 - your monitor can operate at the desired frequency
 - you set the monitor limits with freq accordingly


########################
## CLGen modes, as found in the predefined modes in the driver
########################

# 640x480. This mode should work on ANY Multiscan monitor
mode "cl-low"
	# H: 31.250 kHz, V: 59.524 Hz
	geometry 640 480 640 480 8
	timings 40000 32 32 33 10 96 2
	hsync high
	vsync high
	bcast false
endmode

# 800x600. Nices for consoles
mode "cl-med"
	# H: 48.077 kHz, V: 72.188 Hz
	geometry 800 600 800 600 8
	timings 20000 64 56 23 37 120 6
	hsync high
	vsync high
	bcast false
endmode

# 1024x768, non-interlaced. If your monitor can do this, it's a
# good choice for X11.
mode "cl-high"
	# H: 55.866 kHz, V: 69.399 Hz
	geometry 1024 768 1024 768 8
	timings 12500 92 112 31 2 204 4
	hsync high
	vsync high
	bcast false
endmode

# 1024x768, interlaced. If your monitor is not capable of high
# horizontal frequencies, this might be a good alternative to cl-high.
mode "cl-highi"
	# H: 31.360 kHz, V: 76.769 Hz
	geometry 1024 768 1024 768 8
	timings 22268 92 112 32 9 204 8
	hsync high
	vsync high
	laced true
	bcast false
endmode

# 1024x768 interlaced, but with a bit higher frequencies, so less flicker.
mode "cl-highi+"
	# H: 46.240 kHz, V: 113.196 Hz
	geometry 1024 768 1024 768 8
	timings 15102 92 112 32 9 204 8
	hsync high
	vsync high
	laced true
	bcast false
endmode

# 1280x1024 interlaced. For those who want "full-size" X11. :-)
mode "cl-vhigh"
	# H: 51.020 kHz, V: 87.589 Hz
	geometry 1280 1024 1280 1024 8
	timings 12500 56 16 128 1 216 12
	hsync high
	vsync high
	laced true
	bcast false
endmode



12) Not-Yet-Features(tm), ToDo's
--------------------------------

- A copy of the driver's mode database should be created for each board
  detected. This is not yet done. Currently all initialized boards share
  the same video mode database in the driver.

- Activate 15/24/32 bit modes once the Xserver at least supports some of
  them (24/32 bits should not be too hard, but 16 bits is almost impossible
  because the upper/lower bytes are swapped on the bus (on some of the
  boards at least), so that you cannot access the colors as in 
  "rrrrrggg gggbbbbb", but instead "gggbbbbb rrrrrggg" which the Xserver
  will probably never be able to cope with).

- Make use of the BitBlt engine for X11: I understand that lacking blitter 
  support leaves a good deal of the hardware capabilities unused, but the 
  current framebuffer driver does not make any provisions for using 
  accelerated hardware in an application program (like the Xserver).
  Probably once we adopt the ggi concept, this might be added.
  Until then, there is nothing I can do about it. But at least the console
  is already accelerated.


13) Non-features(tm), also known as Known bugs
----------------------------------------------

- In 320x200 DoubleScan mode, a one pixel wide column is visible at the left
  border that should actually be at the right border. I haven't yet found
  the reason for this.

- A few safety checks are still not in there. Use the driver, but don't stress
  it to its limits :-}.


14) Credits
-----------

There are a couple of persons I'd like to thank: 
- Uli Sigmund of Viona, Karlsruhe, for providing me with Cluster sources
  of his EGS drivers.
- Joerg Ringelberg of Viona, Karlsruhe, for supplying me with the databooks
  for CL GD542x/5434.
- Klaus Burkert of Villagetronic for some hints on Fifo threshold settings
  during the Steinhagen Amiga meeting in October '96, and also for info
  on how to turn off the VideoCapture unit on the P4.
- My professor of the Computer Graphics department, Peter Gorny, for
  accepting this as topic for a "Studienarbeit". I always knew studying
  CAN be fun at times. :-)
- Jes Soerensen for maintaining the Linux m68k kernel source since 1.3.xx
  so well (also thanks for this nice little parcel that made my ZipRAM farm
  complete :-)
- Martin Apel; his Cybervision driver for Linux is not really a very complete
  driver (yet? ;-), but due to its simplicity it helped understand some
  of the ideas behind fb.
- Geert Uytterhoeven for several helpful hints and suggestions
- Anyone else involved in making Linux/m68k as usable and stable as it is
  now. Although I believe we won't be able to push Billyboy Gates out
  of the market with this, it shows how well people from all over the world
  can cooperate in the Internet to work on a common goal.
- All you users who bugged me then and now about when this beast will be
  released; I know it took MUCH longer than I had expected/told you,
  but after all it's out now, and is free. Forgive me.
- The "beta guinea pigs" :-) on IRC - Chels, Nes, pCp, you know who you are.
  Thanks for testing&bug reporting.


15) Contacting the author
------------------------

If you 
 - find a bug in the CLGen driver
 - want to tell me how good/bad it works in your environment
 - have source patches/suggestions

please contact me via E-Mail: Frank.Neumann@Informatik.Uni-Oldenburg.DE
Especially if you found something that should be added to this documentation
file, I'll gladly accept it.
I do get LOTS of mail every day, so bear with me if replying takes a while.
(these "lots" do not come from thousands and millions of clgen users, but
from those too much mailing lists I'm subscribed to ;-). Oh, and one more
thing: I DO NOT LIKE MIME-MAIL.

The newest version of this driver should always be available through my
homepage: http://www.informatik.uni-oldenburg.de/~amigo/
Look out for some "Linux/m68k" stuff in that page. I'm sure you'll be
able to find it! :-)

If you want to report a bug, please don't forget to include:
 - what kernel you are running
 - what version of clgen you are using
 - what system configuration you have
 - how you triggered the bug
 - whether the problem is reproducible or not
 - ..and any other information that might be helpful.


16) History
----------

 *  - 16-Mar-1997: v1.0 First public release
 *  - 22-Oct-1997: v1.1 Added basic console support, P4 support (not working)
 *                      This was never released to the public
 *  - 19-Dec-1997: v1.2 Public release
 *                      working console support
 *                      working P4 support
 *                      hardware-accelerated RectFill/BitBLT on consoles
 *                      (only in 8 bits right now)
 *                      correct standard VGA colour table
 *                      1 bit support working again
 *                      uses the FB_ACTIVATE_* flags correctly now
 *                      correct behaviour when used with fbset
 * - 12-Jan-1998: v1.3  Public release
 *                      correct CLUT handling for Picasso4 (was BGR, not RGB)
 *                      removed left-over printk for Picasso II
 *                      now accepts monitorcap: and mode: on command line
 *                      correct "scrolling" when height or width = 0
 *                      (though that's been done in console/fbcon.c)


42) Final words
---------------

Well, good luck now, and of course: You use this driver at your own risk.
If it blows your computer, monitor, cat or girl-friend, I'm not responsible
for that. If it causes a parallel universe to be opened, I'll be interested
in hearing how you managed to do that, though. :-)
This is free software, but I'd never reject signs of appreciation. Even
a little postcard is something I'd always welcome.
Personal plug: I might be able to finish my studies sometime in spring '99 - 
got an interesting job then? Here I am. :-)

Frank, 12 Jan 1998
--
+        Frank Neumann, Hauptstr. 107, 26131 Oldenburg, Germany         +
+     InterNet: Frank.Neumann@informatik.uni-oldenburg.de IRC:Franky    +