Rodents anyone ?

Modern, Memotech inspired, hardware projects
Martin A
Posts: 406
Joined: 09 Nov 2013 21:03

Rodents anyone ?

Post by Martin A » 27 Apr 2018 09:49

Hot on the heels of the PS2/USB Keyboard interface, now it's the Mouse's turn!

The PS2 mouse protocol is handled by an ATmega328, that converts the serial data from the mouse into 4 directional on/off signals plus left and right button.

Those 6 signals are then pushed onto the keyboard sense lines when the keyboard scanning routine drops the relevant drive line low.

To keep integration with existing software as simple as possible the 18V8 GAL maps the 4 directions map to the cursor keys, while the buttons map to home and return.

Diodes on the sense line ensure that the GAL doesn't interfere with the normal keyboard scanning.

The board is build with a 20 pin male header, which allows it to be connected in parallel with the keyboard using a normal 3 plug IDE cable. A 5v power supply from the MTX is needed. Pin 11 of the Port 7 socket is one source, but there are others that are reasonably easy to tap.
Image2.jpg
Component side
Image2.jpg (81.92 KiB) Viewed 1182 times
Image1.jpg
Wiring side, 7 blue wires are keyboard drive lines, the long green ones are sense. The short green ones connect the GAL to the AVR. The long yellow ones are mouse clock and data
Image1.jpg (108.38 KiB) Viewed 1182 times
There are a couple of shortcomming in the MTX keyboard handling that need to be "worked around" The CALL #0079 scanning routine stops as soon as it finds one key dow. So although the GAL could be setting anywhere between 0 ( no movement) and 4 (diagonal movement with both buttons down) keys, the OS only ever finds one.

Any code that reads the key matrix directly, bypassing the OS would be able to "find" multiple key presses.

The othe issue that cause problems is the resistors that pull the drive lines high on the MTX motherboard are slow. During normal scanning if there are no keys down the scanning sequence is:
Drive port 5, bit 2 low to check control
Drive port 5 bit 6 low to check both shift keys
Drive port 5 bits 0 to 7 low in sequence to read the rest of the keyboard.

The drive lines in port 5 aren't reset after each test, they're just left as they are until the next sense line is selected. Checkimg the drive lines with a logic analyser to find out why the mouse was generating incorrect key presses, I found that with the mouse board attached, the resistors take 4us or so to pull the drive lines back to a valid high after they released. With a 4mhz Z80 that's 16 cycles. The MTX follows the OUT5 to set the drive lines with an IN 5 to read the main keyboard port, that instruction is completed within those 16 cycles. Which means that there are actually 2 drive lines that are low. The one activly being checked, and the previous one being pulled up by the resistor.

In normal use, that's not a problem, however with both the mouse and keyboard providing input, that was leading to false keys being recorded, as the GAL on the mouse board could be driving the sense line base on the "old" drive line while the scanning routine was actually checking the "new" one.

The solution was to monitor not just the 5 drive lines the mouse needs, but also the lines that follow those in the scanning sequence. The revised GAL code then releases the sense line if it detects the next drive line going low. The speed of the GAL means the sense line is release within nano seconds and eliminates the phantom keys.
Last edited by Martin A on 29 Apr 2018 11:01, edited 1 time in total.

Tony Brewer
Posts: 62
Joined: 08 Jan 2014 20:50

Re: Rodents anyone ?

Post by Tony Brewer » 27 Apr 2018 18:07

Could this be integrated with the keyboard interface, if it is meant to be more than just an experiment?

User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Rodents anyone ?

Post by Dave » 27 Apr 2018 20:21

Hi Tony,

Technically, yes, but in practice, probably not - at least, not for the MTX PCB. The current board has been kept <100mm wide to minimise the manufacturing cost. It is not possible to fit the extra components in the free space below the keyboard with a board <100 wide. Given the limited need for a mouse on the MTX, I wanted to make the more useful keyboard PCB as cost effective as possible.

I will more than likely include it on the MTXPlus+ I/O board that I am reworking at the moment and add it with the USB/PS2 keyboard interface

Regards
Dave

Tony Brewer
Posts: 62
Joined: 08 Jan 2014 20:50

Re: Rodents anyone ?

Post by Tony Brewer » 27 Apr 2018 23:47

Dave, I was wondering whether the Propeller could replace the ATmega328.

User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Rodents anyone ?

Post by Dave » 27 Apr 2018 23:57

Hi Tony,

That’s probably one for Bill. We did briefly discuss adding USB mouse functionality to the Propeller, but Bill thought that if he added the optimisations that you suggested to the USB keyboard code, there wouldn’t be enough spare cogs for the mouse. We did not talk about adding just a PS/2 mouse though. There may be scope to do that . . . . Bill?

Regards
Dave

Bill B
Posts: 159
Joined: 26 Jan 2014 16:31

Re: Rodents anyone ?

Post by Bill B » 28 Apr 2018 09:15

Personally, if I was adding a mouse interface to the MTX I would not do it through the keyboard lines. To make real use of the mouse you would need new software to support it. I would add a new interface, with Z80 ports from which you can read X and Y positions and button status. You could then have an interrupt routine which reads the mouse position and (on the VDP) updates the position of a sprite to act as a mouse cursor.

However, if you are using the keyboard interface, I can think of two different approaches:
  • Like a joystick. If you move the mouse up, the cursor up key is pressed. It is not released until the mouse is moved back down again. With this approach, I think I would want four LEDs to show the effective state of the cursor keys.
  • Alternately, moving the mouse up (say) 3cm could produce three separate cursor up press and release events. This would solve the issue of diagonal moves in that moving the mouse 3cm up and 2cm to the right would generate 3 cursor up and 2 cursor right press and release events, with only one key down at a time. I think that this approach would be more effective for things like word processors or spreadsheets (but then who does that on an MTX nowadays). Implementing the timing of the key press and release is not simple, and there may be an issue with keeping up with the mouse.
As to the question of using a Propeller to implement a combined keyboard and mouse interface:
  • For PS/2 keyboard and mouse, yes it could probably be done.
  • For USB it gets rather more challenging. The keyboard and mouse would require separate USB drivers, each requiring 3 cogs. That would leave one cog for keyboard matrix mapping, and one for the keyboard drive and sense lines. So perhaps just about possible for mouse as joystick (although no spare pins for the indicator LEDs). I think trying to sequence cursor press and release events for my alternate mouse emulation would require at least one more cog than is available.

User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Rodents anyone ?

Post by Dave » 28 Apr 2018 09:58

Hi Bill,

Although Martin is keen, I am pretty ambivalent about adding a mouse to the MTX. As you describe, the “best” solution is probably to go the I/O port route, but anything that used the mouse would need new software. Using VDP sprites would only work on the 40column screen and probably wouldn’t work with (m)any games. Personally I don’t think that this is worth doing unless there is a really strong justification that I have missed.

However, if the mouse functionality does not need any software modification, i.e., just works by enpmulating the cursor keys as Martin’s current implementation does, then I am much more inclined to do it. If we can do it with no additional hardware, putting the mouse in the Propeller, then so much the better. Using the cursor keys means that the mouse works with games and 80 column software such as NewWord.

On your second point, I think that Martin’s AVR code works as per the first bullet. I can’t really see a need for indicator LEDs, apart from perhaps for initial debugging. Also, with the board inside the MTX, location of the LEDs would be problematic. I’m sure Martn will comment on the second bullet point.

For the Propeller, my feeling is that, if the number of cogs is going to limit implementating a totally flexible USB and PS2 keyboard and mouse solution, then we should stick with the current plan of having a flexible USB/PS2 keyboard board with a PS2 only mouse. PS2 mice seem to be more available than PS2 keyboards and this appears to be a workable solution for the time being.

Martin?

Regards
Dave

Martin A
Posts: 406
Joined: 09 Nov 2013 21:03

Re: Rodents anyone ?

Post by Martin A » 28 Apr 2018 14:36

The current software uses a very simple set of rules.

Each direction has a counter. Small movements of the mouse add to the counter but don't trigger a key press until the threshold value is met.

Once the key press is triggered, the counter gets reset. If the counter is below the threshold the key is un-pressed.

The idea is to prevent movements close to the axis reporting as diagonal, but slill alow for fine movement control.

Slow movements just under the threshold will report as down up down up on successive updates. The slower the movement the longer the up period. Faster than the threshold movements will report continuously down.

The current setup is 2 buttons and 2 axis, Dave's asked for that to be upgraded to include the mouse wheel and middle button. 3 button, 3 Axis looks to be possible there are sufficient free pins on the GAL and AVR. The software will need updating to identify the "intellimouse" protocol, but that too seems doable and there's plenty of rom space available on the AVR.

User avatar
1024MAK
Posts: 555
Joined: 24 Dec 2012 03:01
Location: Looking forward to summer, in Somerset, UK

Re: Rodents anyone ?

Post by 1024MAK » 28 Apr 2018 16:58

On other 8 bit systems, mice are either interfaced via counters in a special mouse interface (ZX Spectrum, Amstrad CPC) or via an existing I/F port (Acorn BBC, Master).
The former is less CPU intensive and more accurate. The latter is cheaper. But of course both require either "driver" software (plumbed into either interrupt service routines or OS vectors) or software written specifically for use with mice.
There have been many joysticks that "simulate" curser keys (or other keyboard keys), but very few mice that do the same.

I think we really need more information on the usability before deciding... (unless an advanced interface can be developed that does both curser keys and counter I/F).

Any chance of a you tube video Martin?

Mark

User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Rodents anyone ?

Post by Dave » 28 Apr 2018 17:15

Hi Mark,

I don't want to have this idea turn into a science project :) - Well, no more than it already is :lol:

For me, they key requirement (pun intended!) is to have a USB/PS2 keyboard interface.

If we can add a mouse interface too, for close to zero additional cost and absolutely no need for additional MTX software, then I'd be on board with it. If the mouse needs driver software on the MTX, or speciually written MTX application software, to use it, then I think that we will have failed. I don't believe that additional software on the MTX is likely to be worth the effort of coding it (not that I would be doing it).

If a functional mouse inerface can be added that just mimics the cursor keys (as Martin has already done), then I think that is enough.

To my mind, the only outstanding question is whether there is any justification for using the AVR that is currently on Martin's board. If we can achive pretty much the same thing wthout the AVR and use the Propeller, then I think that is the way to go.

Having Martin do a video of the operation of his current mouse interface is a good idea. Hopefully, that should be enough to demonstrate that it is works well enough to perform a useful job. Assuming that it does, then, provided that it can be done, I would prefer to put the functionality in the Propeller.

I am interested in hearing other opinions though

regards
Dave

Post Reply