Serial mouse driver needed/needs hosting.

Can anyone recommend a good RISC OS Serial Mouse Driver?

I have a copy of !SerialMse from Stuart Tyrrell Developments.
But the licence stops us from providing it with paid hardware.
I have asked permission from STD but I’ve not been able to contact them for over a year:-(

I have been pointed to !PCMouse from M.Kircher
http://ftp.uni-stuttgart.de/pub/systems/acorn/riscos/util/mouse/
Unfortunately !PCMouse isn’t StrongArm compatible, I can only find a 20 year old postal address for the author and its licence also does not allow us to supply it with hardware.

RISC OS has a built in serial mouse driver but it seems extremely flaky!

The STD licence says:

1. License
2. ===

1. This version of !SerialMse remains copyright © Stuart Tyrrell
2. Developments. Permission is given for the program to be copied and
3. distributed on any media, as long as it is copied in its entirity (the
4. module may be seperated from the application for use as shown above), and
5. that duplication does not contravene the clause below.

1. !SerialMse may NOT be duplicated for sale as, or with, a value-added product
2. without permission, in order that some form of licensing and version updates
3. may be arranged (I can usually be persuaded to do this for free). Public
4. Domain Libraries are exempt from this clause, in so far as I do not class a
5. disk of Public Domain to be a value-added product, so long as normal rates
6. for PD libraries are charged. PD libraries may wish to contact me in order
7. to obtain updates to this module.

1. This application is given freely in good faith. I cannot, however, make any
2. guarantees as to the suitability of this mouse driver with respect to any
3. given mouse. Under no circumstances does this license imply a binding
4. agreement as to such suitability, although I will endevour to investigate
5. any mouse/machine combination on which problems arise.

I had hoped to be able to point to the Stuart Tyrrell
Developments website so buyers could download it themselves but it doesn’t appear to be available for download anywhere. Have I missed it or is it available from anywhere else?

We could put a copy on our site for download, which I think might comply with the letter of the licence but I’d prefer not push into grey areas.

I think there is nothing stopping a private individual from putting it on a site! If some kind soul decides to do that can I suggest hosting two versions.

By default !SerialMse is configured for an ‘MS’ type mouse which makes it very difficult if you have a ‘PC’ type mouse. So it would be very helpful to users if a second copy preconfigured to ‘PC’ type was included. Adding:
SerialMouseType PC
To the !Run file as below does this.

| !Run for SerialMse
|
Set SerialMse$TempSuffix “3”
RMEnsure UtilityModule 3 Set SerialMse$TempSuffix “2”
Set SerialMse$TempPresent 1
RMEnsure SerialUtils 0 Set SerialMse$TempPresent 0
IF SerialMse$TempPresent = 1 THEN RMKill SerialUtils
Set SerialMse$Path <Obey$Dir>.
Set SerialMse$Dir <Obey$Dir>
IconSprites <SerialMse$Dir>.!Sprites
RMEnsure SerialMouseDvr 3.05 rmload <SerialMse$Dir>.SerialMse
|
| We’ve got a PC mouse attached
SerialMouseType PC
|
WIMPSLOT -min 32K -max 32K
RUN <SerialMse$Dir>.!RunImage

What are the issues that prevent you from using the standard serial mouse driver? If third-party solutions are vanishing then maybe it’s about time the default one was brought up to scratch.

It would be good to bring the built in driver up to scratch and I will retest and report in detail the issues. But the current main market I wish to address is RISC OS 3.1 and 4.02 users whose mouse has died. They can’t or will not be interested in running RISC OS 5. We have sold out of the Castle PS2 Pipe and just have a few PS2MouseMinis left and it seems like we may never be able to get any more of either. I do have other options to pursue but none of them will be quick and we need to keep existing users up and running with as little hassle for them as possible.

But the current main market I wish to address is RISC OS 3.1 and 4.02 users whose mouse has died. They can’t or will not be interested in running RISC OS 5.

That needn’t be a problem. ROOL’s SerialMouse module is under 2K in size, it surely won’t take too long to fix it up so that it will run on RISC OS 3.1. Once that’s done there shouldn’t be anything from stopping you from providing it as a softload.

Actually, getting it running on RISC OS 3.1 would be a bit tricky since the module interfaces with the OS via PointerV, which was a RISC OS 3.5 addition. I don’t really know enough about RISC OS 3.1-era mouse handling to be able to say how difficult it would be to make it work with that (I guess it could directly invoke the kernel mouse routines, if they can be found within the ROM)

I seem to recall that many years ago I wrote a serial driver for a joystick type of mouse thingy. I have a vague recollection of having to use osword for the mouse coordinates.

Chris – I have emailed you with a suggestion

Test results using three serial Mice: Old Genius Easymouse, old Logitech M-MD15L-9F, New Genius Easymouse

On RO 3.1:
No inbuilt serial mouse driver
All work with STD’s !SerialMse set to PC Mouse, fairly smooth.

On RO3.7:
Old Genius & Old Logitech with inbuilt driver in either mode mouse either is unresponsive, or jumps around all over the screen clicking random buttons at slightest movement or click.
Old Genius & Old Logitech only work with STD’s !SerialMse, set to PC Mouse, fairly smooth.
New genius works with inbuilt Microsoft or Mouse Systems Serial Mouse setting, but a bit jerky. Works with STD’s SerialMouse set to PC Mouse and is smoother.

On RO5.22 Iyonix, serial port 1:
Old Genius & Old Logitech do not work with inbuilt driver in either Microsoft or Mouse Systems mode.
New Genius works with inbuilt driver in either Microsoft or Mouse Systems mode, relatively smooth
None work in serial port 2
Twice, when changing mouse mode encountered error “Invalid object type <00> <00> <01>” on clicking ‘Continue’ after warning (I think, from memory, unable to reproduce)
STD’s !SerialMse is not 32bit.

Mousetype:
0 – Acorn mouse
1 – Microsoft Serial Mouse
2 – Mouse Systems Serial Mouse
7 – USB

n.b. Peter I’ve replied by email.

I don’t really know enough about RISC OS 3.1-era mouse handling to be able to say how difficult it would be to make it work with that (I guess it could directly invoke the kernel mouse routines, if they can be found within the ROM)

I did something recently that needs to fiddle with the mouse. The position is set via the OS_Word call, and the button clicks are dealt with by intercepting MouseV and pushing the appropriate bits on return from the vector.

Simple and effective…

The only trouble I found with setting the position via OS_Word (mouse handling in vncserver) is that the kernel ignores the new position if it lies outside of the mouse rectangle (unlike the internal routine the kernel uses to update the position, which will clamp it). So you have to track mouse rectangle changes yourself and perform your own clamping.

On RO5.22 Iyonix, serial port 1:
Old Genius & Old Logitech do not work with inbuilt driver in either Microsoft or Mouse Systems mode.

Interesting idea that – testing a serial mouse on a machine with the built in ability to use USB mice are almost throwaway cheap.

Sadly, USB Marconi Trackerballs are not throwaway cheap 8~( – I’ve still not got around to converting any of my old Acorn-connection Marconi trackerballs to USB – I did convert a couple of them to serial, see http://clive.semmens.org.uk/DIY/index.html?Project5188 – a similar trick should let me convert one to USB, but I’ve not got round to it yet. I’ve tried all sorts of mice and trackballs, but nothing compares to a proper Marconi beastie – except possibly the Mac trackpad, which I can’t use with the Pi 8~(

Interesting idea that – testing a serial mouse on a machine with the built in ability to use USB mice are almost throwaway cheap.

Yes I can’t see anyone ever using one. But it does give some idea as to what to expect from the current driver. I don’t have a RiscPC with 5.xx ROMS to test on.

I don’t have a RiscPC with 5.xx ROMS to test on.

Soft load?

Soft load?

To be honest I really can’t work up any enthusiasm for running RISC OS 5 on an RiscPC. This the first time it would have been of any use to me. I think my time is better spent on some of our other projects than setting up RO5 on an RPC!

I think my time is better spent on some of our other projects than setting up RO5 on an RPC!

I think that the best and most flexible way of testing things is to set up something to test on, particularly if you have a number of the bits of kit handy.

With a soft load it’s even possible to setup one disc with the soft load build and one without.

I’m with Chris; ROOL’s serial mouse driver should behave the same whether you’re on an Iyonix or a RiscPC, so there’s little point setting up a RISC OS 5 on a RiscPC just for mouse testing if you’ve got a perfectly good Iyonix sitting around.

there’s little point setting up a RISC OS 5 on a RiscPC just for mouse testing

“just for mouse testing”? I said “testing things” with the suggestion that it could be used for multiple tests.
More particularly if the build is on an interchangeable disc it could be used for a comparison of the behaviour of various things on both RO4.02 and RO5 with the same hardware.

That licence looks permissible enough for us to host on riscos.info. However the licence doesn’t seem to permit modification, although the ‘as shown above’ bit is missing and might change this (for instance, ‘separating the module’ and writing a new !Run file that does what you want).

On the subject of mice, I suspect it wouldn’t take very long to lash up an Arduino to read in a PS/2 mouse and generate quadrature output – making a new PS2Mouse adaptor. It’s mostly a case of gluing together existing libraries. You probably want the most basic Arduino because they’re 5 volt – newer ones (Due) can also read USB devices, but they’d need their outputs converting from 3.3 to 5v.

There are plenty of PS/2 adapters based on PIC’s (this or this for example). There’s not a massive demand for them though, so nobody’s willing to manufacture/build them, even though they cost less than £10 to make. The other problem of course is mark-up on said adapters.

I was looking at the PS/2 mouse and PS/2 mouse/keyboard adapters I designed a few years back and thinking “I really should devote some time to test them.”

We’ve worked out that you don’t need to modify it! Providing an obey can get round the problem.
e.g.
Even if the user has to copy the application to a DOS format floppy to get onto the computer *exec loaddrv
Where loaddrv is a file of:
| Set the filetype to Module
SetType $.!SerialM.SerialMs Module
|
| Load the module.
RMEnsure SerialMouseDvr 3.05 RMLoad $.!Serialm.SerialMs
|
| Turn off acceleration
SerialMouseAcc OFF
|
| We’ve got a PC mouse attached
SerialMouseType PC
|
| Use the configured mouse speed.
SerialMouseSpeed 0
|

n.b. the SetType $.!SerialM.SerialMs Module is I’ve now realised unnecessary as rmload command loads a module correctly even if not filetyped as module!

There are plenty of PS/2 adapters based on PIC’s (this or this for example).

Thanks for the pointers Jon.

Unfortunately IanB’s design at http://stardot.org.uk/forums/viewtopic.php?f=16&t=9334
is for Archimedes only and not a Quadrature replacement

and http://qubeserver.com/Qube/projects/PS2Quad.html
Says:

Sorry, it’s not finished yet – come back in a while…
Charlie (2010)

One of the biggest problems with a Quadrature replacement is the 9Pin mini DIN plug/cable.
Usable 9Pin mini DIN cables are hard to come by. I have bought some in only to find that not all 9 pins were connected. No right button connection is a bit of a show stopper.

Hand wiring a 9Pin mini DIN plug reliably is not really practical commercially. I have approached Castle to licence their PS2Pipe but as yet they haven’t found the code for the PIC. It is many years since they produced a batch.

I did locate a source of 9Pin mini DIN plugged ‘Sun’ mice only to find they don’t work and don’t wire up all 9 pins so I couldn’t even just use the cables.

What’s the problem with a cable like this ?
(I’m sure cheaper in volume could be found by sufficient scouring of Alibaba)

Though don’t some cables have a mechanical problem where they’re too fat to plug in?

Good find Theo, though given the cable thickness it could only be used as a cable to a box containing an interface. Also producing a box that looks professional is very difficult unless it is for vast numbers… or I wonder where STD sourced the box used for their original STDMouse… an hour and half later and it doesn’t seem it was from RS. Though with many enclosures not having a photo I may well have missed a suitable box (I stopped looking when they got to £14 each!) It isn’t very motivating trying to reinvent the wheel!

For the sorts of volumes we’re talking about, I might be thinking about 3D printing. The advantage is you design it once, tailored to your product with all the holes etc in the right places. Compare with an off-the-shelf box, where you might need to do various drilling and machining steps to get there. Most consumer(ish) 3D printers are slow (maybe 2 hours per box), but that’s not a problem for small volumes – you can ‘print on demand’. There are also cheap 3D printing services (I have no experience of that particular one)

The tradeoffs (design time / workshop time / materials cost / batch size) are somewhat variable – depends how many you think you’ll sell and what capabilities you have.