A Radeon X1550 has been generously donated, and arrived today. One minor modification to the driver was required in order to get it to use the card. The HIS Radeon X1550 PCI card has the Hot-Plug Detect (HPD) pins swapped between the connectors. Thus, connecting a monitor (or a VGA to DVI adaptor) to the DVI port registers as a monitor connected to the  VGA port (which it thinks is a DVI port). Moreover, the VGA connector is not supposed to have an HPD pin, since this is a DVI feature. Thus, the driver skipped checking the VGA output for a connected monitor and decided that there was nothing to output an image to. A quick fix, eliminated this problem, resulting in a working card.

The 256 colour (i.e., 8-bit) and 16-bit modes are now operational. In fact, they were working yesterday, but I forgot to mention it due to suspected issues with the graphics memory of the Radeon X1300 card that I have. There is no screen shot with this log entry because the difference between the 256 colour mode and truecolour is hard to notice from a photo. Obtaining a working 256 colour mode simply required writing the colour-map to the graphics card's Look Up Table (LUT). The 16-bit mode was already operational, but the Radeon X1300 hardware issues made it appear as though there was a problem (vertical lines were visible in parts of the display).

Here is a quick screen shot to show that the Picasso96 driver can also open screens on a Radeon HD 2400 pro. This is fairly unremarkable since mode setting on the 2400 pro was demonstrated previously, albeit by a test program instead of a proper driver. However, I have read at least one comment online that suggests that the Picasso96 driver can ony handle R5xx series cards. Therefore, here is proof that the same driver, without modification, can also drive an R6xx series card.

It looks like my Radeon X1300 graphics card has faulty video memory. 8-bit and 16-bit screens have vertical lines in them, eight and four pixels apart, respectively. After performing a memory test, bit five of every of every eighth byte remains set to one, regardless of what is written. This defect is invisible in 32-bit truecolour mode since that bit is part of the invisible alpha channel. The Visiontek Radeon X1300 that I have has a 64-bit memory bus, i.e., eight bytes wide. Thus, this behaviour is consistent with a single data line being faulty; possibly a bad solder joint or something similar. Unfortunately the memory chips are fine-pitch ball grid arrays, so it is not something that I could fix. An x-ray machine would be required to even check if a solder joint was bad.

Today (13 October 2008) I have successfully opened a screen using the Picasso96 RadeonHD driver. There are still a few issues to sort out. For example, the colour look-up tables are not set, resulting in some funny colours. Also, the 16-bit screen-modes do not display correctly. Nevertheless, this is an important milestone. It is now possible to open screens (including workbench) via this driver. Being just a frame-buffer driver, there is no hardware acceleration for graphics, meaning that all rendering must be performed by the CPU. As a result, dragging windows can be sluggish. Interestingly, compositing does work, but switching it off speeds up the system.

The skeleton RadeonHD.chip driver has now progressed enough that the screen mode preferences editor now lists screen modes for the Radeon HD card. This is another small but important step toward a working driver.  At present, these functions simply output debug information in order to let me know that they are being called. Thus, one cannot actually use any of these screen modes since the functions that perform that task have not yet been implemented.Nevertheless, this is good progress.

Since receiving the developer material for Picasso96, I have built a skeleton driver: RadeonHD.chip. At present this skeleton does absolutely nothing; it fails on initialization of the graphics card. However, the system will correctly identify a Radeon HD graphics card and load the RadeonHD.chip driver. This is, thus, a small baby step toward a basic frame-buffer driver (which will be the first milestone). 

I now have access to all the required developer documentation and source-code for developing a Picasso96 driver. There is quite a volume of information to wade through. The goal now is to work toward a simple framebuffer driver; no hardware acceleration, just a framebuffer.