nV News - Razer Diamondback Precision Gaming Mouse

RAZER DRIVER SOFTWARE
An entire review could be spent on this software. Much of it has been part of the Razer series of mice for some time now and already well covered as a result. The software offers you an extreme amount of granular control of such things as: independent x and y axes sensitivity settings, on-the-fly sensitivity (very cool feature), key-to-button assignment, etc.

Here is some more information from a Razer whitepaper that explains many of the finer points of this mouse:

Windows XP and the USB low speed HID protocol supports an 8 BYTE data packet = 64 bits maximum size.

Windows XP restricts the USB low speed HID protocol to a 8ms-polling rate contrary to USB spec. Windows 2000 and ME comply with the USB spec. This is why we had to find another way around instead of increasing polling rate; it won’t work in WinXP (but it will work, in OSX and Linux, for instance).

The “8 bit” data packet is just a convention that most mice use to report X/Y information. There is in fact no such restriction in Windows, as long as the total information sent, including things like button presses etc, does not exceed 64 bits. How much data is apportioned to X/Y is determined by the FIRMWARE of the mouse, the default drivers on the OS will take their cue from the firmware and receive data accordingly (the beauty of USB plug and play).

The problem with 8 bits for X/Y info is well known. -127/+127 (left/right) is the maximum info that can be sent, resulting in a very low maximum top speed of around 11” per second at 800dpi and 6400 frames per second.

On top of this problem, the old MX500 did not have buffer overflow protection, so if it exceeded +127 instead of staying at +127, it would either error and reset to zero, or worse, reset to -127, resulting in the mouse going in the OPPOSITE direction as fast as possible! With 12 bits, the maximum is -2048/+2048; with 16bits the maximum is -32k/+32k.

Razer Diamondback implementation is like this:

1ms is implemented, BUT it only works in Win2k and other OSs that properly support the USB protocol. It does NOT WORK in WinXP which forces low speed HID devices to 8ms (you can’t set it lower, and you can’t set it higher).

An 8-bit/16bit solution has been implemented, much like Logitech’s 8/12bit solution. WinME and Win2K users would not have noticed this since the 1ms poll rate setting would have been accepted in the firmware by the OS. The 8bit part of the data packet should never be seen by the OS, which should just throw this info away. However, it’s there JUST IN CASE someone decides to plug the mouse into a USB equipped machine running Win95 or has a USB port that is nonstandard, which is highly unlikely since this mouse is meant for gamers.

The 1ms lag feature won’t work in WinXP, and the majority of western gamers do run WinXP. The 16bit data packet completely resolves this issue. Those running Win2k will achieve the best performance.

NOTE: In the "Assign a Key" image above, the ä (umlaut) character before the D is not a typo. That is simply the character that shows up when you press the Windows key. In the case above, I was assigning Windows+D (the shortcut to minimize all open desktop windows) to a button on the mouse.

The image below shows the adjustment scale when on-the-fly sensitivity is enabled. This is adjustable with the scroll wheel. OTF can only be assigned to button 4 which may bother some people though I found it to be the button I'd use for it anyway. This overlay will show up in games as well which was very useful. For example, there are times in Doom 3 or Half Life 2 where I wanted higher or lower sensitivity. All I had to do was press button 4, hold it down and scroll to adjust. Release button 4 on the overlay is gone. I loved this feature.