Multi-Mouse

[+MrFish]

I found this pretty cool looking mouse driver on an old L.A.C.E. disk today and decided to pull the documentation together and format it a little. I fixed a lot of errors, but maybe introduced a few new ones, since I didn't really go over it with a fine-toothed comb yet. I've included the L.A.C.E. disk as well as the all the original files pulled off the disk, including the Docs ARC and Programs ARC. I've only tried out the little BASIC test program that was included, but it looked pretty good, and the documentation and utilities seem to be pretty thorough. I also liked that he set it up to use CIO. Supposedly it will work with TBXL with a little configuring. Many thanks to Simon Trew, the author.

 

Multi-Mouse.zip

Edited October 23, 2013 by MrFish

[+David_P]

Fond memories. Back when I tried to put together a horrible mix of BASIC and canned ML routines into a Hypercard-ish program for the 8-bits, I used the MultiMouse drivers.

[+MrFish]

I've just found out about the L.A.C.E. material in recent years. They seem to have done some pretty nice stuff.

[flashjazzcat]

I remember typing this in back in the day from listings in New Atari User. Very nostalgic.

[+MrFish]

I remember typing this in back in the day from listings in New Atari User. Very nostalgic.

 

Ah, the first sparks of a graphical user interface for the 8-bits...

[+MrFish]

I went over the documentation a little more thoroughly, and made more corrections and added some additional formatting:

 

Multi-Mouse - Manual.doc

Edited October 25, 2013 by MrFish

[+MrFish]

Alright, I think final corrections, formatting, and now wrapped in a bookmarked PDF.

 

Multi-Mouse - Manual.pdf

 

An interesting note on Multi-Mouse is that Simon Trew wrote both the configuration program and the driver in the obscure PL-65 programming language. The driver, however, was done in pure assembly within PL-65, which is probably a good thing.

 

[flashjazzcat]

The relocation technique described in the docs is interesting (assembling at two different addresses and building a table of the differences), and is something I saw mentioned on another forum the other day when I was trawling the Net on the subject. I'm reminded now of Multi-Mouse's main limitation: the fact (IIRC) it polls the input device in a continuous, closed loop until the button is either pressed or released. At the time I think I wanted to use it for a drawing program, but there was no way to use the driver for "rubber-band" drawing, etc, since the CPU was sampling the input flat-out. Of course this was one sure-fire way of ensuring sufficiently high sampling rates and thus smooth pointer movement without any software mouse acceleration. Really interesting to see this again, though: nice work.

[+MrFish]

I'm reminded now of Multi-Mouse's main limitation: the fact (IIRC) it polls the input device in a continuous, closed loop until the button is either pressed or released. At the time I think I wanted to use it for a drawing program, but there was no way to use the driver for "rubber-band" drawing, etc, since the CPU was sampling the input flat-out. Of course this was one sure-fire way of ensuring sufficiently high sampling rates and thus smooth pointer movement without any software mouse acceleration. Really interesting to see this again, though: nice work.

 

Ah, so your nostalgia is partly one of disappointment. Yes, it seems to be restricted in that way. Not such a bad method for achieving smooth movement in environments such as BASIC though. But, yes, they'll be no window outlines moved with the pointer using this driver either.

 

The main benefits I see are:

- Auto-boundary checking

- User configurable and relocatable

- Dual-color pointer (pseudo-masking)

- Driver code hidden in PM Memory

- Usable with multiple devices

 

Based on the size of the code for the demo program -- 15 lines including DATA statements (not counting REM's) -- it looks to be a pretty simple way for adding mouse use to a program in BASIC or other high-level languages.