VOGONS


PS/2 to Serial Mouse protocol converter

Topic actions

First post, by sklawz

User metadata
Rank Member
Rank
Member

This is a simple example circuit and working software for a PIC Micro which converts a PS/2 enabled mouse into a RS-232 enabled serial mouse.

There is a related thread to this one here:
PS/2 Mouse port addon, optical mouse with serial protocol

A demo of this application can be seen here:
http://youtu.be/_iGMpO0fris

The PIC Micro chosen for this project was the PIC16F628A. Choice was simple, this device has both an internal oscillator and a serial UART. It is also one the cheapest PICs available at vendors and on ebay. Other PICs may be used if desired but the 628A is so cheap it seems like a pointless exercise.

An example circuit schematic and the source assembly code for this project can be found on my PIC Micro project pages which are here:
http://dev.kewl.org/k8048/

The project pages are mostly about programming PIC Micros and are mostly unrelated to the PS/2 converter. The actual detail you will require for a demo schematic is here:
http://dev.kewl.org/k8048/Src/asm/pic16f648a/gEDA/rs232.png

and for the working assembly file:
http://dev.kewl.org/k8048/Src/asm/pic16f648a/rs232.asm

Notice that the assembly file includes further assembly files, I will upload an INTEX HEX32 file here later ready for programming.

You may also notice that I used a 648A micro for the test, it's just a bigger version of the 628A.

There is further work required for the circuit, since the demo doesn't have a PSU nor does it attempt to use the RS-232 lines to power itself.

This thread should be used to rectify this, however, I will not be doing any more development on this project except for any software bug fixes but I will answer any questions regarding how this converter operates as best I can.

Good luck.

UPDATE (4th March 2013):

Here are two simplified schematics for two different PIC Micros:

PIC16F628A:
http://dev.kewl.org/k8048/Src/asm/mouse/gEDA/pic16f628a.png

PIC16F688:
http://dev.kewl.org/k8048/Src/asm/mouse/gEDA/pic16f688.png

Here are the Intel Hex 32 files:

PIC16F628A:
http://dev.kewl.org/misc/mouse/pic16f628a.hex

PIC16F688:
http://dev.kewl.org/misc/mouse/pic16f688.hex

Here are breadboard layout images:

PIC16F628A:
p1020639p.jpg

PIC16F688:
ps2serial.jpg

Here are the source files:

PIC16F628A:
http://dev.kewl.org/k8048/Src/asm/mouse/pic16f628a.asm

PIC16F688:
http://dev.kewl.org/k8048/Src/asm/mouse/pic16f688.asm

Last edited by sklawz on 2013-03-04, 19:49. Edited 3 times in total.

Reply 1 of 125, by keropi

User metadata
Rank l33t++
Rank
l33t++

awesome work!
will you also provide a simplified schematic for building the adapter with just the basics along with the .hex file? can't wait to test it!

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 2 of 125, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Thank you for sharing the schematic. A few questions:

1) What is the function of the SW DIP-4? Why do you want to connect these 4 lines to GND and not to GND. Is the switch normally open or closed?

2) What is the purpose of the 2-colour LED?

3) Is the diode a standard 0.7 V rectifier, i.e. 1N4148?

4) Is the 100 pF capacitor between RB6 and GND only required for initial ICSP programming purposes?

Plan your life wisely, you'll be dead before you know it.

Reply 3 of 125, by sklawz

User metadata
Rank Member
Rank
Member

Hello

keropi wrote:

awesome work!
will you also provide a simplified schematic for building the adapter with just the basics along with the .hex file? can't wait to test it!

I will provide a simplified diagram if no one else does in the meantime.

feipoa wrote:

Thank you for sharing the schematic. A few questions:
1) What is the function of the SW DIP-4? Why do you want to connect these 4 lines to GND and not to GND. Is the switch normally open or closed?

The four switches are to enable and disable PS/2 mouse features and also to switch between two different software algorithms.

This is in the rs232.asm header:

;  1 RA6 RESOLUTION B'00XXXXXX'=1 B'01XXXXXX'=2 counts/millimeter
; 2 RA7 RESOLUTION B'10XXXXXX'=4 B'11XXXXXX'=8 counts/millimeter
; THIS SETTING APPEARED TO HAVE NO IMPACT ON THE TEST MICE
; APPLIED AFTER RESET OR HOST INITIATED REINIT
;
; 3 RA3 SCALING 0=1:1 1=2:1
; THIS SETTING APPEARED TO HAVE NO IMPACT ON THE TEST MICE
; APPLIED AFTER RESET OR HOST INITIATED REINIT
;
; 4 RA4 ALGORITHM 0=DIVIDE 1=LIMIT
; USE DIVIDE MODE FOR TEST MOUSE #1
; USE LIMIT MODE FOR TEST MOUSE #2
; APPLIED IN REAL-TIME

A simplified circuit may omit the switches and just pull the pin either way. For RA4 though, it would be best to have a 2-pin jumper.

feipoa wrote:

2) What is the purpose of the 2-colour LED?

The bi-colour LED toggles between it's two colours as the device is taken out of RESET by the serial host computer. You can see this in the video (the bottom most LED). MS-MOUSE 9.01 will RESET the mouse on loading and also when the mouse is opened.

feipoa wrote:

3) Is the diode a standard 0.7 V rectifier, i.e. 1N4148?

Yes, but the diode can be omitted if you are not providing a high level programming voltage on VPP (ICSP).

feipoa wrote:

4) Is the 100 pF capacitor between RB6 and GND only required for initial ICSP programming purposes?

Yes, that is correct. It is there for reliable ICSP operation only.

Bye

Reply 4 of 125, by keropi

User metadata
Rank l33t++
Rank
l33t++

great, I'll wait for that simplified diagram without the programming port or switch , I have no problem building stuff but I can't really make the simplification myself 😀

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 5 of 125, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Thank you for the clarification. It sounds like the 2-colour LED is for prototyping/troubleshooting purposes only. When omitting the LED, can we leave RA2 and RB5 floating, or should we pull them low through a resistor?

I do not plan on using ICSP. I was going to use a multi-purpose programmer once the .hex file is ready. I suspect this would be how must people here choose to program the PIC since we are not handling the programming. Are there any other circuit simplifications besides the diode and 100 pF omissions? At this level, I think this is pretty straight forward for anyone to setup on a breadboard.

Let us know if any switch setting preferences change after testing the tracking quality at 1280x1024.

Plan your life wisely, you'll be dead before you know it.

Reply 6 of 125, by sklawz

User metadata
Rank Member
Rank
Member

Hi

feipoa wrote:

Thank you for the clarification. It sounds like the 2-colour LED is for prototyping/troubleshooting purposes only. When omitting the LED, can we leave RA2 and RB5 floating, or should we pull them low through a resistor?

Left NC is okay.

feipoa wrote:

I do not plan on using ICSP. I was going to use a multi-purpose programmer once the .hex file is ready. I suspect this would be how must people here choose to program the PIC since we are not handling the programming. Are there any other circuit simplifications besides the diode and 100 pF omissions? At this level, I think this is pretty straight forward for anyone to setup on a breadboard.

The 100K on RB4 can be omitted once the PIC has LVP mode disabled which would be case if the chip is programmed externally.

And, yes, this circuit is dead simple, hardly anything needed when using this line of PIC micros.

What's important are the pull-ups, one each for the PS/2 lines and one for the MCLR. In fact this latter may be omitted if MCLR is disabled but that is untested.

feipoa wrote:

Let us know if any switch setting preferences change after testing the tracking quality at 1280x1024.

I will create a second version of the code specifically for this page. It will utilise the internal pull-ups on port B and relocate the switch inputs there as wires or jumpers for the protocol options but more importantly for the algorithm selection.

What's important is that all mice are different. In my test sample of two I needed two algorithms. One for the basic optical mouse and the other for a high resolution optical mouse.

I will see about doing this over the weekend. Firstly I will remove everything from my breadboard and start over again but keeping it minimal.

Bye

Reply 7 of 125, by feipoa

User metadata
Rank l33t++
Rank
l33t++
sklawz wrote:

What's important is that all mice are different. In my test sample of two I needed two algorithms. One for the basic optical mouse and the other for a high resolution optical mouse.

That is somewhat concerning... What were the symptoms? I am using a 3-button Logitech PS/2 track ball mouse (M-S38 MouseMan), which I have been addicted to since 1998. Perhaps once you have completed the new code you could add some instruction into the code comments as to which parameters might be altered for different mice. Then the user of a particular mouse can employ some fuzzy logic to the algorithm for fine tuning.

Plan your life wisely, you'll be dead before you know it.

Reply 8 of 125, by sklawz

User metadata
Rank Member
Rank
Member

lo

feipoa wrote:
sklawz wrote:

What's important is that all mice are different. In my test sample of two I needed two algorithms. One for the basic optical mouse and the other for a high resolution optical mouse.

That is somewhat concerning... What were the symptoms? I am using a 3-button Logitech PS/2 track ball mouse (M-S38 MouseMan), which I have been addicted to since 1998. Perhaps once you have completed the new code you could add some instruction into the code comments as to which parameters might be altered for different mice. Then the user of a particular mouse can employ some fuzzy logic to the algorithm for fine tuning.

I am sure your old mouse will be fine.

My test mice were as follows:

; TEST MOUSE #1 GENIUS GM-050021 TRAVELER 320 OPTICAL MOUSE
; TEST MOUSE #2 EXCEL AM-1310U+P MINI OPTICAL MOUSE

Mouse #1 is too sensitive for the low sample rate achievable over the serial line. Serial mice are 1200 baud which is pitifully slow by today's standards. Added to that we also need to sample the PS/2 position before sending three bytes of data, the maximum rate achievable is 20 samples per second. AFAIK serial mice normally achieve ~40.

Mouse #2 is a basic mouse and probably the same as your own sample. I will test this mouse tomorrow.

The two algorithms are absolutely necessary since PS/2 mice report movement in 9-bit displacements and serial mice in 8-bit. Obviously 9 doesn't fit into 8 hence algorithm 1 divides the movement by 2 and algorithm 2 limits the maximum displacement.

Bye

Reply 9 of 125, by vetz

User metadata
Rank l33t
Rank
l33t

All this is abit too complicated for me, but it seems you are on the right path sklawz 😀

I just hope this project can turn into something usable for people without the technical know-how of how to program or build the converter itself.

3D Accelerated Games List (Proprietary APIs - No 3DFX/Direct3D)
3D Acceleration Comparison Episodes

Reply 10 of 125, by sklawz

User metadata
Rank Member
Rank
Member

Hi.

vetz wrote:

All this is abit too complicated for me, but it seems you are on the right path sklawz 😀

I just hope this project can turn into something usable for people without the technical know-how of how to program or build the converter itself.

Well, this project would require some technical capabilities *or* friends 😀

The technical aspects would be soldering and flashing the micro-controller.

No other knowledge should be necessary other than being able to supply power. A basic mobile phone charger at 5V should suffice for this.

I will endeavour to get back here with a simpler solution tomorrow. It is too late here in the UK for anything now.

Goodnight.

Reply 11 of 125, by keropi

User metadata
Rank l33t++
Rank
l33t++

it would be nice to have a small device that plugs in a serial header inside the computer and outputs to a ps2 bracket , powering with 5v once inside a case would be trivial 😀

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 12 of 125, by feipoa

User metadata
Rank l33t++
Rank
l33t++
sklawz wrote:

Added to that we also need to sample the PS/2 position before sending three bytes of data, the maximum rate achievable is 20 samples per second. AFAIK serial mice normally achieve ~40... PS/2 mice report movement in 9-bit displacements and serial mice in 8-bit. Obviously 9 doesn't fit into 8 hence algorithm 1 divides the movement by 2 and algorithm 2 limits the maximum displacement.

Hopefully this loss of resolution isn't very noticable.

Last edited by feipoa on 2013-01-26, 00:15. Edited 1 time in total.

Plan your life wisely, you'll be dead before you know it.

Reply 13 of 125, by keropi

User metadata
Rank l33t++
Rank
l33t++

^ if it's at least like our ps2 adapters then I'm happy... sure you can't use high resolutions with ease but they make excellent adapters for XT/AT DOS machines 😀 and it's wayyyy better than nothing 😊 😊 😊

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 14 of 125, by sklawz

User metadata
Rank Member
Rank
Member

Good day.

keropi wrote:

it would be nice to have a small device that plugs in a serial header inside the computer and outputs to a ps2 bracket , powering with 5v once inside a case would be trivial 😀

That is feasible and also a great idea. Power could supplied from a floppy power connector.

feipoa wrote:

Hopefully this loss of resolution isn't very noticable.

With the divide algorithm the pointer is slowed down by half. With the limit algorithm there is no resolution change but the maximum speed of movement is limited.

I will look at this today but first will see about booting XP and testing a higher resolution. What exactly would you like me to test for?

Bye.

Reply 15 of 125, by sklawz

User metadata
Rank Member
Rank
Member

Hi

I dug this out of the other thread:

feipoa wrote:

I saw the YouTube video, but the resolution was pretty far from 1280x1024. Could you test your converter at 1280x1024 and let us know verbally how well the mouse tracks?

It tracks as any other mouse I have in XP. The pointer moves exactly where I expect it to be when I expect it to be there. I assume this is the question you are asking? The only difference due to the low sample rate of the serial interface is that the stepping of the pointer is greater per sample which gives it a less fluid motion.

Bye

UPDATE: Here is a new demo video:
http://youtu.be/9uTXhoLNUv0
You can see the mouse converter working here at a high resolution in Windows 98. The video quality isn't good but should be adequate.

Reply 16 of 125, by feipoa

User metadata
Rank l33t++
Rank
l33t++
sklawz wrote:

It tracks as any other mouse I have in XP. The pointer moves exactly where I expect it to be when I expect it to be there. I assume this is the question you are asking? The only difference due to the low sample rate of the serial interface is that the stepping of the pointer is greater per sample which gives it a less fluid motion.

There are two situations I have noticed with other converters. With the Raritan converter, the lag in acceleration was so bad that you were always over-shooting where you wanted the mouse position to be. You had to move the mouse really slowly to navigate any menus.

With the Vetra Systems converter, the issue was more like you describe, less fluid. You could see the stepping in the mouse movement, somethings it would look like the pointer was blinking as you moved it.

These are the two conditions I am testing for. It sounds like your converter may have symptoms similar to the Vetra converter's symptoms, but to a much lesser degree. I say to a much lesser degree because you mentioned, "It tracks as any other mouse I have in XP."

If you have time, would you mind testing a typical serial mouse at 1600x1200 in XP, run through the start menu programs, some drop-down menus, etc. Then could you qualatatively compare the motion of the serial mouse to that of PS/2-serial converter mouse that you've made? It would be most appreciated.

With the divide algorithm the pointer is slowed down by half. With the limit algorithm there is no resolution change but the maximum speed of movement is limited.

Which algorithm has the least visible impact on the user at 1280x1024, for a user who leaves the default XP mouse speed/acceleration settings in the middle?

Plan your life wisely, you'll be dead before you know it.

Reply 17 of 125, by sklawz

User metadata
Rank Member
Rank
Member

hi

feipoa wrote:
sklawz wrote:

It tracks as any other mouse I have in XP. The pointer moves exactly where I expect it to be when I expect it to be there. I assume this is the question you are asking? The only difference due to the low sample rate of the serial interface is that the stepping of the pointer is greater per sample which gives it a less fluid motion.

There are two situations I have noticed with other converters. With the Raritan converter, the lag in acceleration was so bad that you were always over-shooting where you wanted the mouse position to be. You had to move the mouse really slowly to navigate any menus.

With the Vetra Systems converter, the issue was more like you describe, less fluid. You could see the stepping in the mouse movement, somethings it would look like the pointer was blinking as you moved it.

Neither is there lag nor blinking.

feipoa wrote:

These are the two conditions I am testing for. It sounds like your converter may have symptoms similar to the Vetra converter's symptoms, but to a much lesser degree. I say to a much lesser degree because you mentioned, "It tracks as any other mouse I have in XP."

If you have time, would you mind testing a typical serial mouse at 1600x1200 in XP, run through the start menu programs, some drop-down menus, etc. Then could you qualatatively compare the motion of the serial mouse to that of PS/2-serial converter mouse that you've made? It would be most appreciated.

The mice move to the intended destinations equally well. The point has been made already, the serial mouse has 20 samples per second when converting from PS/2. A standard PS/2 mouse uses more like 100 and a regular serial mouse 40. The difference is clear, the serial mouse has a less fluid motion.

It is impossible to send more samples down the serial interface at 1200 baud. This isn't a choice but the absolute limit of what is possible.

sklawz wrote:

With the divide algorithm the pointer is slowed down by half. With the limit algorithm there is no resolution change but the maximum speed of movement is limited.

feipoa wrote:

Which algorithm has the least visible impact on the user at 1280x1024, for a user who leaves the default XP mouse speed/acceleration settings in the middle?

This depends on the mouse. I quite like having the setting low with the limit option but I also quite like the divide option with the setting higher up.

Bye.

Reply 19 of 125, by keropi

User metadata
Rank l33t++
Rank
l33t++

thanks for the simplified schematic and hex!!! 😀
this mind sound stupid, but why the pins of the st232cn are not in order? it is so they are easier to draw right?

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website