exxos's Atari, Amiga & retro forum

Here's a guide to my Smalliermouse project, based on Simon Inns' Smally Mouse 2.

I demonstrate its use, discuss its advantages, build one, flash the firmware and show how to tweak the settings of this open-source hardware Atari-focused USB mouse adapter.

https://github.com/dh219/SmallyMouse2

https://oshpark.com/shared_projects/GFtooovG



BW

Nice!

Just to note that this won't work on the original ST (external floppy only) as the mouse and joystick ports are recessed into the case and close together, meaning that even having the tabs on each side of the DB9 make the devices too wide.

Otherwise it looks interesting. Does it have a diode on the right button connection so that it can't override the joystick button? This is a problem with the Tom+.

stephen_usher wrote: 10 Sep 2021 12:16 Otherwise it looks interesting. Does it have a diode on the right button connection so that it can't override the joystick button? This is a problem with the Tom+.

Thanks.

The buttons are driven with an open drain arrangement. This was an early improvement over the original firmware which has been adopted upstream.

BW

The one you sent me I have used a fair bit now. It seems to work very well overall. I know we was talking about the bandwidth limits of the port and such previously.. There does seem to be a tiny bit of "lag" but of course that is versus the actual movement on the mouse by how much it actually moves. So less lag would mean " more mouse work". We had the same problem with PeST in fact. It's why overall we had four selectable modes so people could choose which one they wanted.

@Badwolf Sorry if I missed it, but I can't seem to find the BOM on github.

Steve wrote: 10 Sep 2021 15:44 @Badwolf Sorry if I missed it, but I can't seem to find the BOM on github.

I've never really got on with BOM files. Never sure what format they should have or what they should say!

This is what KiCAD has spit out. Is this any use? If so, I'll add it to the repo.

Cheers,

BW.

The BOM files depend upon the manufacturer. PCBWay require a CSV file in their own format, which has different columns to that which KiCAD produces.

stephen_usher wrote: 10 Sep 2021 17:39 The BOM files depend upon the manufacturer. PCBWay require a CSV file in their own format, which has different columns to that which KiCAD produces.

Yeah, exactly. I've always seen them as a bit of a personal thing. What you put in them depends on the circumstances so I'm never sure what should be in a published one.

I suppose the only key component is: 1x Amphenol Right Angle SMT Socket Type A 2.0 USB Connector (eg. RS component number 771-0050)

BW

exxos wrote: 10 Sep 2021 14:47 The one you sent me I have used a fair bit now. It seems to work very well overall. I know we was talking about the bandwidth limits of the port and such previously.. There does seem to be a tiny bit of "lag" but of course that is versus the actual movement on the mouse by how much it actually moves. So less lag would mean " more mouse work". We had the same problem with PeST in fact. It's why overall we had four selectable modes so people could choose which one they wanted.

Sorry -- missed this earlier. Glad to hear it's performing well. :-)

The only 'lag' you ought to see is in the buffered ('overflow') movements if the divisor is too low. Out of the box it's set to 1/4 second max. It's the 'bufferlimit' setting in the firmware. Lower lag doesn't have to mean more mouse travel, though. It's a coupled sliding scale, but it's not reciprocal.

The two extremes are:

• Set bufferlimit to 0 to have no lag -- you might have lost travel instead.
• Raise the divisor so that your most rapid movement doesn't exceed 400 Hz -- that's the one that trades movement against lag.

And of course personal preference will be somewhere betwixt those two.

Ultimately it's quart into a pint pot, isn't it? ;)

BW