Hardware acceleration for R5xx cards is still a work in progress. In the meantime I have discovered how to switch the card to performing byte-swapping in order to convert from big-endian to little-endian modes for R5xx cards (Radeon X1000 series). Previously, all modes were simply defined as being little-endian, thus byte-swapping had to be performed in software by Picasso96. This is now handled automatically by the R5xx chipset.

It has been several weeks since I posted an update on this project.  Right now hardware accelerated blitter is still a work in progress. In the meantime I have written an installer and AmiUpdate script for the driver. I personally dislike software that requires manual installation, and so took the time to write the necessary scripts for installation and updates. This was done now rather than later since I knew that it would take some time to write an installer (which is something that I had not done before), and it would have been very tempting to skip it if the driver were ready for release, and no installer was written. Along with the installer and update script, a "build-release" script has also been written. Thus, making a release now simply requires running a single script.

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.