The mouse pointer now uses the Radeon card's sprite hardware. The graphics card documentation calls it "Cursor," which matches the X-windows terminology. This was a fairly straightforward task, with just a few issues such as ARGB vs. RGBA pixel formats, and alpha-channel blending modes. 

Days after having my Amigaone back up and running the RadeonHD driver can now drive monitors via DVI.  Last night, a 1920x1080 @ 60 Hz screen was successfully opened by the driver (see the photo below).  This test was performed with an HIS Radeon X1550 PCI card (RV505 chipset). DVI, or Digital Visual Interface, is a monitor interfacing standard that uses digital signalling in order to achieve maximum quality. The older VGA standard used analog signals, which could degrade with long/poor cabling. 

Moving back to New Zealand was a good time to get a new monitor. The cost of shipping my old monitor would have been more than it was worth, and I really needed a DVI capable monitor in order to test the DVI output. After looking around at what was available at what price, the final choice was the 22 inch Benq E2200HD. The E2200HD is one of the few monitors (right now) with 1080p HD as its native resolution (i.e., 1920x1080). This means that HD videos can be viewed at full resolution without stretching or extra black bands above and below the image. More importantly (for me), it has three inputs, DVI, HDMI, and VGA. This means that I can connect my Laptop and both graphics cards in the Amigaone (A1-XE) to the monitor without needing a KVM.

Today my Amigaone finally arrived in New Zealand. The hardware survived the long trek across the entire world and I am now in the process of updating my system via AmiUpdate. I forgot to buy a mouse and will be needing a DVI to HDMI adaptor in order to connect both graphics cards' DVI output to the new monitor (I'll post more about the monitor later). Once all this is done, I will finally be able to get back to developing the RadeonHD driver for Amiga OS 4.x.

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.