10 Most Recently Updated Pages

RadeonHD Driver Hardware Compatibility

Sun, 20 Dec 2009 23:17:16 -0600

This page lists all hardware that has been tested with the RadeonHD.chip driver. A list of places to buy these cards can be found here.

DISCLAIMER: While every effort will be made to keep these lists accurate and up to date, it depends on the testing and feedback of others. As such, I do not guarantee the completeness or accuracy.

Graphics Cards

The "driver version" column lists the most recent driver version that a particular card was tested with.

Graphics Card	Chipset	Driver Version	Status	Notes
VisionTek Radeon X1300 256MB PCI	RV515	0.3	Working	Was last tested when it was a framebuffer only driver (the card that I used had a hardware defect, so I don't have it any more)
HIS Radeon X1550 256 MB PCI	RV516	0.7	Working
Club3D Radeon HD2400 PRO PCI 256MB low profile	RV610	0.7	Working	No hardware acceleration yet
Diamond Radeon HD 2400 Pro PCI, SB Edition (256 MB)	RV610	0.5	Working
HIS Radeon HD 4350 PCI (512 MB)	RV710	0.7	Partial	VGA output only

Motherboards

The "driver version" column lists the most recent driver version that a particular card was tested with.

Motherboard	Driver Version	Status	Notes
AmigaOne SE	0.5	Working	Use Amiga OS 4.1 update 1 or higher for stability (previous versions had stability issues when Radeon HD cards were plugged in whether in use or not)
AmigaOne XE (Unfixed)	0.7	Working	33 MHz slot only; UBoot does not detect the card properly when plugged into the 66 MHz slot
AmigaOne XE (with DMA fix)	0.7	Partial	USB must be disabled or the machine will freeze. The DMA fix appears to cause a hard lockup when large amounts of data (e.g., bitmaps) are sent over the bus and USB is active (possibly a conflict with USB DMA transfers)
Micro AmigaOne	N/A	Untested	The Micro AmigaOne has the AmigaOne-XE's DMA fix built in, so it will probably behave in the same manner as fixed AmigaOne-XE motherboards
SAM 440ep	N/A	Untested
SAM 440-flex	0.7	Working
Pegasos 2	N/A	Failed	OpenFirmware fails to detect the card, so the driver cannot even be tested
AmigaOne X1000	N/A	Untested

Submitting Updates

At present only beta testers can update this page.

make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3

Fri, 05 Feb 2010 15:15:08 -0600

I was using GCC on Windows recently for an embedded project, and discovered that I couldn't use "make" to build my projects. It always failed with the cryptic error:

make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)

Searches on the internet suggested that there is a bug in "make" that causes it to crash when the path to the GCC executables contain "(" or ")". With a 64-bit version of windows (such as the one that I'm using), GCC is installed to "C:\Program Files (X86)\" by default. So, I reinstalled it to a directory without spaces or parentheses, and it still failed. At this point further searches proved futile.

The problem lies with the way that the PATH environment variable works. When "make" (or any other application) searches for a command in PATH, it starts by looking at the first directory that is listed in the PATH environment variable for that command. If it does not find it there, then it moves on to the next directory in the list, and so on, until it either finds the command that it is looking for, or runs out of directories to search. This means that any directory in the PATH with parentheses that occurs before the directory containing the GCC executables will cause "make" to fail. By default, the installer will add the directory to the end of the list. Thus, shifting the directory containing the GCC executables to the start of the list, solved the problem.

Working Around the Make Bug

This particular bug in the "make" tool can be worked around by doing the following:

In the Windows control panel, open "System," and click on the advanced tab,
Click on the "environment variables" button,

In "System variables" edit the "Path" variable; move the directory containing the GCC executables to the front of the path list,

Click "OK," and then "OK" again (in the main window of "System Properties"), and
Reboot the machine to make sure that the updated path variable is used.

MiniGL

Thu, 05 Jun 2008 22:01:32 -0500

A gears demo

MiniGL is not actually one of my projects, but I have spent a significant amount of time and effort on MiniGL, so it deserves a mention. MiniGL for Amiga OS was originally developed by Hans-Jörg Frieden and Thomas Frieden for Hyperion-Entertainment's game ports to the Amiga (e.g., Freespace, shogo). As such, it was designed to support the subset of the OpenGL 1.3 API that was used by these games - hence the "mini." The goal was also to make it as fast and efficient as possible, particularly as Motorola's 68K series processors were already lagging behind in processing power. 3D hardware acceleration was performed via the Warp3D library.

Want to learn how to program in OpenGL? Click here.

I first got involved in late 2007. By this point MiniGL had been open-source for some time, and various people had asked if it were possible to add display-lists. The answer was, "of course, the source-code is open, feel free to add it." The Friedens were hard at work on Amiga OS 4.0, and thus did not have the time required to add additional features. No one else took on the task of adding display-lists, so I did it. Two to three weeks later, MiniGL version 1.5 was released, containing display-lists and various bug-fixes.

After the MiniGL 1.5 update, I asked people to email me if there were additional OpenGL features that they required. At this point a few others who had been working on MiniGL related projects came out of the wood-work and a small team (including the Friedens) started work on expanding the feature-set. Thus, MiniGL 2.x was born.

MiniGL 2.x

A NURBS surface using the new evaluators

MiniGL 2.x constitues a major update to MiniGL, with a significant expansion of its feature set. Essentially, MiniGL is no longer so mini. The new features and changes are:

Added support for evaluators (glMap*, glEvalCoord*, glMapGrid*, glEvalMesh*, glEvalPoint*)
Added selection support (glListBase(), glNewList(), glInitNames(), glLoadName(), glPushName(), glPopName(), glSelectBuffer(), and glRenderMode())
Added gluPickMatrix()
Added gluProject()/gluUnProject()
Added glGetDoublev()
Added glIsTexture()
Added glGetTexEnviv()
Added glGetLight*() functions
Added GL_PROXY_TEXTURE support
Fixed some rendering bugs (e.g., a bug causing incorrect lighting for clipped primitives)
Added const qualifiers to improve OpenGL compliance
Mglut.library now has glutKeyboardUpFunc(), glutSpecialUpFunc(), and glutIgnoreKeyRepeat()
Added text functions to Mglut.library (glutBitmap*(), glutStroke*())
Added glPushClientAttrib()/glPopClientAttrib()
Added glDrawPixels()
Added game mode to mglut.library
Added glutDeviceGet(), glutLayerGet(), glutGetModifiers(), glutSetOptions() and expanded the number of attributes supported by glutGet()
Added glut geometry rendering functions including the teapot functions
Added glut overlay function stubs for completeness (overlay is not actually supported)
Added glGetMaterial*()
Added the complete set of glNormal*() functions
Added glGetTexImage
Added full set of glPixelStore modes, as well as glPixelTransfer
Added glutTimerFunc(), glutCloseFunc(), glutWMCloseFunc()
Added glutWarpPointer()
Added glutExtensionSupported(), glutIgnoreKeyRepeat(), glutSetKeyRepeat(), glutKeyUp(), glutSpecialUp(), and glutForceJoystickFunc() (note: no joystick support yet)
Added stubs for glutSetColor(), glutGetColor(), and glutCopyColormap() (note: these functions really don't make sense any more but they're in the GLUT spec. Like FreeGLUT, these don't do anything as we're using truecolour modes)
Added glDrawBuffer and cleaned up the whole video code
Added the SGI GLU library into MiniGL. MiniGL now supports all of GLU

A public beta (MiniGL 2.1) was released 4 April 2009. It can be downloaded from os4depot.net. MiniGL 2.2 was released in Amiga OS 4.1 Update 1.

That's Nice, but What Does all this Mean?

If you are asking this question then you are obviously not a 3D graphics software developer. For users, this means more 3D games; more 3D software. All the features listed above are really only important to people who are writing OpenGL based software, or porting existing ones. MiniGL 2.0 provides developers with a more complete implementation of the OpenGL API making it much easier to port existing OpenGL games/applications. It also provides developers of new 3D software with a wider range of functions for generating the effects that they desire.

More screenshots...

MiniGL's Future

MiniGL 2.x will be the end of the line as far as MiniGL is concerned. It is provided as a stop-gap solution until a complete MESA port is available. Eventually it will simply be a stub that maps on to MESA. MESA will provide a complete OpenGL implementation that is up-to-date. However, a full MESA port may take some time. In the interim, MiniGL 2.x provides enough functionality to increase the amount of 3D software that is available for Amiga OS 4.0.

Links

Code templates for getting started with MiniGL (on this website)
Public MiniGL release (v2.1)
The MiniGL project page (for developers wishing to compile the SVN version only). ** Currently Unavailable ** Those who wish to compile the SVN version themselves can checkout the code using subversion with the following command: svn checkout http://www.hyperion-entertainment.biz/svn/MiniGL/trunk MiniGL

Full-Screen GLUT

Fri, 27 Jun 2008 10:36:18 -0500

The same rotating triangle as in previous templates, but full-screen.

Sometimes it is preferable to run a 3D application in its own screen, particularly for games. The first time that I wanted to do this, it took a surprizingly long time to find the documentation required, particularly considering that obtaining full-screen operation requires only 1-2 lines of code. This template has two different methods of opening a full-screen. These can be found in files GLUT-fullscreen.c, and GLUT-fullscreen2.c. The makefile will build both examples.

This template includes a project file for Visual Studio 2008 (i.e., Windows), and a makefile for Amiga OS 4.x+. Users of other systems should be able to modify the makefile for their systems easily.

Learn more about programming in OpenGL. Click here.

GLUT Game-Mode (GLUT-fullscreen.c)

GLUT game-mode opens a screen of specific resolution and properties (e.g., bit-depth). The advange of this method over the other one is that it offers more control over the screen's properties. This advantage is somewhat diminished on Amiga OS, since its concept of screens is different from other operating-systems. More about that later.

Achieving full-screen using the game-mode requires removing the glutCreateWindow() call, and replacing it with two new lines of code. For example:

glutGameModeString("640x480:24");
glutEnterGameMode();

The first line specifies the desired screen properties. GLUT will try to match those. It is possible to suggest a refresh-rate too, but this is currently ignored by MiniGL (the graphics drivers do not give you that option). The second line opens the full-screen window. Leaving GLUT game mode is achieved simply by calling glutLeaveGameMode().

GLUT Full-Screen (GLUT-fullscreen2.c)

The other method of switching to full-screen is simply to call glutFullScreen() after opening the window. Exiting full-screen and returning to a window view can be achieved by calling glutReshape().

So why have two separate methods of switching to full-screen? Well, the specification for glutFullScreen() simply states that the image should cover the complete screen. In many systems, this means enlarging the window to cover the whole screen, and making it borderless. GLUT game-mode, on the other hand, allows specifying the resolution of the display. The reason for this implementation probably stems from the fact that most systems have no concept of multiple screens like the Amiga does. MiniGL on Amiga OS 4 opens a separate screen in both cases. For glutFullScreen(), it tries to choose the screen-mode that most closely matches the original window.

Download

GLUT full-screen templates

NOTE: For Amiga OS users/developers, this template requires features that are only available in MiniGL 2.0 or better.

Frame-Rate Independent Animation using GLUT

Wed, 18 Jun 2008 21:56:09 -0500

A triangle that rotates at constant speed regardless of CPU load.

You may have experienced old computer games running so blazingly fast that they are unplayable, when run on a newer, faster, machine. This is due to the game relying on the timing of the specific machine for which it was designed. The basic GLUT template has the same problem. Try resizing the window. Make it small; notice how the triangle now spins at a ridiculously fast rate? Now make the window as big as the screen; the triangle slows down? This is because the different window sizes take different amounts of time to draw, resulting in different timing depending on the window size. The template simply uses 100% of the available CPU time to render and animate the triangle, with no regard to timing. This becomes even more annoying when another CPU intensive task is involved; the other task (or tasks) will cause the GLUT application timing to vary, resulting in stuttering animation. Thus, software such as games must be designed to compensate for variable timing. Methods for achieving this using GLUT are given below.

This template includes a project file for Visual Studio 2008 (i.e., Windows), and a makefile for Amiga OS 4.x+. Users of other systems should be able to modify the makefile for their systems easily.

Learn more about programming in OpenGL. Click here.

Frame-Rate Limited Animation

The easiest method of obtaining constant-speed animation, is to limit the frame-rate via the use of a timer. GLUT offers a hook that calls a specified function after a desired delay. Thus, this can be achieved simply by changing the animate() function in the basic template to:

void animate(int value)
{ 
    glutTimerFunc(TIMERMSECS, animate, 0);
    ... the rest of the animate code ...

Here, TIMERMSECS is the delay in milliseconds between calls to animate. The new parameter "value" is ignored, but could be used for a single call-back function to differentiate between different timer events. The only other change left is to replace the following in the main() function:

glutIdleFunc(animate);

with this:

glutTimerFunc(TIMERMSECS, animate, 0);

This call starts the timer. This is all that is required for timer-based animation.

If you have a CPU monitoring utility, you will also note that this template uses a fraction of the CPU power of the other. This is because it only performs the processing required to render the animation at the desired speed. I recommend using a timer instead of an idle function (when in windowed mode) simply because there is no point in rendering 100+ fps on a display with a refresh rate of 60-75 Hz.

The link to the template source code can be found in the downloads section below.

Achieving Frame-Rate Independent Animation

The timer based template above does not completely solve the animation speed problem. It effectively sets a constant frame-rate. However, if one were to run other programs simultaneously with the timer-based GLUT template, the animation will still stutter. Likewise, if processing time for any operation within a GLUT application takes longer than the timer period, the animation speed would still change. This is because the timing is not guaranteed; the computer will take "best-efforts" to meet the timing, but overloading the CPU will make this impossible. What is required is a mechanism for measuring elapsed time (and/or the time since the last frame), and responding appropriately.

Fortunately, GLUT offers an easy way to obtain the elapsed time since the application was started via the following line of code:

int time = glutGet(GLUT_ELAPSED_TIME);

The animate template provides two variables in the animate method that can be used for animation timing. ElapsedTime gives the number of milliseconds since the first timer tick; timeSincePrevFrame is the time in milliseconds since the previous frame occurred. You may notice that the template has a startTime variable that is initialised with a glutGet(GLUT_ELAPSED_TIME); call. This is just me being cautious. It also offers the ability to reset the timer if you so wish (e.g., when a new game is started).

The template's default code rotates a triangle at constant angular velocity. This is achieved simply by multiplying the elapsed time with a constant, i.e.,:

rot = ROTRATE / 1000 *  elapsedTime;

Try running this template simultaneously with the timer-based template, and then run other applications in order to bring CPU usage to 100%. Whilst the frame rate may drop and stutter, this template will keep the triangle rotating at constant speed, whereas the timer-based template will not. This shows frame-rate independent animation in action.

For more complicated animations, or game engines, it may be necessary to calculate the average frame-rate too. Often a game/animation engine will take varying lengths of time to perform all computations depending on factors such as the number of collisions, etc. In this case, one wishes to estimate what time it will be when the image is redrawn, not what time it is at the start of processing. However, the basic principles remain the same.

Downloads

NOTE: For Amiga OS users this template requires features that are only available in MiniGL 2.0 or better.

Silverstripe/PHP Projects

Thu, 19 Mar 2009 21:57:28 -0500

This section is devoted to projects related to Silverstripe, and PHP/web-programming in general. These projects were often started in order to extend this site's functionality. Silverstripe is the Content Management System (CMS) that runs this website; it is written in PHP, a powerful scripting language that is well suited to web-development.

Links will be added to the menu on the left as projects are ready.

R5xx Compositing is Done

Hans de Ruiter — Mon, 28 Dec 2009 00:00:00 -0600

I am pleased to announce that compositing for R5xx based cards (Radeon X1000 series) is now done. This marks a major milestone in the development of the RadeonHD.chip driver. Namely, full 2D graphics acceleration is implemented for an entire series of graphics cards. The screenshot below shows Workbench with compositing effects enabled being displayed by a Radeon X1550 graphics card. As you can see, the errors that were present in the previous screenshot are now gone (the development log entry containing the previous screenshot is included in the image below for comparison).

Implementing compositing proved to be a major undertaking. As I said earlier, Amiga OS 4.x's compositing contains a powerful array of features, all of which must be implemented correctly by the driver. Added to this, a slight eror in the data sent to the graphics card could cause a freeze, requiring a hard reset. This makes debugging rather time consuming. Needless to say, I am glad that it is done, and working correctly.

With full 2D acceleration implemented for R5xx chipsets, it is now time to turn my attention to hardware accelerated blitter for R6xx/R7xx based cards.

RadeonHD Driver

Sat, 28 Jun 2008 22:50:05 -0500

The goal of this project is to write an Amiga OS 4.x graphics driver for R5xx and higher graphics cards. One of the motivations for this is that, my computer vision research extensively uses shaders that are present in modern GPUs. None of the existing supported graphics cards for Amiga OS 4.x support shaders. Shaders are rapidly becoming an essential component for running newer games. This project, however, focuses on the 2D driver, not 3D. Without a 2D driver, there will be no 3D driver. Hence, this is the first important step toward supporting more modern graphics cards. Once the 2D driver is in place, and a full MESA port is underway, a 3D OpenGL driver can be considered.

IMPORTANT: Developing a driver will take a considerable amount of time. This page will be updated as and when progress occurs. For those wishing to follow progress, keep an eye on the development log.

Current Project Status

The following features/functionality are operational:

Framebuffer,
VGA and DVI output for all cards (VGA only for Radeon HD 4000 series),
Full 2D acceleration for R5xx chipsets (Radeon X1000 series), including compositing, and
Hardware mouse pointer.

The Development Log

Follow the progress of this project in the RadeonHD Development Log.

Tested Cards

Card Name	Chipset	Status
Visiontek Radeon X1300 PCI	RV515	Framebuffer works in 32-bit (there are hardware issues)
HIS Radeon X1550 PCI	RV505	Framebuffer fully operational, both VGA and DVI output tested and working. 2D blitter hardware acceleration working.
Diamond Radeon HD 2400 Pro PCI	RV610	Framebuffer fully operational
HIS Radeon 4350 PCI	RV710	Framebuffer fully operational

The Screen Mode Preferences test screen as displayed by a Radeon X1300.

Workbench being displayed by a Radeon X1300 graphics card.

Month in Review - January 2009

Hans de Ruiter — Sun, 01 Feb 2009 00:00:00 -0600

This month has seen a move to a newer, faster server. Just to give an idea of how much difference this makes, Google's search-bot took an average of 2.2 seconds to download a page on the old server, whereas a page download now takes about 0.5 seconds. That's approximately 4 times faster.

I have finally received my Amigaone, which I had sent to myself from Canada to New Zealand back in November. As a result, the RadeonHD driver for Amiga OS 4.x is progressing again.

There have also been a number of more minor changes. Drop-down menus have been added (plus a few other layout changes) in order to improve this website's usability. Akismet was replaced with math based spam protection. As usual, more content has also been added.

The statistics for the last month:

Attribute	Value
Number of Pages	144
Size of site	80.0 MiB (HELM provides the total)
Number of Visits	1247 (Google Analytics)
Number of unique visitors	972 (Google Analytics)
Total page views	2314 (Google Analytics)
Bandwidth	912.2 MiB (server control panel)
Adsense Revenue	$2.49

One important thing to note is that Google Analytics only sees page-views on the public part of the site, whereas AWStats and Webalizer also log the accesses by me to the CMS pages that are used to maintain and update the sit.

A snap-shot of visitor locations on 1 February 2009.

Month in Review - February 2009

Hans de Ruiter — Sun, 01 Mar 2009 00:00:00 -0600

This month has seen further development of the RadeonHD driver, and a few more OpenGL templates. Fewer additions to this website occurred because I have been spending more time working on various projects. Unlike other websites, adding pages to this site requires extra work to develop the software/technology upon which the page is based (except for random musings in this blog). This results in fewer updates, but also less rambling.

The Google AdSense revenue spiked this month. However, this is probably an outlier because the increase is disproportionate to the increase in page views.

The statistics for the last month:

Attribute	Value
Number of Pages	153
Size of site	74.4 MiB (HELM provides the total)
Number of Visits	1456 (Google Analytics)
Number of unique visitors	1069 (Google Analytics)
Total page views	3358 (Google Analytics)
Bandwidth	1.07 GiB (server control panel)
Adsense Revenue	$10.53

A snap-shot of visitor locations on 1 March 2009.