Very slow on 8-bit (BBC micro) machine

[JasonStonier]

Ok, firstly thanks for a great design and for making it open source.

Disclosure - this is the first time I have soldered surface mount, and the first time I've programmed a microcontroller, so a thousand things could be wrong! Built the board up, flashed ok (I think) with Atmel Studio, and installed to a BBC micro with appropriate support ROM.

My board is sub-populated, so without the quadrature header, or the generic header - only the SMT parts, the 2x13 pin box header for bbc - the SLW jumper (closed), and the two uC bootload and reset jumpers (open).

On the beeb, I have to move the mouse -really- slowly to get it to register properly - the SLW jumper makes no difference.

Any pointers on what I should focus on to find the issue? Thanks.

[simoninns]

It's a pretty simple circuit, so it's likely one of three things.

Firstly check around the AVR chip pin to pin with a multimeter and make sure you have no shorts.

Secondly check the fuse settings of the AVR and make sure they are right and the AVR is running at the correct speed (this is very unlikely to be wrong if the USB mouse is working at all).

Finally check the Beeb... either plug in a known working board/mouse or, if possible, try your SmallyMouse2 in another Beeb. There can be anything from dirty pins to semi-working buffer ICs in there.

[JasonStonier]

Thanks for the reply Simon. So, no shorts - checked all that, and also re-flowed the solder and checked every component to ground/AVR pin. the beeb is -unlikey- to be the problem as I have a number of userport devices which all work ok. Without going through the exact pinouts, obviously this isn't definitive but it seems unlikely.

Fuse settings - I have only the most basic knowledge of programming micros - to flash the device I just loaded up your Atmel project in studio 7, compiled it, and flashed it to the chip. Is there any setup which needs to be done to the chip before flashing?

I have a few PCBs and I've just ordered a batch of micros to build them up, so it may turn out to still be my dodgy soldering - I'll let you know.

[simoninns]

The fuse settings should be fine if you used studio 7.

On the Beeb; there is a very (very) small chance it could be the 6522 VIAs; there are two in the Beeb though, so just swap them over and see (sometimes the GPIOs are fine, but the timers go weird).

Other than that, the most likely thing is some kind of construction error; making another board and comparing is a easy test though since you are already doing that.

[JasonStonier]

Again, thanks for the replies - made a second board and exactly the same symptoms. All buzzed out ok and no shorts, but still the problem that moving the mouse too fast causes the pointer to reverse direction and get very choppy on screen. Really strange! I've buzzed the ribbon cable out too, and pin to pin it's fine, so the last remaining thing to check is the 6522s. I've tried with two different mice, but will gather a collection to see if it's some weirdness with especially high DPI or something (I doubt it though, they're both bog standard USB mice) - or the surface I'm using them on (again, doubt it as they work fine in Linux).

[JasonStonier]

I'm going to hack about with the code a bit to force it into rate limiting regardless of the SLW jumper - might help start to identify where my problem is.

[JasonStonier]

Spent an hour inexpertly playing with the code (really well-commented code, very readable even for me) - first thing is that the SLW jumper definitely is being recognised by the uC, so I played with the settings for Q_RATELIMIT and Q_BUFFERLIMIT and discovered that my beeb won't sample accurately at a rate above 300Hz. With rate = 300 and buffer = 100 the mouse movement is now working, but physically moving the mouse fast causes the pointer to slow down significantly showing that sample points are being missed. The effect is present at rates down to 200Hz, but below 250Hz the sampling is too slow to represent the mouse movement properly (a fast circle produces a square, for example).

Is this adding evidence to the problem being in the timing of my 6522s?

[simoninns]

The 6522s in the Beeb are generally in sockets and can be easily swapped. The best way to test if the 6522s are at fault is to spend 2 minutes swapping them over; just try that and see if the issue goes away - that way you will know if that is the cause of the issue rather than guessing. If a chip is failing the symptoms can be completely random, so there is no other way to tell for sure.

[JasonStonier]

Cheers Simon - I will do that next time I have my beeb open (it's in a custom case so not just as easy as taking the lid off). What's interesting is that it needs to be exactly 300Hz: 301Hz exhibits the behaviour, so it doesn't -feel- like a timing fault. Can I ask: when you've done your testing on a beeb, what ROM and software are you using? - I'm using the official AMX ROM amxmse316 and AMXSuperArt as the test bed. Just wondering if it could be a sampling issue in the software, rather than a hardware fault.

[simoninns]

I've used both AMX ROMs and VFS ROMs during testing... However; if you consider that many hundreds of SmallyMouse2 devices have been made - and many of those are used with Beebs... It's far more likely to be a fault local to your setup than the software - which is why swapping the 6522s is a good approach. If this is hard to do, perhaps buying a SM2 from Ebay and testing it on your machine would be another quick way to see where the issue is.

[JasonStonier]

Of course - totally get that, and I appreciate the level of support you've shown for what is, after all, given away for free :-) I'm trying to understand the problem, as well as solve it. Thanks.

[simoninns]

Closing issue; please open a new one if you track the cause of your observations (and it is a bug/something that need investigation)