Bonsjoer,
Op de website van razer ( www.razerzone.com )
staat de volgende tekst:
"First, a couple of facts ...
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."
Ik heb de tekst nu 3 keer doorgelezen maar ik zit met het volgende, ze zeggen het zal nooit met 1 ms werken in windows xp, maar ze hebben wel wat gevonden erop (dat 16bit gedoe) zodat het wel werkt.
Kan iemand me eventjes wakker slaan aub
Op de website van razer ( www.razerzone.com )
staat de volgende tekst:
"First, a couple of facts ...
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."
Ik heb de tekst nu 3 keer doorgelezen maar ik zit met het volgende, ze zeggen het zal nooit met 1 ms werken in windows xp, maar ze hebben wel wat gevonden erop (dat 16bit gedoe) zodat het wel werkt.
Kan iemand me eventjes wakker slaan aub