Okay, after some very quick tests, I'm not very pleased with the scroll wheel as an input. However it looks like it might vary on the mouse and the mouse driver; even so, I think it'll be hard to find a good mouse. An other possibility might include some ugly mame hacks.

First off, I tested only three unhacked mice, with their default drivers, and used the "scroll wheel". One wheel had a mechincal encoder, another has a optiomachincal wheel geared so one bump while turning the scroll wheel equaled one gap passing the sensor, the third was a "scroll trackball" with optiomachanical encoder wheels like normal TBs, with "two" scroll directions. I set the mouse settings to scroll 1 line in windows (shouldn't make a difference for most drivers), mame's digital speed to 1, and left the accelleration at default. I tested arkanoid.
On the two normal scroll wheels, the arkanoid paddle jumped quite a bit at each bump. I believe this is due to a default step (or granularity) much greater than one (1) of the normal mouse axes.
The scroll TB was a little different. First, both vertical and horizontal are seen as moving the Z axis in mame. However, in windows I can't scroll diagonally: it's either scroll straight up-down or straight left-right, depending on which of the two the ball is roll the most. So either the driver is splitting and filtering the HorScroll and the VertScroll from a mixed Z axis, or the chip in the mouse is filtering it first and somehow sending on the Z axis a different signal depending on which Vert or Hor it's getting the most of. (I think it's the chip doing the V-H filtering, and the driver decoding.)
Now vertical scrolling the TB jumps just like the wheels.
However, horizontal scrolling acted differently. It would jump forward about 1/2 as far as the other jumps, jump back past the original position, and then jump forward not as far as before, jump not as far, ect for about 3-6 frames, ending about where it should be if it were a normal mouse axis turned as much. IOW, if it didn't wiggle back and forth like it does, it would be perfect.

That said, IIRC it might be possible to decrease the step the mice are sending with directInput inside mame, if the mouse and driver let it. Again, this might vary from mouse to mouse and driver to driver.
tmasman,
As for applying the diff, I was able to do it to 0.85, and the code looks like ir should fit, but I don't have the old compile stuff set up anymore, so I wasn't able to compile (didn't get that far). I hope someone else tries it and reports back, instead of me reinstalling the old stuff. Thanks
