New PS/2-to-A8 (ST Emulated) Mouse Adapter Chip

[+mytek]

Although this is slated for a bigger upcoming project, I figured it would likely be useful in a stand-alone application as well. Since I have a new compact motherboard design that will require an internal mouse interface with the ability to easily switch between joystick ports, and if desired completely disappear (stealth mode), I began work on a new mouse interface chip for the A8. It could have just as easily been used in an Atari ST, or with a bit of code finagling also made to work in an Amiga. Initially I looked at some of the GPL PS/2 mouse-to-ST/Amiga offerings, thinking that I would simply add what code I needed. However once I dived in, I quickly decided this would not be a good way to go, and so began my journey to write mouse code from scratch in my favorite development application FlowCode. Anyway suffice it to say i am probably 85% done, with the last 15% dedicated to supporting mouse movement acceleration (very tricky stuff).

So here's a look at how this new mouse chip will be implemented in my new project, along with of course a TK-II keyboard chip (this schematic shows part of the I/O section).




Unlike the mouse support that existed on the early versions of TK-II firmware, and then was later abandoned, this one has true ST mouse emulation as its primary goal (plus some enhancements). Yes I know people would love to have a USB mouse instead (as well as a USB keyboard interface), but with all that I have going on I'm afraid this is the best that I can presently do. Especially considering the learning curve required to implement this in USB as well likely needing to switch over to a different processor family to really do it right (yet another learning curve to climb). Besides despite what the rumors would have you believe, there are plenty of NEW PS/2 mice and keyboards still available, as well as some that offer wireless support. And lets face it, PS/2 protocol is a hell of a lot easier to work with. Ohh and did I mention that I get lazy from time to time .

Anyway I doubt if I'll be making any PCBs for stand-alone plug-in usage, but if someone is ambitious, I will be providing the PIC MCU Firmware (in JOY2PIC and Microchip file versions). Stay tuned for more info and eventually the firmware release.

- Michael

Edited December 12, 2016 by mytekcontrols

[+mytek]

I like giving my projects names so that they can more easily be identified, and I think that this is especially important with this new mouse project since there are so many variants already out there in the wild.

 

So let me introduce you to...

 

Image source: http://www.funny-games.biz/pictures/1922-ultra-fast-cat.html

 

The name MOUSETARI will from this point forward be used to describe the MCU w/Firmware for the new PS/2 to ST/A8 mouse adapter (shown as the Mouse Chip on the previously posted schematic).

 

- Michael

 

P.S. 'Accelerated' refers to the fact that I will be implementing an exponential acceleration aspect that will allow for fast excursions across the screen directly tied into fast mouse movement. This is something that we are used to seeing in modern day mouses and operating systems, but wasn't exactly the thing back in the Atari ST era. At least not at first. Most likely I will also implement a way to adjust or possibly turn this feature off.

Edited December 13, 2016 by mytekcontrols

[flashjazzcat]

Note the WIP GOS already implements software acceleration, just in case you use it for testing and didn't realise.

[+mytek]

Note the WIP GOS already implements software acceleration, just in case you use it for testing and didn't realise.

 

Noted (and no I didn't realize that --- thank you for the tip ). And as I mentioned earlier, this is why I will implement a way to shut off and/or adjust it in the design. And soon I'll have a 'real' ST mouse to play with for comparison. So between this, your GOS, and some other mouse enabled offerings, I should be able to make this ideal for all situations.

 

Thanks again for the info,

 

- Michael

 

P.S. I'll have you know that your GOS was, and is the inspiration behind my desire to develop this new product.

Edited December 13, 2016 by mytekcontrols

[flashjazzcat]

I'm interested to know how hardware acceleration will work. One reason behind adding software acceleration to the GUI was to try and overcome overrun in the grey code (i.e. the common issue of direction becoming ambiguous owing to insufficiently frequent sampling of the port). There's an adjustable threshold, basically, of n continuous movements in any direction: once that's encountered, all X and Y changes are doubled until there's a break in continuous motion. This is very simple but works well. I'm wondering - since grey code describes relative movement - how one can "amplify" mouse coordinate changes in hardware? I mean, if you ramp up the direction changes on the port, you'll get the same overrun issue since the sample rate would need to be even greater again.

[+mytek]

I'm interested to know how hardware acceleration will work.

 

I'm still playing around with this but I am seeing encouraging results. So here follows my feeble attempt to explain what I am doing...

 

Basically most any PS/2 mouse will have a better DPI than the ST mouse, which I believe is 200 DPI, whereas PS/2 mice start at 400 DPI and go on up from there (400,800,1600). Anyway the PS/2 mouse is constantly collecting mouse movement data and setting a count in it's X and Y registers which equates to distance traveled vs time. I can read these registers at about 900+ times per second with the PIC MCU, even taking into consideration that part of my polling period includes a 1 ms delay for each Gray Code send that I make to the Atari (limitation of how fast the A8 can get a reliable read due to the RC input conditioning going into the PIA chip). This gives me very good granularity from the PS/2 mouse to work with.

 

So once I have that X/Y distance data, I do two things [1] I see if there has been any change (has it moved), and [2] if so, how far has it traveled? The how far has it traveled value is used to index a look-up table (LUT) holding my desired rate of acceleration data (gives me a number that will get plugged into a loop that sends Gray Code --- it'll loop as many times as the value taken from the table, incrementing or decrementing the Gray Code dependent upon direction). The LUT allows me to fine tune how much acceleration I will see for a given amount of movement.

 

Preliminary Acceleration LUT

/*  Translate PS2 Move into Acceleration Loop Count*/

rom char* Accel_tbl =
	{
	0x01,0x01,0x01,0x01,0x01,0x01,0x02,0x02,
	0x02,0x02,0x03,0x03,0x03,0x04,0x04,0x05,
	0x06,0x07,0x08,0x09,0x10,0x11,0x12,0x13
    };

FCV_TEMP=Accel_tbl[FCV_TEMP];

 

----

 

So if you look at the table, you'll see that early on the value remains the same for index position 0-5 (= 1 x through the X or Y move loop). But as the index value increases beyond that due to more distance traveled between samples of the PS/2 mouse, the number of times through the move loop will at first gradually increase, and then do so more rapidly as the index position approaches 15 becoming a 1:1 relationship thereafter. Without seeing the code, this might be difficult for some people to really get a good grasp of what I am actually doing. Unfortunately this code is in a visual state (FlowCode) that would take a lot of space to show. Only the LUT was done in 'C'.

 

So with those values in the LUT, I'm seeing rather good results mousing around in your GOS. The only thing I don't yet know is how would this compare to a stock ST mouse. That will be next on my list of things to do (have to get my hands on an ST mouse first).

 

- Michael

Edited December 13, 2016 by mytekcontrols

[flashjazzcat]

Thanks - that's an interesting explanation. It didn't take much effort (before I added software acceleration) to get mouse rollback, even at an 800Hz-1KHz sample rate. For this reason I think the sampling at the Atari end is always going to be the governor, unless the grey code can somehow be translated into absolute coordinates or something else which is less CPU intensive to read. The software acceleration doesn't make the driver any better at reading the mouse (indeed, slightly worse, since I was thankfully able to edge the sample rate down a little), of course. Its purpose is to actually prevent or discourage the user from moving the mouse too fast at all. Doing the acceleration on the other side of the joystick port is going to tend to overwhelm the driver, since to get fast movement (without any software acceleration on the Atari side), the bit transitions need to get more and more frequent. I'm thinking the fastest possible speed without dropped bits can be no greater than the fastest mouse movement I was able to get without rollback with the unaccelerated driver. Even if the mouse itself has a higher DPI, this is just going to mean yet more bit transitions coming in.

 

Anyway - I'll be really interested to see what can be accomplished. Reading the mouse at around 800Hz isn't really such a headache now, but it would be fun to try some different methods. We have an IRQ line on the SIO connector, for instance. A mouse which raised an IRQ when moved could get rid of the need for polling altogether.

Edited December 13, 2016 by flashjazzcat

[+mytek]

I limit overrun as part of my routine. So it can only go so fast at max speed, and not enough to give the GOS any trouble. I established what that was by simply writing a back and forth move routine that would execute 200 moves one way and then 200 moves the other way, and varied the delay between sends while watching what would happen in your GOS. So in essence I am not trying to, or am even able to exceed the mouse processing time in your routine, which by the way is very impressive. I'm just tailoring distance traveled on screen vs speed of movement on the PS/2 mouse, with fast transitions giving you lots of travel. While allowing slow movements to be every bit as precise as it would be using a non-accelerated mouse. You could of course do the same in your GOS, providing a way to tailor it inside the application similar to how it's done on modern OS's (mouse settings). My main reason for having it available in the MOUSETARI Chip, is that not all A8 applications that support a mouse are the same, so there may be advantages in doing it my way for those other programs. I'll have to scope this out better and see. Anyway for the time being, I am making good progress on this project, and so far my tests show that the overall concept of being able to select which Joystick port will become the mouse and the ability to still use Joysticks and Paddles on all ports is viable. So now its just a matter of fine tuning bits of code.

 

- Michael

[+mytek]

Hmm... I did an image dump from FlowCode of my mouse XY Move routine so let's see how well this works with AA's image handling...

 

 

This subroutine (called a Macro in FlowCode) is called by another routine I named MouseProc which basically directs all the action associated with deciphering the PS/2 mouse registers after the mouse was polled. This particular sub-routine (XYmov) is the most complex outside of the PS/2 Read and Write routines. Unfortunately this image dump doesn't give all the details of what is happening in the calculation boxes, but I think it still gives a good overview of the basics.

 

- Michael

 

Edit: Wouldn't it be nice to be able to write code for the A8 in a similar way I know to some it may appear a bit strange, but for me I have never used a better and easier programming language. And this is especially true when it comes to writing programs for PIC chips.

Edited December 14, 2016 by mytekcontrols

[flashjazzcat]

I suppose if the DPI is especially low and one finds oneself heaving the mouse around just in order to cover short distances, then hardware acceleration will be very useful. I can't recall how bad stock ST mice are in this respect since I use third-party equivalents which are a lot less clunky and possibly higher DPI. I've never tried a PS/2 or USB mouse.

[+mytek]

I suppose if the DPI is especially low and one finds oneself heaving the mouse around just in order to cover short distances, then hardware acceleration will be very useful. I can't recall how bad stock ST mice are in this respect since I use third-party equivalents which are a lot less clunky and possibly higher DPI. I've never tried a PS/2 or USB mouse.

 

Yeah if you have a mouse like this, then some kind of assist is likely needed.

 

 

Just like you, I don't presently have a stock ST mouse to test with. However one thing that I kept seeing in reference to some (not all) of the GPL PS/2 to ST/Amiga mouse code were people reporting sluggish performance. So one of my goals with this project, is to not have a fat and sluggish mouse

 

- Michael

[flashjazzcat]

I have ST mice (four or five of them), but I avoid using them for the reasons outlined above. Also, most of them are the same colour as the mouse pictured.

[+mytek]

I just did a quick video of where things are at presently with the mouse firmware.

 

https://www.youtube.com/watch?v=PFbzHnpI_w0

 

- Michael

 

Edit: Sorry that it's slightly crooked (I thought I had that tripod set-up correctly ). And yes GOS really is that fast at booting up on a STOCK A8

Edited December 14, 2016 by mytekcontrols

[Brentarian]

Michael, I'm curious how it performs with trakball games. Can you try your adaptor with Missile Command in trakball mode? (Control-T)

 

Thanks!

[+mytek]

Michael, I'm curious how it performs with trakball games. Can you try your adaptor with Missile Command in trakball mode? (Control-T)

Thanks!

Hi Brent,

 

I'll try that tomorrow. No Atari computers here at home (at least not yet). It'll be interesting to see how well that works.

 

- Michael

[pirx]

If possible, please test the mouse with Operation Blood and/or Special Forces games - there, due to very little available time the probing is done just a few (8?) times per frame, so it is definitely less than 800Hz.

[Roydea6]

Have you tried it with many games that have a mouse as the controller. I like playing Pad 1.83 by NRV 1995 - 2014. An Arkanoid style game.

[+mytek]

Thank you guys for all the great test suggestions. Now I have a list of games to check this against.

 

- Michael

[+mytek]

Michael, I'm curious how it performs with trakball games. Can you try your adaptor with Missile Command in trakball mode? (Control-T)

 

Thanks!

 

I tried it with Missile Command+ and it works fantastic! In fact it became so much fun to play that I couldn't put it down for quite some time I think I remember playing this with a trakball many years ago and it just wasn't the same as using the giant tracball at the arcades. In actuality the game plays even better with the mouse.

 

When I check out a few more different games that have been mentioned I'll have to post a video showing a short clip of each under mouse control.

 

- Michael

[+mytek]

If possible, please test the mouse with Operation Blood and/or Special Forces games - there, due to very little available time the probing is done just a few (8?) times per frame, so it is definitely less than 800Hz.

 

I can't seem to find a version of this that works on my XEGS or 1200XL. Do you have a link to one that will?

 

 

Have you tried it with many games that have a mouse as the controller. I like playing Pad 1.83 by NRV 1995 - 2014. An Arkanoid style game.

 

Pad works great with my mouse and is extremely responsive to the acceleration aspect that I built into my mouse code. This also was a good game to play with a mouse (very addicting).

 

- Michael

Edited December 14, 2016 by mytekcontrols

[+mytek]

First beta firmware version has been released: ataribits.weebly.com/mousetari.html

 

You will need to scroll down to the bottom of the page to get to the download link. This is a beta version so use it at your own risk

 

Enjoy

 

- Michael

Edited December 15, 2016 by mytekcontrols

[Matej]

This is amazing. I use ST mouse in some paint apps... ST mouses are great but that ball... So this will be ultimate solution.

[+mytek]

This is amazing. I use ST mouse in some paint apps... ST mouses are great but that ball... So this will be ultimate solution.

 

Yep no wheel mouse for me So instead I've been using a 400 DPI Logitech M-SBF96 optical PS/2 mouse, which works quite well for me.

 

 

You can get these new from eBay for around $8 with free shipping (search link). And I even see that there is a white version available.

 

 

- Michael

[ricortes]

Anyway - I'll be really interested to see what can be accomplished. Reading the mouse at around 800Hz isn't really such a headache now, but it would be fun to try some different methods. We have an IRQ line on the SIO connector, for instance. A mouse which raised an IRQ when moved could get rid of the need for polling altogether.

Way back, I did an ~absolute<bad choice of words?> mouse design. Much as I can recall, it was just two counter chips i.e. 74LS193<?> that would store the 'blips from the encoding wheels. It was a poor design in that I had to do several kludges to get it to work. I think I used one button on the mouse to reset the counters. I can't remember how I did direction, maybe some other Rube Goldberg scheme like the Atari driving controller. The noisy cursor movements from the Koala Pad were driving me nuts but my design was probably an order of magnitude worse.

 

With a micro in the mix, summing movements and absolute position when polled should be doable. I'm not sure it would be a better way of doing it, but a two button mouse would give you the option to have one button to work as a normal mouse button and the other could be a center or home button. I'm probably doing a bad job of explaining it, but instead of sending all the current data you get from a PS2 style mouse, the micro keeps track of where the mouse is relative it its starting position and that is what gets transferred to the Atari.

[Gunstar]

I have ST mice (four or five of them), but I avoid using them for the reasons outlined above. Also, most of them are the same colour as the mouse pictured.

I use a standard ST mouse exclusively with my 1200XL. I did have to do a recent cable re-wiring. But it's a lot darker color than that mouse! Of course this is on purpose, but before it's new look, it did look about the color of that real mouse too! My choice to use a real ST mouse is purely aesthetics. With the matching XL color scheme and the already angular design of the ST mouse, it matches my 1200XL line perfectly. I'm big on matching peripherals.

Edited December 15, 2016 by Gunstar