copy
Support of Microsoft Serial Mouse on /dev/ttyS1
v86 emulates a PS2 mouse, which seems to be supported by elks. I wouldn't mind supporting serial mouse too, but it's probably not very widely used.
No. This documentation is completely outdated. There is experimental support for PS2 mouse on a serial line, not the bios PS2. But this is not the case in copy.sh, right? So either Microsoft serial mouse or PS2 mouse on a serial line will be welcomed.
And why in https://copy.sh/v86/?profile=elks it does say Mouse: No on the right. It should provide PS2 mouse, right?
But this is not the case in copy.sh, right?
Do you mean that ELKS supports PS/2 protocol via serial port?
it does say Mouse: No on the right. It should provide PS2 mouse, right?
Yes, it reacts to PS/2 mouse initialization.
https://github.com/copy/v86/blob/2996c087fd35d481501880769bfbe8cc1a139e3b/src/browser/main.js#L2233-L2237
Hi @copy and @SuperMaxusa,
Do you mean that ELKS supports PS/2 protocol via serial port?
Yes. When ELKS is setup for PS/2 mouse, it executes the following code when reading from a serial port:
/*
* Input routine for PS/2 mouse.
* Returns nonzero when a new mouse state has been completed.
*/
static int
ParsePS2(int byte)
{
switch (state) {
case IDLE:
if (byte & PS2_CTRL_BYTE) {
buttons = byte & (PS2_LEFT_BUTTON|PS2_RIGHT_BUTTON);
state = XSET;
}
break;
case XSET:
if(byte > 127)
byte -= 256;
xd = byte;
state = YSET;
break;
case YSET:
if(byte > 127)
byte -= 256;
yd = -byte;
state = IDLE;
return 1;
}
return 0;
}
In other words, it parses each byte of the 3-byte PS/2 mouse message read from serial. It could easily be upgraded to the 4-byte version for mice with scroll wheels or five buttons. It doesn't write anything to the mouse.
I wouldn't mind supporting this, but it's not a high priority.
That would be fantastic, thank you! Let me know if need any help from my end.
I recently ported Microwindows to ELKS, and everything is now running, multiple applications drawing in multiple windows, all running 16-bits, see the screenshot below. @toncho11 has tested this with copy/v86 and all is also running except the mouse. At this time, the ELKS kernel doesn't know anything about mice and implementing a hardware PS/2 mouse requires trapping IRQ 12 which isn't allowed for application programs... the Microwindows server performs all the mouse reading/decoding, all from serial on ELKS (and Linux). I would like to add hardware PS/2 mouse support to the ELKS kernel but its a bit complicated and requires more changes that it should. QEMU and 86Box allow serial mouse emulation but we really like how easily copy/v86 boots and runs an OS right from the web.
16-bit ELKS running Nano-X on QEMU
Thank you!
Hello @ghaerr, nice to see you! Awesome work, looks really cool!
Let me know if need any help from my end.
I have experimented with ELKS and the serial port and I have a question: is it possible to change a default mouse port for ELKS (mouse utility) and Nano-X?
I tried to export MOUSE_PORT=/dev/ttys1 (on QEMU and v86) but it still uses ttys0 instead of ttys1. My ELKS version is v0.8.1.
In copy.sh/v86, COM0 is used by the terminal by default, so it would be better to use a different COM port.
Thanks!
Hello @SuperMaxusa,
Thanks, it's been fun getting Nano-X back running 16-bit.
Yes, it's possible to change /bin/nano-X and /bin/mouse to use the second serial port as you mention using export MOUSE_PORT=/dev/ttyS1 (note the capital S not s). However, you should probably be running ELKS v0.9.0-dev, as there have been some changes made recently in this area. I've attached a ready-to-go 32M bootable ELKS image for you, with the mouse port set to /dev/ttyS1 in /etc/profile. (Login as root, then type "nxstart" to start nano-X).
In copy.sh/v86, COM0 is used by the terminal by default, so it would be better to use a different COM port.
Great, I prefer it that way myself, as in that configuration debug or informative messages will be displayed on /dev/ttyS0 which is routed to the host terminal session, while the mouse operates on /dev/ttyS1. With QEMU, there is otherwise no way to get debug messages to the terminal if the mouse is on /dev/ttyS0.
Internally, there is an ELKS hack that sets QEMU=1 at boot (for qemu only) when it is programmatically found that QEMU is running, and then the mouse port is set to /dev/ttyS1 automatically (unless overridden by MOUSE_PORT=). This aids in getting users running without having to otherwise separately specify MOUSE_PORT=/dev/ttyS1. For copy/v86, we'd just upload an image that has MOUSE_PORT= set and everything should run. I've done that on the attached HD32 image.
Thank you!
Thanks for the image, I recently made a rough prototype of MSMOUSE and it works with ELKS.
https://github.com/user-attachments/assets/be8105d5-6b78-4a4c-a766-4802e8821531
Current problems:
- Reset by RTS line for mouse identification is not implemented. It seems this is not required for ELKS and Linux, but required for Windows and MSMOUSE driver for MS-DOS.
- Need to figure out with BusConnector stuff, but this is v86-specific thing.
Will update if I make some progress.
Awesome! That will help a lot as copy v86 is my preferred way of testing ELKS! Post an url where we can try when you are ready.
There is a new Paint application to try as well!
This is great @SuperMaxusa, thank you for adding MSMOUSE support! And correct, ELKS doesn't use RTS for mouse identification (or any serial control for that matter).
Your video seems to show everything working quite well, with nxworld displaying single-point graphics quickly on v86. Since the last image I posted here there's been some improvements made to the graphics cursor which use VGA hardware XOR for higher speed and a better looking cursor for slow 8088 machines. I need to add that to Microwindows and try it out on v86 to see how that looks. I'll also add the upgraded Paint application as well. and post another image here.
@toncho11 after we get that done you can post an updated image on the main v86 page :)
Sorry for the long delay, I'm a bit busy right now and don't have time to finish the MSMOUSE device. I'm trying to add compatibility for other OS and drivers.
Current problems:
- Hold and drag doesn't work in Basic Linux, starts clicking when moving, on ELKS it works properly.
- (maybe) Fix CuteMouse for DOS (needs some 16-bit I/O ports and probably https://github.com/copy/v86/pull/1423).
Anyway, here's my WIP branch: https://github.com/SuperMaxusa/v86/tree/msmouse-wip If you have any useful docs about MSMOUSE, let me know :)
Will deploy a small demo with ELKS later.
Thank you for the update! If you have this version web hosted somewhere publicly I could use it / test it to run ELKS with our Microwindows Nano X.
Hello @SuperMaxusa,
Thank you for continuing to move this forward with everything else you're doing.
If you have any useful docs about MSMOUSE, let me know
Are you looking for external Microsoft documentation, I might be able to find some?
Hold and drag doesn't work in Basic Linux, starts clicking when moving, on ELKS it works properly.
That is a bit strange. I ended up fixing a Microwindows MSMOUSE problem by only reading 3 bytes from the mouse at a time, and passing the results upwards, rather than trying to be "fast" and reading everything the mouse might have sent. This corrected some synchronization errors outside the driver:
/*
* NOTE: max_bytes can't be larger than 1 mouse read packet or select() can fail,
* as mouse driver would be storing unprocessed data not seen by select.
*/
#define PC_MAX_BYTES 5 /* max read() w/o storing excess mouse data */
#define MS_MAX_BYTES 3 /* max read() w/o storing excess mouse data */
#define PS2_MAX_BYTES 4 /* max read() w/o storing excess mouse data */
Not sure that will help here since I haven't studied your driver, but thought I'd mention it.
I can post the working ELKS or Microwindows mouse decoder if that might help.
When you end up applying any MSMOUSE enhancements, let us know and we'll help test it.
Thank you!
Hello @ghaerr,
Thank you for your response!
Are you looking for external Microsoft documentation, I might be able to find some?
Yes, this would be great, actually I used FreeDOS driver and mouse(4) man pages, and I want to make sure I haven't missed anything in those specs.
I ended up fixing a Microwindows MSMOUSE problem by only reading 3 bytes from the mouse at a time, and passing the results upwards, rather than trying to be "fast" and reading everything the mouse might have sent.
Hmm, so ELKS' driver ignores 4-th byte for the middle button and/or wheel (for MSMOUSE with 3 Button Logitech extension)? My driver and QEMU (not sure about other emulators) uses this mouse type.
If I correctly understand, Basic Linux' driver should support 3-button mices and uses auto-detection for mouse type, at least on QEMU it works properly.
Thank you!
Hurray, the bug in Basic Linux was fixed!
@ghaerr Thank you again for pointing out the packet length, I was mistakenly always sending 4-byte packets (3 bytes for the standard MS protocol + 1 byte for middle button/wheel extension), even when the middle button wasn't pressed, like in the first implementation in QEMU: https://github.com/qemu/qemu/commit/aa71cf802eb884dcdaebae6fbbd008248a64a01b. For me, it works with 2-button mouse drivers (like ELKS), but confuses 3-button mouse drivers. Now the 4-th byte only sent when the middle button was pressed.
At this moment, the mouse implementation works with ELKS, Basic Linux and modern Linux with gpm (mouse-test is partially broken, works with manual setup: gpm -m /dev/ttyS1 -t ms+).