Matrox G100/G200/G400/G450/G550 driver for (open)BeOS



NewsItems:


25 November 2004: Today I'm finally releasing a new version of the Matrox driver as V0.20. It has a few fixes that needed to be done for a long time now, like returning valid information about the hardware specs and having correctly working overlay in virtualscreens.
I did not add AGP support yet, as none of the Matrox cards supported has the AGP 'FastWrites' feature built-in, so no gain in speed is possible here now anyway.

Get the driver from the download page and have fun, as usual.. :-)


7 June 2004: Just a housekeeping message today: I've deleted my Email adress rag.cornelissen@inter.nl.net due to large amounts of viruses and related spam coming in each day (3000+ !). You can find another Email adress on this site to use instead. Please don't post this adress elsewhere anymore as this will destroy useability of that adress as well.

Thanks for your cooperation..

8 February 2004: We have a new Matrox driver release today: version 0.16 is ready for download. This is a bug-fix release more or less, as a nasty bug has been fixed for G450/G550 cards. It turned out that I introduced an error with primary head DPMS in V0.15, which could make you stare at a screen that got shut-off after boot!

The second update for this version is the addition of extra high-res modes in the modelist (done by Andrew Bachmann). Those modes will appear in Dualhead Setup if your card supports them. Note please that they can only be used in singlehead mode due to hardware restrictions in the cards.

So, I suggest everyone updates to this new version: it's the version you want. Seriously ;-)


6 January 2004: Happy new Year! A new year, a new beginning I guess ;-)

From today onward, you can find the latest sources for the (open)BeOS nVidia, Matrox and NeoMagic drivers in openBeOS CVS: they are all 100% up-to-date now. Also you are now able to download the latest binaries for those drivers from the new OpenBeOS Build Factory as Jam packages. While I still need to update/include up-to-date documentation for those packages, the drivers are up-to-date already after new builds. Be aware that those versions are not real releases, so they might be less stable than you are used to. I'll do my best to keep them rock-solid though...

The fixes page on this site will remain up-to-date as well, other documentation might change later on to bring it up to speed with the new way of developing the drivers. Real releases for the drivers will of course also keep happening. For the use of features like TVout and dualhead you still need to use Mark Watson's DualheadSetup and/or tools from this site for now. Have fun...


18 December 2003: Today I am releasing version 0.15 of the Matrox driver. See the fixes page for details about it. Get it from the download page, and make sure you download dualheadSetup from BeBits if you want to use dualhead and/or Desktop TVout modes. For VCD and DVD Video TVout modes make sure you download a simple command-line tool called VideoScreen for now from the tools page on this site. For driver V0.15 and up you need the updated V6 version of this tool. Look for information on using it correctly here.

Have fun, and let me know if you run into trouble!


6 December 2003: More good news indeed. We now have the VCD and DVD TVout playback modes for G400 upto and including G550 cards. I was indeed able to get them working nicely on G400 also now, although overscanning in NTSC VCD mode is very minimal. It seems the G400 MAVEN design has restrictions which are just a bit too narrow to support all important modes exactly as they are supposed to be. Note please that you will need the (updated) tool 'VideoScreen V6' for setting the VCD/DVD modes for now (see the techinfo and tools page).

28 November 2003: I have some splendid news for G400 owners that like using TVout to see their Desktop on TV: All supported Desktop modes are working just as they should now! So no more distortions in some modes; and correct aspect, size and positioning of the picture on TV. The refreshrate dependancies are also gone now. I think I'll push my luck a bit and see if I can get the DVD and VCD modes going as well. Stay tuned...

11 November 2003: After being very busy on both the NeoMagic driver and the nVidia driver (sorry about that ;-) I'll update the Matrox driver once again. Because those other drivers are based on the 0.14 Matrox driver I fixed several bugs in those 'new' drivers that also exist in the Matrox driver. So it's only logical to update the Matrox driver at this point to fix those bugs here as well.

Two very important bugs that came up directly in the Matrox driver because someone gave me a very detailed bugreport about it, are a WaitForRetrace() delay bug and a bug in cloning the accelerant. This clone bug (actually copied from the Be R4 graphics driver kit) prevented BWindowScreen from cloning the accelerant and with that acceleration for applications.

So, stay tuned for the 0.15 release. For more details about it, have a look at the 'fixes' page on this site.


15 June 2003: Well, it's been a while since I 'reported' here. Anyway: I've completed the (60 pages!) Dutch 'BeOS videodriver howto' document. It has become something a bit different from what I was planning, but it should be helpfull for those people outthere that can read Dutch. Make sure you checkout the roadmap for creating a graphics driver I've included :-) Now it would be nice if someone could translate this document to English so more people could use it. Anyone? I will not do this myself for a while, I'm afraid I've had enough of 'documenting' for now.

Get the Word document here: a link to this file is also added in the 'downloads' page. Feel free to use it anyway you want ;-)

Now the videodriver document is completed, I am working some more on the NeoMagic driver before I'll resume work on the Matrox driver again. The NeoMagic driver has a webpage like this one. See the links on the left of your screen. The first 'alpha' version can already be downloaded there, and hardware overlay is on the way...

11 May 2003: Here's a small status update: in three parts :-)

While I have not yet been coding on the driver again, I am working on a document that describes my experience and knowledge about writing videodrivers for BeOS. This is a 'project' I have to do for the school I am attending: it's the last thing I need to do to complete this study. While it will be in Dutch at first, I will translate it to English later on so I can publish it in both languages then. I have about a month left to complete the Dutch version, and it's taking up much of my time...

One other thing I am working on, is a document that describes the extension of the driverinterface which I need for the Matrox driver. I will work a bit on this before I continue on the driver: next up is seperated modesetup for both heads, so I need to do some more planning. Some of the stuff for this will also be used in the project mentioned above.

There's one more thing I am spending a bit of time on currently: I am writing a Neomagic videodriver for BeOS, which I will release as another (open)BeOS driver. For this driver I am gathering cardspecs from the linux Xfree86 driver, so I can create my own style driver with this. If you look at it later on, you'll definately recognize the Matrox driver design style in it ;-) Anyway: The things I learn from looking at yet another brand of videocards, and from interpreting the Linux code, will be used for the project I am doing for school also.

So, all in all, I am working hard on some document that describes my experience and knowledge about writing videodrivers for BeOS you could say. After that, I'll continue coding on the driver(s). So stay tuned for more stuff to come.. And don't worry: the Neomagic driver will be up and running in 'no time'. After all, much of the code can be copied from the Matrox driver.


21 April 2003: Driver 0.14 released!
And here's the second bit of news for today. (Make sure you read the first item below also ;-) Get the latest driver from the download page as usual, and see if you'll need some extra testapp(s) for certain goals... Have a look at the 'fixes' page for details on improvements for this driverversion.
Let me know if you run into trouble. Have fun!


21 April 2003: Well, the story started in the previous 'newsitem' goes on a bit further you might say. It turns out that on system boot, BeOS only asks the driver for the supported modes via the GET_MODE_LIST hook. Calling Proposemode is done a lot of times, but this is just internally in the driver as part of the initialisation process. Calling GET_MODE_LIST just returns the modelist generated by the driver itself earlier this way...

I was correct on the 'system' only partly listening to Proposemode on boot by the way: it's the driver itself that does it though, not the app_server. This is prescribed in the R4 Graphics driver kit everyone is referring to (I suppose). Anyway, I modified that behaviour: the Graphics driver kit is (also) not always 100% OK of course. Now the Matrox driver only exports videomodes that are really supported by the driver on specific hardware.

More generally speaking about the modelist:
A driver should export at least one mode for a certain resolution/colordepth if it supports that resolution/colordepth. If you don't export at least one such mode, BeOS will 'grey out' the mode's resolution/colordepth in the Screen Preferences Panel.
I have the feeling that if you export more than one mode for a specific resolution/colordepth combination (which will be for different refreshrates then!), the Prefs panel will 'calculate' intermediate modes if you change refreshrate for that combination in this Prefs panel. Different modes per resolution/colordepth combination have different refreshrates, but can also have different sync pulses lengths and positioning.

As a last note on the subject I want to say it turned out to be very handy indeed to have my own testing 'applications' for non-standard resolutions (vidscreen), BWindowsScreen (windowscreen), and virtual desktops (virtualscreen). If you want to use them yourself or learn something about 'tricks', get them from the techinfo and tools page. Sources with informational comments are included... I have to say to you that these tools permitted me to find and solve a lot of bugs! (So test the apps on driver V0.14. On older versions you'll be less happy with the results ;-)


4 April 2003 (updated twice): Hi there! OK, OK, so I gave hints that the next driverversion will be released within one week. That's a promiss I won't be able to keep completely I fear. But look on the bright side: its getting better and better while I keep working on it ;-) Anyway, let me explain what the delay is about:

Short version:
BWindowScreen support improvements.

Longer (rather technical) story: (ehh: sorry about that, but I just could not resist for once!)
Because I like to make things 'foolproof', I was working on making sure that the driver limits the user to the constraints imposed by all seven supported cards (I am counting both Millenium cards also now, though support is preliminary). This turns out to be a bit tricky, and I stumbled upon a BeOS bug in the process.


First, the description of what I am doing with BWindowScreen support, or rather: virtual_screen support.
Because the cards acceleration engine has tighther contraints than it's CRTC part (which is the part that sends the signals to your monitor and gets info from the cardRAM), support was limited to the constraints of this acceleration engine (with some faults in it BTW).
Currently I am increasing support by letting the code first check for the acceleration engine contraints, and, if you specify a mode beyond that, checking for the CRTC constraints during a SetMode or ProposeMode command. In the latter (CRTC) case the driver will not export the 2D acceleration hooks on the mode you are setting, so you can safely use the mode.
If such an 'extended' mode is used for displaying the desktop via BScreen BTW (so it's not used within the derived class BWindowScreen), you will notice 2D acceleration to vanish, but the card keeps displaying your Desktop correctly.

Here are the approximate maximum sizes supported in V0.14, assuming you have the (onboard) RAM to cope:
Note please that with unaccelerated modes both coordinates at max take too much RAM, but you can take your favorite layout at least.

I'll publish more exact figures later on. Suffice it to say, you could create games with a large maze directly in the videocards RAM with this: you could create scrolling modes, panning modes or modes combining both. Also, you could setup, say three 'buffers' that you use for displaying some video while using a technique called 'page flipping' to switch between them. No Bitmap copying required ;-)
One thing more: BWindowScreen grants you access to the accelerant's hooks. This means you could use the acceleration engine if you wanted too. You can also check if you are actually having an accelerated mode or not this way.
For some reason, my thoughts go back to my Atari 8-bit days, in which I played 'BoulderDash' numerous times for example....


OK, here's the second thing I am busy on: there's a 'bug' in BWindowScreen (somewhere). At least on R5.
Normally, you activate BWindowScreen by setting a predefined mode. There's no trouble so far. But say, you want to create some nice maze game, and you want to set a larger virtual size to use for that. The way to go, would preferably be using BWindowScreen.SetFrameBuffer(). If you do that, BWindowScreen will first issue a ProposeMode command to the driver, and if that succeeds, this is followed by the actual SetMode command. Unfortunately we are in trouble most of the time on the system issuing the ProposeMode command...

As far as the driver is concerned, BWindowScreen (or any other 'application') should issue a ProposeMode command to it to see if the requested display_mode (including virtual size) is supported within the limits that have to be specified to this command. In addition, the requested mode should be modified to reflect what the driver can do. Unfortunately, BWindowScreen offers us driverwriters no space at all to vary in because it sets the low and high limits exactly to the proposed mode itself. If any of the items processed by the Proposemode command vary just a tiny little bit, ProposeMode (in the driver) should return B_BAD_VALUE. Let me just say, it's impossible to set a pixelclock (for instance) that precise as you can actually specify it in a display_mode. So, you are bound to vary a bit, and return this B_BAD_VALUE status code (according to Be's R4 Graphicsdriver kit sample driver).
Now, BWindowScreen concludes that it's not possible to set the requested virtual size and returns an error to the application upon this, aborting the process.

Well, here's what BeOS probably should do: It should issue the ProposeMode command with a low and high limit set to accept a certain amount of deviation for every item except the virtual size the application is requesting. This way, the error returned to the user actually means that the requested virtual size is not supported... After all, the rest of the mode was already set earlier!

Additional info:
After looking once again at the sample driver mentioned earlier, and double checking the Matrox driver code, I had to update the info here a bit. I found that the driver's ProposeMode should modify the requested display_mode to what it can actually do, so the calling 'application' gets this info. Setmode on the other hand internally works with a copy of the display_mode. While Setmode will also modify this mode to what it can actually do, it will not relay this info to the calling 'application'.

Apparantly Setmode should try to set a mode unless real hard errors occur. So the application that issues the Setmode command has part of the responsibility to make sure it tries to set a valid mode. It can do so by first issuing Proposemode, because the 'display_mode to be' will be checked to be within the limits the application can specify itself. And it will be modified to something the driver can actually do.
You have the option to disable the range checking part by giving ProposeMode the display_mode to 'check and modify' via the *low, *high and *target mode pointer simultaneously.

It's interesting to see how BeOS works with SetMode and ProposeMode commands for the Screen Preferences application for instance. This application itself never issues a ProposeMode command. Upon system boot however, BeOS does issue a lot of proposemode commands, one for every mode available in the Preferences Panel if you invoke that later on. The driver checks the proposed modes, and returns an error for modes that really can't be set (due to lack of memory for instance). The driver returns B_BAD_VALUE if a mode can be made outside the given limits only. I suspect that these limits again are set to be the requested mode itself, so no deviation is 'permitted' at all.
I think BeOS listens to ProposeMode here partly: It will 'greyout' modes that really can't be set in the preferences Panel, but modes that can only be set outside the 'given limits' will be there just the same. That is, it does not present the modified mode, but the original mode issued at boot time. I say this because I see ProposeMode complaining about the CRTC timing in 1152 x 864 modes for example. The driver's ProposeMode returns updated timing also naturally. Still, ProposeMode (issued from SetMode internally) complains again if you set such a mode later on via the Screen Preferences panel..


I want to make one extra remark here: The pixelclock (so the refresh rate) is implicitly excluded in the ProposeMode checks, because only B_BAD_VALUE is returned on deviations (which BeOS does not look at here). This is perfectly OK, because the Preferences Panel does issue a GetPixelClockLimits command to the driver to see what refreshrate range is supported for the currently set mode. The custom range you can choose from is updated according to this, and also some fixed rates may be greyed out.

Of course I just have to mention also now that the ScreenPreferences Panel contains an error here: it should not ask for the pixelclock limits for the currently active mode, but for the mode being presented in the Panel itself at any given time! (That will look a lot more consistent to the user ;-)


Conclusions:
The driver will now use a workaround to get BWindowScreen working reliably: it adds a certain 'extra' space to vary in for certain items in the ProposeMode command, while it will not return B_BAD_VALUE at all on some other items. Those items will be modified anyway if the driver is requested to actually set the mode via the Setmode command later on, because Setmode also issues ProposeMode internally.



Well, I might be wrong in the exact error there is in the system, but the symptoms are as I described anyway. I am convinced the driver is working reliably, at least as reliably as I can possibly make it with the options and knowledge I have. At the very least you can regard this 'description of a normal working day' as an example of what you might encounter when you are writing (video)drivers. I suppose this explains why sometimes only small visible improvements are made, while you have to do a lot of work to get that 'tiny thing' done..

Interested in doing BWindowScreen experiments? Checkout my testing 'tool' on the 'tech-info' page: version 6 is available now. Make sure you read the comments in the included sourcecode...



Ah, well: back to work! (I've got a driver to release ;-)


1 March 2003: Currently I am working on the Millenium 1/2 support in the driver. TVout for G400-G550 has improved also since 30 January. It's not completed yet though. I have had some requests for DVDmax support, so I am going to have a look at that. Chances are this will be implemented for G450/G550 at first, while on these cards normal Desktop output will be setup later. The Matrox 2D/3D engine has to be setup to do Texture scaling and filtering for that. BTW: If someone has a singlehead G200 (or G100 if this exists?) with TVout let me know: I think I might be able to make that work too...
If there are people outthere with a Millenium1, a Millenium2, or a G100/G200 with TVout please contact me: I could use some betatesters to improve support..

30 January 2003: Yes! We have basic G450/G550 TVout support! It actually works over here... The code is a bit of a mess because of all the testing I had to do, but it's getting there. Here are some details on the preliminary results:
The TV output on G450/G550 works with CRTC2 setup in interlaced mode, while the TVout chip is working in slave mode. This means you will love it for video playback use! The vertically non-scaled output is looking very sharp. I can actually read the tiny words in a terminal window while 1024x480 output is enabled.
The bad news however is that for desktop use this setup is not perfect. An extra buffer needs to be used, and the 2D engine needs to be instructed to downscale the desktop picture onto TV. This is not implemented yet BTW. Of course we will loose some of the sharpness because of this scaling: but that can never be helped, no matter what downscaling setup you have. This does not apply for the videomodes however because they are unscaled and output 1:1...
Anyway; Stay tuned!

10 January 2003: Hi there. I hope you all had a nice change of year...
Anyway: Just reporting in to let you know I have started work on driverversion 0.14. The first thing I am working on now is re-implementing basic TVout functionality, while adding G450/G550 support. I am not certain I will be able to pull this off though, but at least this will clean up the driver code some more. Just stay tuned if you want to know about the results. I know I do...

13 December 2002: Finally; driverversion V0.13 beta2 is ready!
See 'Features', 'Fixes' and 'Todo' for more information, and get it from the download page ('as usual'). Oh, and *please*, if you encounter trouble or if you are satisfied, let me know! Feedback is important...

7 December 2002: More good news!! G550 dualhead support is up and running! G400 and G450 dualhead support will be cleaned up also, and overlay will have a small patch so you can see it on a head in each mode.. (except with TV-out modes: overlay is fixed to the primary head then. Don't panic though: hardware buffer flipping and YUY2 colorspace conversion can be setup for TV: useable in fullscreen mode like in a video consumer node..)

6 December 2002: There is some very good news today: I have completed coldstart support for the entire range of Gxxx cards and completed the 'migration' to the new PINS implementation also.
Coldstart support offers something that's very rare on BeOS (no other card can do this currently as far as I know): you can use the cards as secondary vgacard in your system alongside another vgacard that's used to boot up and display the computer's BIOS, POST and your BeOS Desktop. You could use a Matrox card to display a second desktop as soon as BeOS supports that for instance. Another use would be a videoconsumer node on the Matrox cards, so you can display movies on it while your Desktop is on the primary card. This is something that could work today already if someone created such a node...

Anyway: You can expect the V0.13 beta2 release any time now... Stay tuned!

15 November 2002: Just dropping in to say 'thank you' to Petr Vandrovec!. He is the author of matroxfb, and he is really generous in feeding me with hints and tips every time I bug him with questions. The people working on Linux stuff can really make a big difference for us BeOS souls ;-)
You can take this message as a hint also that work is still progressing well on the driver.. Though sometimes a lot of work has to be done to make some 'small' step..

26 October 2002: Well, work has started on V0.13beta2. The first thing done already is implementing the 'hardware zoom' function in the overlay implementation (would be nice if that was used in VLC for example ;-). I'll keep the 'fixes'/'todo' listing on this site up-to-date..
Also visited BeGeistert #9 a week ago: that turned out to be very interesting. Saw some of the work Thomas Kurschel did on the ATI driver, and also saw some of the CT65555 driver in development by dutch author Mark Hellegers. Thanks to these guys I now have some more 'tricks' up my sleeve :-)

11 October 2002: V0.13 beta1 is here!
See 'Features', 'Fixes' and 'Todo' for more information, and get it from the download page... Oh, and *please*, if you encounter trouble or if you are satisfied, let me know! Feedback is important...

29 September 2002: This weekend turned out to be a 'learn HTML and JAVAscript' session for me. This is why you are seeing a new website here (HTML only). Of course I also wanted to create a better source for information about the (open)BeOS Matrox MGA driver. Hope you like it...
Now, back to actual driver work. Bringing you the newest version soon. See 'Features', 'Fixes' and 'Todo' for more information.

22 September 2002: Hi! I am still working on the driver.. But it's costing more time than I anticipated. Anyway, 'extra features' for the following release will also include: (also thanks to Daniel Teixeira (The BeOSJournal) and Claus Windeler for giving me their (different) G100 cards: thanks guys!)
- G100 hardware cursor support;
- Full G100 card coldstart support, along with improved G200-G550 internal card settings, maybe even also full coldstart support for these cards. This means that the G100 will now be fully functional!
- Oh yes, the switch for 14.318 and 27Mhz timing base will not be nessesary. All cards get this info now from their BIOS :-)

24 August 2002: Just a quick status update on the driver to let you know I am still very hard at work on it. The next version, let's call it V0.13beta1, will contain the following improvements:
- hardware overlay is completed. Colorkeying and sync work like a charm :-). One feature that turns out to be still missing though (thanks Thomas) is sort of a hardware 'zoom' function. I have never seen it used yet, but I will implement this later on.
- BWindowScreen: MoveDisplay has been improved. The driver will successfully report screen movements even if they are smaller than the card can actually do. This is required for scrolling and panning to work as it should.
- G200 support is finally 100% OK (got one over here: thanks Mark ;-). It turns out that G100 and G200 cards exist that use a different timebase than most others. For now mga.settings will contain a switch so you can select manually which one should be used in the calculations (14.31818Mhz or 27.000Mhz: default 27.000Mhz).
- While working on the G200 I finally found out why G200, G450 and G550 cards will sometimes shutdown on some settings. This will be fixed for all cards: all modes will work as expected (resolution, refreshrate).
- G200 and G400 cards have walking, wave-shaped distortions on screen sometimes (G400 with TVout enabled for instance does this a lot). Maybe other cards exhibit this behaviour also. This will be fixed for all cards.
- G100 will have it's own DAC pixelPLL setup. Currently G100 support does not seem completed to me. Got to look a bit more into this yet though. Because I have no G100 to test, and because noone reported in with such a card yet, there's no way to tell if it will be flawless though.. Anyone care to donate such a card? ;-)

Note BTW that the last 4 improvements all come from the same update: the pixelPLL setup contained serious errors for all cards! It will maybe be some weeks before I'll be able to publish the next version here. Stay tuned..

12 July 2002: Got some additional behaviour info on the V0.13 alpha2 driver:
- It's now known that the G100 card does not work OK yet: please stick to the BeOS driver for now if you use such a card;
- It turns out that the FoFt/openBeOS driver contains an error concerning BWindowScreen use. This class is used for pageflipping without overlay, and for scrolling/panning use in some games probably. This means that for instance eXposer will not work properly with this driver for now. Hopefully the driver will be fixed for the next release, which will also contain overlay colorkeying.

4 July 2002: Here's the 'final status' on the V0.13 alpha2 driver. It's working the same as the FoFt V0.12 driver, but with added overlay capability and with preliminary Millenium2 support. So it's working:
- 'perfectly' on all G400's;
- good on G450 and G550 (with 'usebios true' in the mga.settings file!);
- still bad on G200 (for some people it might work though). I suggest sticking with the Be driver for this card for now (though more feedback would be nice..);
- Status on G100 and Millenium2 (these cards have no overlay on the driver BTW) is still unknown. No-one reported back with these cards yet. I suggest sticking with the Be drivers for now, though I would love some feedback here ;-)

2 July 2002:
NOTE PLEASE!!
It looks like there's a configuration 'error' in the openBeOS mga.settings file for use with some cards!
The G450 and G550 powerup routines (at least) have been changed: they decide on a way to go upon a setting in the mga.settings file.
The 'real' powerup has not been fixed, so the driver still has to rely on it's BIOS to do the powerup (at system start time) for these cards. This might (probably) be the case for other cards also, but not for G400 cards: these are known to work OK with the default settings.

*BEFORE* rebooting after the driver install:
In ~/config/settings/kernel/drivers/mga.settings:
Please set the line:
usebios false # if use bios instead builtin card initialisation
to:
usebios true
If you test this *please* let me in on the results, so I can update the 'docs' (so others don't have to 'suffer' as much ;-).
BTW, if you neglect to change the setting, you will get a black screen on restarting and you'll need to hit the systems 'reset' button to start again. Use failsafe videomode on starting BeOS so you can 'undo' the damage...

28 June 2002: The latest version is V0.13 alpha2, I uploaded it today (Get it below!). It has been compiled on BeOS R5.0.3, but it's also reported to work on DANO5.1d0. This version of the driver should work on:

- Matrox Millenium 2 (MGA2164) cards;
- Matrox G100 cards;
- Matrox G200 cards;
- Matrox G400 cards;
- Matrox G450 cards;
- Matrox G550 cards.

Video-overlay is only supported on G200-G550 cards though.

The driver should be stable on all cards AFAIK, but of course, you use it at your own risk..
It is the same as the previously released alpha1 version, only overlay has been extended a lot:
- scaling and filtering are working (fullscreen output!);
- overlay is only exported on cards that support it (so video-output should work again on Millenium2 and G100 cards).

Still missing are:
- colorkeying (takes care of 'vanishing' items on top of the video output, etc);
- synchronous update of all registers (takes care of distortion stripes you may encounter).
Of course these things will be included as soon as possible also. For more detailed info, you should read the textfiles included in the binary download. And stay tuned...


Rudolf.

(Page last updated on November 25, 2004)