Author Topic: Xep128 (Read 110192 times)

lgb · « **Reply #45 on:** 2016.March.21. 11:53:52 »

I think it would be better to talk about Xep128 and its emulation problems

here, as the Javascript based EP emulator (JSep) is a different project ... The mouse issue which was/is being discussed there, should be here

lgb · « **Reply #46 on:** 2016.March.21. 12:01:18 »

And please respond to the Xep128 (in UK, I've started a new topic) topic, not here, hopefully the discussion here with Xep128+mouse is also moved to that topic soon

gflorez · « **Reply #47 on:** 2016.March.21. 13:34:37 »

I want to answer your questions before testing the XEP128...

Quote from: lgb on 2016.March.21. 01:20:20

Besides what I've written, an interesting question has just come into my mind. If I know correctly, the "shifting" is done by RTS change, it does not matter it was low or high before, just the fact that it changed (ie: edge triggered, regardless of falling or raising edge). However, how the app / driver / whatever (software on EP) knows what was the original state of RTS (before it starts running)? Because, if it was high, and it makes it low, it's an edge, shifting is done. But if the app always makes RTS low, there is a problem: what happens if it was _already_ low, there is no change, no shifting (of course the example works in the other way as well). As app has no way to know the original state of RTS, it cannot be sure how to produce an edge. Of course, it can make it - let's say - low at the beginning to be sure, then waiting for like 2000usec (watchdog always expires) to have a well defined level, then starts the "dance", indeed. Just I am not sure every software do this as it should (should?!). Especially it's a question with original boxsoft and apps using that protocol only where the existence of watchdog seems to be not even clear ...

This is a pretty good question and the reason that the /Select line is inverted in the Neos mouse respect to a MSX mouse.

On the MSX controller ports the Select line is normally inactive(0v), so the active state of the mouse is high(5v). But the Neos origins are from adapting the MSX mouse to a C64, and the normal state of the used pin is positive, so the active state of the mouse is low. The Neos mouse was a fiasco as Commodore soon released his 1351 mouse, compatible with its Geos operative system. I think you know this already. On that days there must be an excess of unsold Neos mice. I think there are still a lot of them, as today it is very easy to find "Mouse & cheese" boxes totally new on Ebay.

When Tim Box adapted the Neos mouse to the Enterprise he found that its controller ports didn't have an output line to interact with the processor inside the mouse. So then he used the RTS line(normally high) to do it, lowering the voltage from 12v to 5v.

On the reading routine, you can see how the idle state is HIGH, then the first state is LOW and the final state is always HIGH, even if only reading one nibble of the two, like it happens when the fifth or ninth is tested. If the last nibble read is odd, the RTS signal is forced to HIGH state while waiting for the next interrupt.

The original Boxsoft routine does a long delay just after the first LOW+nibble read, and then does short delays between nibbles. After reading even number of nibbles the state is again HIGH.

The EnterMice doesn't need that first long delay, but it has been maintained on the routine for backwards compatibility with the MSX protocol.

When you power on the Enterprise the RTS signal is always HIGH, its normal state. If an error happens on the mouse routine and the RTS line is put to a LOW state while waiting for the next interrupt, no problem, it only will mess up the following reading but at the fourth nibble RTS will be again HIGH.

gflorez · « **Reply #48 on:** 2016.March.21. 14:17:55 »

As I said before, the Neos pin-out arrangement is strange, as the /Select(/Strobe) line shares pin with the left button lead inside the mouse...

Then, every time you press the left button the pointer stops because the RTS line is forced to LOW with masse...

Is for it that the main button in the Neos mouse is the right one.

On the EnterMice adapter, in Boxsoft mode, that error has been corrected, the two buttons work, but the right one is maintained as the main one for backwards compatibility with existing programs. On EnterMice mode the Left one is the Main button, like on PCs mice.

gflorez · « **Reply #49 on:** 2016.March.21. 15:21:55 »

You've got it!

There are some glitches on the movement if the mouse is moved fast, but it is very functional.

The buttons are correct on both modes, you can read the secondary one on bit 7 of system var 190 when using the mouse driver.

I've only tested 1 and 4 modes on your XEP MOUSE command, and both work.

-XEP MOUSE 1 -----> VAR 189 3 Boxsoft mode.

-XEP MOUSE 4 -----> VAR 189 4 EnterMice mode.

If you don't put the correspondent mode on the Mouse driver it will not work.

lgb · « **Reply #50 on:** 2016.March.21. 15:53:35 »

Thanks for the test, and comments!

http://wiki.enterpriseforever.com/index.php/EnterMice#Control_Map

This section was a real miracle for me to help to understand how it does work at all ...

Besides rewriting the whole stuff, I've found some old mistakes of mine, for example:

* L column bit on button was set always in every rows, but should be on row=0.
* watchdog was handled in reading the port, I think it should be (and now it is) at the RTS signaling
* there were even mistakes at nibble handling (totally wrong values) if modes 4,5,6 are used ...

And it's possible there were more, just I haven't noticed them as mistakes, but the rewrite fixed them as well ...

My TODO/check list:

* if you see the source, maybe buttons should be swapped (?) in entermice mode, that's easy just the button map arraies should be mododified for the given mode
* the glitch stuff what you mentioned seems to be interesting ... X/Y coordinates are hold in signed 8 bit values, SDL PC mouse events updates it in a sign correct way, but if it would over/underflow, it "saturated" on the 8 bit signed max/min value. Reading the mouse buffer causes to reset x or y variable (move_dx and move_dy in the source) to zero
* it would be interesting to see if extra buttons work, if there is a software at all tries to use it (of courses modes 2,3 or 5,6 are needed for that)
* it would be interesting to see if wheel works ... wheel is handled like the mouse move, just wheel_dy is the key variable (there is wheel_dx as well, but in entermice dox, it's said that currently only one wheel is supported as a 8 bit signed value like for X/Y vals). of course, the same 2/3 or 5/6 modes are needed for that!
* it would be interesting to see if full entermice 16 nibble (8 byte) lenth answer (mode 3 or mode 6) can be interpreted successfully with any software at all (if such a software exist ...). You can see the source input.c after line "static Uint8 mouse_buffer[] = {" that "ENTERMICE" stuffs are sent as those bytes (0x44, 0x14, 0x19, 0x5D).
* handle joystick emulation if mouse is on K-column, since in that case, J-column joy-1 is available (currently this case is not handled in Xep128, joystick is not used then - anyway joystick now means the key pad numbers, which is by default replicated as both of joy-1 and joy-2, joy-1 only if mouse mode/grab is not enabled).
* as a bonus project

write SDL code to really have joystick/gamepad handled as EP joy

this would require me to have at least one joy/pad for real, ehhh ...

* figure out what kind of mouse modes are really useful and needed ... even there can be boxsoft J-column but with and without swapped buttons for convience, and some of them may be not needed at all

lgb · « **Reply #51 on:** 2016.March.21. 16:41:21 »

I've also found why SymbOS does not work without going to mouse grab mode first. In the old code of mine there was pulse detection. That means, even if mouse is not enabled (by clicking in the emu window to go into "grab" mode) it detected the RTS pulses and "temporarly" enabled mouse automatically even that it was not enough to use your mouse, on port read behaved like that for one read at least. With the new code, I disabled that (by a mistake, but it's another question). Now I put it back (it is only my local version of Xep128 yet ...), and SymbOS works again even without going to grab mode first. However I think it's an ugly solution after all. What I would like to do (maybe):

* If mouse is on K-column, it's OK to enable mouse all the time (no collusion with joy-1) even without mouse grab (then just PC mouse won't send events ...).
* If mouse is on J-column, still the auto-detection should be better, ie try to find a better algorithm because it cases interesting things which may affect applications (ie, EGI without the auto detection - without the mouse grab of course! - slowly moves the mouse pointer to the right-bottom, while with auto detection it does very quickly ... well it's not an important case, but who knows it creates other problems).

gflorez · « **Reply #52 on:** 2016.March.21. 17:05:00 »

The buttons in EnterMice mode, and also in Boxoft mode, are good as that, don't touch them!

Think that the Boxsoft mode will be history when soon Prodatron makes SymbOS compatible with EnterMice.

lgb · « **Reply #53 on:** 2016.March.21. 17:15:37 »

Quote from: gflorez on 2016.March.21. 17:05:00

The buttons in EnterMice mode, and also in Boxoft mode, are good as that, don't touch them!

Think that the Boxsoft mode will be history when soon Prodatron makes SymbOS compatible with EnterMice.

Well, at least I can keep as some higher numbered mode so it won't be the default then

For the other question: it's interesting question if there is any reason to have modes for 4,8 and 16 nibbles mode. Normally, the application won't read more nibbles/bytes than it needs, what who knows if some application wants to test the zero nibble answer to figure out what kind of interface it is, then it can be important. For the future, with widely accepted Entermice solution, virually maybe one mode is enough normally which wouldn't even collide with joy-1

pear · « **Reply #54 on:** 2016.March.21. 17:23:05 »

Quote from: lgb on 2016.March.21. 15:53:35

* it would be interesting to see if full entermice 16 nibble (8 byte) lenth answer (mode 3 or mode 6) can be interpreted successfully with any software at all (if such a software exist ...). You can see the source input.c after line "static Uint8 mouse_buffer[] = {" that "ENTERMICE" stuffs are sent as those bytes (0x44, 0x14, 0x19, 0x5D).

There is no such information in the documentation, but the hardware interface has two more bytes of data

The fifteenth byte contains the serial number and 16th is a batch number (with the exception of the first two test units that don't have serial numbers).

pear · « **Reply #55 on:** 2016.March.21. 17:26:22 »

Quote from: lgb on 2016.March.21. 17:15:37

Normally, the application won't read more nibbles/bytes than it needs, what who knows if some application wants to test the zero nibble answer to figure out what kind of interface it is, then it can be important. For the future, with widely accepted Entermice solution, virually maybe one mode is enough normally which wouldn't even collide with joy-1

In EnterMice the number of available bytes is given explicitly (at 9th nibble). No need to look for nibble 0000.

lgb · « **Reply #56 on:** 2016.March.21. 17:34:53 »

Quote from: pear on 2016.March.21. 17:26:22

In EnterMice the number of available bytes is given explicitly (at 9th nibble). No need to look for nibble 0000.

Yeah, but maybe an older software waits for zero nibble before 4th nibble (boxsoft-like) or 8th nibble (extended MSX protocol like). For a strictly-Entermice capable program, it will read the available bytes nibble, indeed

What I wasn't sure that it worth to implement "strictly" boxsoft and ext-MSX like modes, where you get 0 value if you try to read more nibbles than available for the used Xep128 mouse protocol.

gflorez · « **Reply #57 on:** 2016.March.21. 17:37:47 »

You can test the spare buttons and wheel easily testing system var 190.

write a simple Basic program to do it:

10 GRAPHICS
20 SET 180,101
30 OPEN £1:"MOUSE:"
40 ASK 190 A
50 PRINT A
60 GOTO 40

System var 190 condenses a lot of information, so you can process it before printing. There is an example on the wiki to do it.

The wheel is a special case, the value you read on the four first bits of 190 var is in reality a counter, not the direct reading of the eighth nibble. The values are added by the driver to the counter until the user resets it.

This is to aid in a scroll movement, the program sets it to zero goes to make other tasks and when returns to test if the wheel has been moved, the counter knows how many lines the program has to move up or down. Then the program has to set it to zero again and do the scroll, its other tasks and return to read more movement of the wheel.

pear · « **Reply #58 on:** 2016.March.21. 17:49:05 »

Quote from: lgb on 2016.March.21. 17:34:53

Yeah, but maybe an older software waits for zero nibble before 4th nibble (boxsoft-like) or 8th nibble (extended MSX protocol like). For a strictly-Entermice capable program, it will read the available bytes nibble, indeed What I wasn't sure that it worth to implement "strictly" boxsoft and ext-MSX like modes, where you get 0 value if you try to read more nibbles than available for the used Xep128 mouse protocol.

If you do not want to put additional data (after 8th nibble), it just set the 9th nibble to 0.
It lets to preserve the full compatibility between protocols

gflorez · « **Reply #59 on:** 2016.March.21. 20:03:56 »

Quote from: lgb on 2016.March.21. 15:53:35

* the glitch stuff what you mentioned seems to be interesting ... X/Y coordinates are hold in signed 8 bit values, SDL PC mouse events updates it in a sign correct way, but if it would over/underflow, it "saturated" on the 8 bit signed max/min value. Reading the mouse buffer causes to reset x or y variable (move_dx and move_dy in the source) to zero

I don't think so, is very improbable(impossible) to move the mouse with an increment greater than +255 or -255 in a fraction of 1/50 of second....

The Arduino code simply ignores that ninth bit the PS/2 mouse provides.

Author Topic: Xep128 (Read 110192 times)

lgb

Re: Xep128

lgb

Re: Xep128

gflorez

Re: Xep128

gflorez

Re: Xep128

gflorez

Re: Xep128

lgb

Re: Xep128

lgb

Re: Xep128

gflorez

Re: Xep128

lgb

Re: Xep128

pear

Re: Xep128

pear

Re: Xep128

lgb

Re: Xep128

gflorez

Re: Xep128

pear

Re: Xep128

gflorez

Re: Xep128