NAME¶
svgalib.mach32 - Information on the Mach32 chipset driver
TABLE OF CONTENTS¶
0. Introduction
1. Specifying pixel clocks
2. Copyrights
3. The mach32info utility
4. Third party cards
5. Logical line width
6. Noisy video signals
7. The configuration EEPROM
8. EEPROM woes
9. The Mach32Eeprom command
10. Setup of the memory aperture (linear framebuffer)
11. Accelerator support and other weird features
12. Ramdacs
13. Meaning of the detection message from svgalib
14. Conclusions
0. INTRODUCTION¶
The driver should allow you to use any of the graph-modes your Mach32 card
supports. Note that there is no support for <8bpp modes and that I won't
ever implement that because I don't see any reason for doing so. All standard
VGA-modes are supported, of course (by using the standard VGA driver
routines).
If you configured your Mach32 for a memory aperture and it is at least as big as
the memory of your card (that is, not a 1MB memory aperture for a 2MB card)
support for linear frame buffer access of svgalib is given.
Auto detection of the Mach32 seems not to work on all cards. That's really
strange since I got the code from the X people. It should be OK regardless of
my docs. Well, I fixed that (hopefully). Actually the bug was found by Daniel
Lee Jackson (djackson@ichips.intel.com). (Thanks again.. It was so silly... I
would have never found it) If you still have problems just put a chipset
Mach32 in your config file.
1. SPECIFYING PIXEL CLOCKS¶
WARNING! The Mach32 driver needs to know correct clock frequencies for
graceful DAC configuration. Wrong clocks may damage your card! However, this
version contains code for automatic clock detection. Since clock detection is
time critical, please do it on a completely idle system. Then put the printed
out
clocks line in your
libvga.config(5) file.
The driver tries to do this for you. After that, you can restart whatever
svgalib program you used and you are set. If you already put a
clocks
line in your config by hand, comment it out to have the driver check your
clocks.
Since clock probing is time critical, values differ from time to time, you may
try it multiple times and see which values seem to be most exact. You can also
compare them with the standard clock chips for Mach32 cards in
libvga.config(5)).
The clock probing relies on the 7th clock being 44.9MHz as this is what Xfree
does. If this is not true (and it is not always), probing is hosed. See
libvga.config(5) for a list of the
clocks used by common svgalib
cards.
2. COPYRIGHTS¶
Some tiny routines are copied from Xfree86. The clock detection code is almost
just copied. So I repeat the copyright statements for these parts here:
Copyright 1992 by Orest Zborowski <obz@Kodak.com>
Copyright 1993 by David Wexelblat <dwex@goblin.org>
Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that the
above copyright notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting documentation, and that
the names of Orest Zborowski and David Wexelblat not be used in advertising or
publicity pertaining to distribution of the software without specific, written
prior permission. Orest Zborowski and David Wexelblat make no representations
about the suitability of this software for any purpose. It is provided
"as is" without express or implied warranty.
Orest Zborowski and David Wexelblat disclaim all warranties with regard
to this software, including all implied warranties of merchantability
and fitness, in no event shall Orest Zborowski or David Wexelblat be
liable for any special, indirect or consequential damages or any
damages whatsoever resulting from loss of use, data or profits, whether
in an action of contract, negligence or other tortious action, arising
out of or in connection with the use or performance of this
software.
Copyright 1990,91 by Thomas Roell, Dinkelscherben, Germany.
Copyright 1993 by Kevin E. Martin, Chapel Hill, North Carolina.
Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that the
above copyright notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting documentation, and that
the name of Thomas Roell not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior permission.
Thomas Roell makes no representations about the suitability of this software
for any purpose. It is provided "as is" without express or implied
warranty.
Thomas Roell, Kevin E. Martin, and Rickard E. Faith disclaim all
warranties with regard to this software, including all implied
warranties of merchantability and fitness, in no event shall the
authors be liable for any special, indirect or consequential damages or
any damages whatsoever resulting from loss of use, data or profits,
whether in an action of contract, negligence or other tortious action,
arising out of or in connection with the use or performance of this
software.
Author: Thomas Roell, roell@informatik.tu-muenchen.de
Rewritten for the 8514/A by Kevin E. Martin (martin@cs.unc.edu)
Modified for the Mach-8 by Rickard E. Faith (faith@cs.unc.edu)
Rewritten for the Mach32 by Kevin E. Martin (martin@cs.unc.edu)
And here is my own copyright:
This driver is free software; you can redistribute it and/or modify it without
any restrictions. This library is distributed in the hope that it will be
useful, but without any warranty.
Copyright 1994 by Michael Weller
Email addresses as of this writing:
eowmob@exp-math.uni-essen.de mat42b@spi.power.uni-essen.de
Michael Weller disclaims all warranties with regard to this software,
including all implied warranties of merchantability and fitness, in no
event shall Michael Weller be liable for any special, indirect or
consequential damages or any damages whatsoever resulting from loss of
use, data or profits, whether in an action of contract, negligence or
other tortious action, arising out of or in connection with the use or
performance of this software.
3. THE MACH32INFO UTILITY¶
The
mach32info(6) utility or demo reads out all configuration registers
and the configuration EEPROM of your Mach32 card. If there is a problem with
the particular card you have, compile and run the utility in the
mach32/ directory of the svgalib distribution and send it's stdout to
me This might also be useful if you need a lot of options (e.g. clocks on new
models?) to get it to work so that this can be done automatically in future
versions.
4. THIRD PARTY CARDS¶
I got a few reports about AST systems with onboard Mach32. They do feature an
incompatible EEPROM setup, but I think I got around that. Nevertheless the
Mach32 chipset driver doesn't work out of the box on any AST system I heard
of.
Since original ATI Mach32 demos and tools don't work as well, I've to claim that
the Mach32 on these AST systems does not conform to ATI's Mach32 docs.
Fortunately, Vernon C. Hoxie <vern@zebra.alphacdc.com> found a work
around after years (really!) of investigating. AST Mach32 seems to work now.
The work around was also submitted to Xfree and will be incorporated to allow
running it on the AST hardware too in recent versions. Please read on the
misc_ctl command below.
Dell users should have a look at the
vendor,
ramdac, and
svgaclocks commands below (if they have problems with the default
settings).
Commands to support third party cards¶
I had to learn that those cards seem to use not only non standard clocks for the
Mach32, but also for the included SVGA. However, since people often like to
use proprietary, non standard VGA (read 80x25) text modes, the Mach32 driver
has to set the included SVGA to a VGA compatible clock frequency. Otherwise
svgalib has problems using plain VGA modes. This screws VGA modes up if these
clocks have different values on third party Mach32 cards.
- svgaclocks n
- with n a number between 0 and 31 to
select the svga clocks to be used in vga modes. The bits of n refer
to specific ATI register bits to complicated to explain here. Even if I
would, I can't tell which clocks they would select on your third party
card (which is the actual problem)
svgaclocks 9 is the default setting and correct for original ATI
cards.
Often svgaclocks 0 (Dell cards) works.
- svgaclocks keep
- is special in that the driver will not touch any SVGA
timings. This requires the Mach32 SVGA part to be in a VGA compatible mode
when the svgalib application is started, that is, you must use 80x25
(maybe 80x50) console text modes.
As I mentioned already, Vernon C. Hoxie <vern@zebra.alphacdc.com> really
seems to have located the reason for the Mach32 AST problems. Any access to
MISC_CTL locks up the card & system. Fortunately
MISC_CTL is
only used for some DAC fine tuning (actually the setting you can fine tune
with the
blank command) which is only of barely noticeable effect to
the screen.
The following configuration commands exist to support AST cards:
- misc_ctl keep-off
- Do not dare to touch MISC_CTL.
- misc_ctl use
- Use it for fine tuning of the Ramdac setup (default).
Finally, for your convenience there exist:
- vendor ati
- vendor dell
- vendor ast
- These are macros that expand to settings for
svgaclocks, ramdac, misc_ctl, and mach32eeprom
that are usually correct for ATI, Dell, AST cards. Be aware that they
really work like macros. That is, they override any setting of
svgaclocks, ramdac, misc_ctl, and mach32eeprom
made before them and individual aspects will be changed by a following
svgaclocks, ramdac, misc_ctl, and mach32eeprom
command.
Note that the mach32eeprom ignore required for some Dell cards
requires you to include explicit timings for Mach32 modes other than
640x480x256. The mach32/mach32.std-modes file in the svgalib
distribution contains recommendations for modes from ATI.
I heard about a bug in some ATI chipsets returning wrong memory amounts
configs. (But cannot confirm that)
You can enforce correct chipset identification from the configuration file:
- chipset Mach32 chiptype memory
- where chiptype is the sum of at exactly one value
from each of the following two groups
- 128
- use no memory aperture.
- 160
- use a 1MB memory aperture.
- 192
- use a 4MB memory aperture.
- 0
- choose size for the memory aperture automatically.
and
- 16
- Ramdac is of type 0 (ATI68830)
- 17
- Ramdac is of type 1 (IMS-G173, SC11486)
- 18
- Ramdac is of type 2 (ATI68875, TLC34075)
- 19
- Ramdac is of type 3 (INMOS176, INMOS178)
- 20
- Ramdac is of type 4 (Bt481, Bt482)
- 21
- Ramdac is of type 5 (ATI68860)
- 0
- Ramdac type is queried from Mach32 chip.
- memory is the amount of video memory in KB.
Note that the type of the ramdac can be set more conveniently with the
ramdac command.
5. LOGICAL LINEWIDTH¶
At least my VRAM card seems to be very peculiar about logical line widths. From
my experience a multiple of 64 pels is needed. Your mileage may vary. Use the
config file options to adjust it and tell me if your card needs a different
value. Include the name and model number of the card and what the correct
numbers should be. This is so that I can correct the auto configuration of the
driver.
If some svgalib application has problems, note that you can force the logical
line width to the default value from the config file. Probably this will lead
to glitches in some 800x600 resolutions. You can
inhibit these
resolutions from the config file as well. Apropos glitches, I found no
guidelines as to what clock rates to use due to memory restrictions. I
adjusted the driver, such that I get a stable pic in all resolutions. However
sometimes the screen is disturbed by heavy video memory accesses. If you don't
like that, reduce the clocks used with the maxclock16 or maxclock24 command,
resp. This may of course lead to none of the predefined modes being used. Then
you can try to define your own mode via the define command.
6. NOISY VIDEO SIGNALS¶
If you get some flicker or heavy noise on your screen, some fine tuning may be
needed. My docs didn't give me hints as to what each card can stand.
Especially DRAM cards may give problems (I've VRAM). In that case, use the
fine tuning config commands and send me your results along with the output of
mach32info(6). Then I can include them in my next release.
Fine-tuning configuration commands¶
First you should think about the
maxclock* configuration commands to
reduce pixel clocks used for each color depth.
Especially important for DRAM cards is the video FIFO depth used to queue memory
values for writing to the screen. Here is a command to set this value for the
8bpp modes:
- vfifo8 number
- where number is in range 0 - 15. The
default is now 6.
Since vfifo is of some impact to the speed of the card, tell me the lowest
setting that satisfies your card.
For 16/24/32 modes, there are non-zero values preset from internal tables
and the EEPROM, however you can enforce minimal vfifo values with:
vfifo16 number
vfifo24 number
vfifo32 number
- blank number
- where number is 4 * pixel_delay +
blank_adjust where pixel_delay and blank_adjust
are in range 0 .. 3. pixel_delay delays pixels before
they are sent to the DAC and blank_adjust adjusts the blank pulse
for type 2 DAC's. blank should be set correctly for each DAC type
automatically. So use it only as a last resort.
- latch number
- where number is the sum of zero or more of the
following numbers:
- 128
- VRAM serial delay latch enable, DRAM latch bits 63 - 0
enable.
- 4096
- Latch video memory data.
- 8192
- Memory data delay latch enable for data bits 63 - 0.
- 16384
- Memory full clock pulse enable.
- Default is to switch all settings on (they are on on my
card by default anyway).
Note that these commands may vanish again once they are no longer needed for
debugging purposes.
There is no 320x200 mode in the EEPROM of the Mach32 at all, however I defined
one in the default configuration file for you. This is the best thing I could
get up on my card/screen. Note that it will probably have big borders on your
screen, and black lines in between the pixel lines. This is because of the
lack of low clocks < 16MHz on the Mach32 and the lack of a line doubling
mode as VGA has. The Mach32 is not intended for such low resolutions. If you
find a better mode or have an idea, please let me know. You can also just
remove my timings from the default configuration file.
7. THE CONFIGURATION EEPROM¶
Ah yes, about the EEPROM, I figured out how to read out the Mach32 EEPROM. I did
it by disassembling the BIOS routine mentioned in the docs. I then redid it in
C. The driver will use everything it finds there.
Use the Mach32 install tools (they should have reached you together with your
Mach32 VGA card) to setup your card/monitor combo correctly. The
monitors setting from the config file (or default of 35kHz or
something) will be obeyed by the driver nevertheless (for safety!).
As you probably know already, accessing the EEPROM causes some screen
flickering. If this annoys you (or even worse your monitor) have a look at the
mach32eeprom command described below. This allows you to put the data
from the EEPROM into a file and which can be read whenever it is required.
Don't even think about changing the contents of the file. (There is an easily
faked checksum in it.). Anyway the driver ensures (hopefully) that no damage
can be caused.
Also, if some mode is not well aligned on your screen or you don't like it's
sync frequency, consider using the Mach32 install utility (setup for custom
monitor) and set one up interactively. If there is no valid faster (higher
VSYNC) standard mode given in the EEPROM the driver will use that mode. You
will find that this is fun compared with calculating video timings for
/etc/XF86Config or
/etc/vga/libvga.config.
However the install utility does restrict the maximum pixel depth for custom
modes sometimes unneeded hard and the driver obeys that. (Hmm.. actually it
should be smart enough to decide itself which pixel depth it can use in that
mode.) Since the standard modes are usually only slightly shifted to one side
a file with the configuration commands representing the standard modes is
given in
mach32/mach32.std-modes in the svgalib distribution. You can
use these as a starting point.
But here are some real problems:
8. EEPROM WOES¶
I got 2 reports of people having problems with incorrect EEPROM checksums. Both
had motherboards with onboard Mach32 VGA's from AST. I guessed a checksum
algorithm from those reports and put this in the code in addition to the
standard ATI style. Still I got a report of someone whose EEPROM was
completely empty. If you have problems with checksums send me the output of
mach32info(6) and I'll see what I can do.
By default svgalib writes a complaining message and ignores the contents. You
can have svgalib ignore the checksum and contents with the configuration
command
mach32eeprom ignore
Then you can decide to use the partial info that is still in it. Use
mach32eeprom ignore usetimings
to use the video modes that are defined in the EEPROM (if no better modes are
known by the driver). This is usually safe, because the driver knows which
modes are safe for your hardware (if
clocks,
monitor and
ramdac are configured correctly). You can also allow the driver to use
the configuration for the linear frame buffer in the EEPROM:
mach32eeprom ignore useaperture
or
mach32eeprom ignore usetimings useaperture
However I discourage this because the driver will just enable what the EEPROM
says about the aperture. Use
mach32info(6) to check the address it will
choose is safe. It might be better to use
setuplinear to set up a 4MB
aperture at a free address range.
9. THE MACH32EEPROM COMMAND¶
The
mach32eeprom allows to work around these problems. Here is the
complete description for this configuration command.
- mach32eeprom filename
- The filename has to begin with a "/".
Unfortunately reading the EEPROM causes annoying screen flickering and is
slow. To avoid this, specify a filename from which to read the
contents of the EEPROM.
If the file cannot be read, the EEPROM is read out and the file is created.
There is a very simple checksum put into this file. Although it can easily
be fooled, don't change the file except you know very, very well
what you are doing.
Also, as long as the file exists, changes in the Mach32's EEPROM are
ignored. Delete the file to recreate an updated version on next use of
svgalib. You should ensure that the permissions of the file don't allow
normal users to change it. (This may happen if umask has a bad value when
svgalib creates the file).
Example:
mach32eeprom /etc/vga/mach32.eeprom
Due to problems with some boards this command got heavily expanded:
- mach32eeprom subcommand1
[subcommand2...]
- At least one subcommand is needed. Valid
subcommands are:
- ignore
- Don't complain about checksum and don't use any EEPROM
contents.
- useaperture
- Use the configuration for the memory aperture given in the
EEPROM.
- usetimings
- Use video modes found in the EEPROM of the board.
- nofile
- Forget about any filename that maybe was already
configured. Don't read a file, don't create one.
- file filename
- New style form to specify the filename; On contrary
to the mach32eeprom filename form it can be mixed with any
other mach32eeprom subcommand.
- updatefile
- Don't read the file, always read the EEPROM (except when
ignore is given) and create an uptodate image of the EEPROM.
- keepfile
- Disable all previous updatefile commands.
- compatible
- Fall back to default behavior: If checksum on the EEPROM
data is not ok, use nothing of the configuration data. If it is ok,
configure everything as specified in the EEPROM.
- The subcommands are intended to be used together and are
performed in the order specified. For example:
mach32eeprom ignore useaperture usetimings
will ignore the checksum of your EEPROM, but use its contents. Order is
vital! So:
mach32eeprom useaperture usetimings ignore
won't use any configuration from your EEPROM. Be careful with the
useaperture subcommand. Please see the EEPROM WOES section.
Note that any non understood subcommand will terminate the
mach32eeprom command silently! Use only one subcommand per
mach32eeprom command to avoid this.
The mach32eeprom command is usually not allowed in the environment
variable SVGALIB_CONFIG.
10. SETUP OF THE MEMORY APERTURE (LINEAR FRAMEBUFFER)¶
Due to poor design, Xfree86 insists on setting up the aperture itself. It
doesn't reset the original settings at a VC switch once it runs. You should
not start X for the first time after a boot as long as an svgalib application
is running. This will result in pre X values being restored at a VC switch by
svgalib. If you use svgalib and XF86_Mach32 together, run X first or at least
do not start it while any svgalib appl. is still running. After X was started
once you can use svgalib and X in all combinations w/o any problems. Xfree
uses whatever address is given in the
MEM_CFG Mach32 register for a 4MB
aperture, even if the aperture is not already enabled and the value in this
register is pointless garbage. This is IMHO a dangerous bug as some systems
may work only with a 1MB aperture.
However, usage of a correct EEPROM circumvents any such problems. If you cannot
use that, use
mach32info (6) to find the address in
MEM_CFG.
Then,
if it is a sensible setting for your system, enable a 4MB
aperture at that address with
setuplinear. Ensure that no other card or
memory uses the address range you choose.
11. ACCELERATOR SUPPORT AND OTHER WEIRD FEATURES¶
This version now has support for all accelerator functions of svgalib. However
they were intended for use with the cirrus chips. It may happen that at
runtime they find they cannot emulate the function actually requested. Then
you should disable the corresponding blit function (at least for that
application) with the blit config command.
Data transfer between the host and the Mach32 is normally via I/O. This proved
to be pretty slow. If a big enough aperture is available, a simple memory copy
is used instead. This is usually much faster. You can change which method is
used with the blit command. This I/O option affects only
vga_imageblt(3). The other functions are incredible fast.
For type 2 DACS, there is support for 8 bit per color (instead of the normal 6)
in the RGB triple in the color lookup table of the 256 color modes. This can
be enabled by an application, if it supports it. The
testaccel(6) demo
uses it if supported by your hardware. You can use
vga_ext_set(3) to
use it from your programs.
12. RAMDACS¶
Mach32 Ramdacs are specified by a type in range 1 .. 5. This type can be queried
from the Mach32 and then specifies how to set up the ramdac. A list of actual
hardware chips used for each type exists, but is not of much use. The Mach32
will return a type and the ramdac will be completely hardware compatible to
one of the given type.
Type 1 and 4 Dacs need different clock frequencies for high colormodes. For
32K/64K colormodes the frequencies have to be doubled and for 16M colors (type
4 only) they have to be tripled. I followed the ATI scheme and did this
internally. However this means that for 32K/64K you can use only clocks for
which the doubled frequencies can be generated as well.
This is no hard restriction as the 16 clocks of the Mach32 can be divided by 2.
Thus if you setup some mode yourself try to use one of the divided clocks in
your timings and I can use the undivided clocks internally.
It is a real restriction for 16M colors. ATI itself only supports 25MHz
(640x480) here by use of a 75MHz clock. Depending on your clock chip other
values may be usable as well. Even the doubled/tripled clocks have to be less
than the magic 80 MHz. However the driver does all this itself. It may just
happen that some of the predefined or one of your handmade mode-timings can't
be used because the clock that is used cannot be doubled/tripled. Even though
there is already some tolerance in the driver you may fix that by slightly
changing the clock values that you set with the
clocks command. But
note that this will as well affect the ability of the driver to calculate
video timings and thus it ability to check the monitor and DAC safety
restrictions.
In addition (in complete contrast to my original ATI docs) RAMDAC 4 does not
support RGB with blue byte first but only with red first. This required
special handling and me adding a bunch of functions to all modules of svgalib
and vgagl. The added functions are of lower performance than the usual
functions. However most data has to be completely mangled, so I doubt that it
can be done much faster. Sorry.
Of course, I might have forgotten to port some parts or even confused things.
About bugs in the gl and drawing libs, please ask Harm. But then, I'm able to
emulate a BGR ramdac on my card, so I should even be able to reproduce your
problems.
Recently I hear often about type 6 ramdacs in non ATI Mach32 cards. There exists
no info about these dacs, thus I cannot support them. The driver assumes
unknown DACs can stand up to 80MHz in 256 color clut modes and does not touch
the ramdac (that is, assumes it is in the 256 color mode already)
To get rid of the warning message you can use the
- ramdac n
- configuration command. It allows to explicitly set the type
of the dac to n (in range 0 to 5). Ramdac 3 is
the most dumbest ramdac possible, s.t. you can use it without any fear for
your hardware.
- ramdac dumb
- is equivalent to ramdac 3.
- ramdac auto
- switches back to the default autodetection.
13. MEANING OF THE DETECTION MESSAGE FROM SVGALIB¶
Some programs (which do not switch it off) will show a
Using Mach32 version (sizeM at adrM
(how), memK mem, DAC dactype)
line. This will show up in
testlinear(6) etc but will probably scroll
away when you use
vgatest(6). In this line:
- version
- is the version of the driver (as of my counting, not the
svgalib version).
- size
- is the size of the memory aperture. It can be 1 or
4 (1 will lead to not using the linear aperture if your card
has more than 1MB memory, however applications can still use the 1MB
aperture and page the video memory through it in 1MB steps). size
can also be no if no aperture is setup at all.
- adr
- is the base address of the aperture in MB.
- how
- is autodetect if the aperture was setup this way
already when the program started. It is setup when the the setting
was enforced with a setuplinear configuration command. It is
EEPROM when no aperture was detected, but parameters to set it up
were found in the EEPROM.
- mem
- is the amount of memory the card reported to have.
- dactype
- is the type of the DAC that was detected.
If a special ramdac type was set with the ramdac command a
(set) will be displayed after dactype.
If
mem,
dactype and/or the chipset were enforced with
chipset
from the configuration file or
vga_setchipsetandfeatures(3) a
forced will be appended to the line.
14. CONCLUSIONS¶
A final word: I have an ATI ULTRA PRO/2MB/EISA with a Type 2 DAC. My monitor is
an EIZO F550i-M. Everything I tried works on it like a charm. However, I
couldn't try it with other machines myself and esp. other DAC's. Fortunately
the Type 2 DAC is the worst to code. So I will probably have gotten the other
DAC's right. But please be warned!
I did my very best to code the driver to support the other DAC's by just reading
the docs.
But i can't give any definitive guarantee for it to work
or even not damaging your hardware. So please be careful!
Note that you will have to set the environment variable
SVGALIB_MACH32 to
ILLTRYIT if your DAC is not type 0, 2, 3 or 4. This will of course
change if no one with a DAC equal to 1 or 5 has serious problems. If you have
a different DAC, making patches to support your card will be much more helpful
instead of just complaining. If you have a different DAC that works well tell
me as well such that I can remove the need for SVGALIB_MACH32 in the next
release. Still, even now, after years, I got no reports of a Mach32 card with
a type 1 or 5 ramdac. Go figure.
Thank you for your audience and wishes you will enjoy this driver,
Michael.
FILES¶
/etc/vga/libvga.config
/etc/vga/mach32.eeprom
SEE ALSO¶
svgalib(7),
libvga.config(5),
mach32info(6).
AUTHOR¶
The Mach32 driver and this documentation was written by Michael Weller
<eowmob@exp-math.uni-essen.de>.