ENTERPRISE KLUB
2019. május 25., 1055 Budapest, Nyugati tér 9. 14-19 óráig
Részletek
Welcome, Guest. Please login or register.


Author Topic: Xep128 (Read 22911 times)

Online gflorez

  • EP addict
  • *
  • Posts: 2557
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #15 on: 2016.March.10. 10:39:02 »
Maybe I am mistaking you a little....

You are emulating the hardware of a two buttons mouse(1 effective button at the end....)  because implementing the captions of the extra buttons and wheel is very difficult, as you said:

About more buttons: in emulation it can be problematic. For example maybe the real PC mouse used with the your PC (which running Xep128 then) don't even had so much buttons. And even for more buttons, eg for JSep, in browsers it's problematic to handle the right button as it's usually "locked" for the browser's local menu, and only the left button can be used to trigger JS events. Well, it's possible to override the other button as well with some tricks - if I remember correctly - but it's kinda tricky and maybe (?) not portable between different browsers easily.

Then, the Boxsoft protocol (MSX and EnterMice, exactly the same) has evolved to implement more buttons and wheel on the real hardware, but your code doesn't need to know it. Is for that you must put only a fifth nibble filed with zeroes, because it is the mark of the simpler mouse, with only two buttons.

The driver then will attempt to read that fifth nibble and will default to the simpler mouse. Other programs that use older versions of the driver or internal routines like SymbOS will work because they don't read that fifth nibble.  

As I said before, Boxsoft and Entermice are the same but are read on different bits to save incompatibilities with the first joystick port.

Here you can see the complete protocol, there are a lot more of nibbles added by Pear... Your XEP doesn't need to know that...

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #16 on: 2016.March.10. 14:03:15 »
Well, I admire you if you can understand this mouse world of EP, really :) For me, it's quite confusing. Especially this quite slow method to "step" over nibbles then "scan" bits in the nibbles, detecting using, etc :-@ I would say, it's better to create some parallel protocol/interface but indeed, it would mean a bus expansion card, which is maybe not so nice. Oh well, maybe it's still the more simple, only problem that it's not so simple from the view point of programmers :)

You are emulating the hardware of a two buttons mouse(1 effective button at the end....)  because implementing the captions of the extra buttons and wheel is very difficult, as you said:

Xep128 can do more than JSep (the javascript web emulator), since Xep128 is a native application, no problem with the mouse buttons used by browser, or not handled at all, etc. It's mater of SDL in fact, as far as I can see, it means at least 3 buttons (but the mouse header file of SDL also defines X1 and X2 so maybe it means five buttons?), I have no idea about wheel scrolling etc though. So it's possible to emulate more functionality, I guess ... Also note, that game controllers/joysticks for some degree is already supported by JSep (because modern browsers has API for this) and maybe in Xep128 too in the future, so there is really room for the improvement here :)

Quote
The driver then will attempt to read that fifth nibble and will default to the simpler mouse. Other programs that use older versions of the driver or internal routines like SymbOS will work because they don't read that fifth nibble.

Ok, now I'm officially lost ... :) How it can be done "not to read the fifth nibble"? I guess it's not possible, since the "stepping" over nibble iterates over nibbles, so if there are more than four, old software won't work which expects four "stepping" to get the nibble being the "first", then you need more stepping pulse to get the same result. Also I couldn't understand too much what happen if a program send a pulse by mistake before your program to be able to run, then nibbles will be "shifted", since there is nothing which can tell which is the "first" nibble, no way to find a sync point.

Quote
Here you can see the complete protocol, there are a lot more of nibbles added by Pear... Your XEP doesn't need to know that...

I see, and it's indeed a very nice and helpful draft on the protocol within a single table. However, I still can't get it, if you have more nibbles, no software will be compatible, ie 4 nibble mode softwares does 4 "pulses" to "cycle" nibbles so if there are more, it simply won't work.


Offline pear

  • EP lover
  • *
  • Posts: 754
  • Country: pl
  • Z80 only
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
Re: Xep128
« Reply #17 on: 2016.March.10. 16:28:26 »
I see, and it's indeed a very nice and helpful draft on the protocol within a single table. However, I still can't get it, if you have more nibbles, no software will be compatible, ie 4 nibble mode softwares does 4 "pulses" to "cycle" nibbles so if there are more, it simply won't work.
I thought about this when writing firmware.
If the device only supports BoxSoft protocol, the fifth nibble is always equal to 0000.
The same is true in the case of a difference between the Extended MSX and Entermice. The ninth nibble is equal to 0000 for Extended MSX and greater than 0 for Entermice.
Moreover the hardware EnterMice have implemented watchdog, which allows you to read an incomplete set of nibbles.

Online gflorez

  • EP addict
  • *
  • Posts: 2557
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #18 on: 2016.March.10. 16:58:16 »
You can admire me, as mice and its relation with EP's is the only thing that I can understand.....

The cause of the existence of the MSX protocol (and therefore the Boxsoft and EnterMice ones) is that inside every single msx mouse there are a 4 bit microprocessor(the Neos chip) calculating the movement of the mouse and sending nibbles over a 4 bit input parallel bus formed with the four direction leads. One output line more is needed for requesting information to the Neos chip. You already know this. The AY sound chips used on the MSX computers have additional I/O data ports that are used to form "easily" the joystick ports(at the end it is not so easy, as they must be read through the AY chip by commands).

The convenience of this method is to discharge the Z80 from the task of decoding the movement of the mouse. It returns two bytes, one for X and other for Y that express the amount of movement from the last reading. Then, the processor only have to add those signed numbers to the pointer position, putting care on borders or "objects" in screen.

But you know that reading the joystick ports adds a little of difficulty when implementing this on the Enterprise...

On a MSX computer you only need the mouse for it to work, but the controller ports of the Enterprise are not so standard and need to be converted. On a C64 the adaptation was almost straight, because the signals where compatible, only that it used other pinout, the Atari one.

Is for all this I think that the Boxsoft interface is a little miracle.

On the other side its existence has opened us the way to a EP SymbOS port, as they use the same protocol.

-------------

Ok, XEP128 can emulate more than two buttons, but first we must make work the most basic mouse.

-------------

It is a fact that a real MSX mouse returns 0000 if a fifth or more nibbles are requested, it only returns the four first nibbles of the movement, then waits for the next 1/50 second, the next interrupt. Based in this, Prodatron and NYYRIKKI  invented the extended MSX protocol.

A mouse with more than two buttons(a PS/2 to MSX converter like EnterMice) always returns 0001 on the fifth nibble read.

---------------

Then you must put 0000 on the 5th nibble, the mouse driver will read it and will stop requesting data, the actual version of SymbOS or the older driver will not read it, but it doesn't matters, as the movement is already read, and then your emulator, not requested for more data, will wait up to the next reading cycle, the next 1/50 second. If you don't request for more nibbles the mouse or the EnterMice doesn't sends more. And it is not a malfunction.

Once the rest time has passed, the program begins again another lecture cycle from the first nibble.

It is more simpler than you can think.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #19 on: 2016.March.18. 22:50:10 »
Here you can see the complete protocol, there are a lot more of nibbles added by Pear... Your XEP doesn't need to know that...

I just wonder about that nice JPG. Can you also give information what bits should be checked? I mean the mouse_read() function, if you remember. So I would be really interested in some kind of table like that JPG but extended with all Entermice modes and the interpretation of reading port 0xB6, it seems boxsoft uses different ones (which, yes, conflicts with external joystick in fact ...). I plan to have setting for all possible mix of modes, number of nibbles, which lines should be used, etc, so hopefully it's enough to select the right one :) Also, I don't understand clearly that JPEG either, for example:

* extended MSX portocol buttons 3,4,5. Well OK, but where is button 2? Is it supported even in BoxSoft protocol? Honestly, I wrote my original JSep code by trying to understand a disassembled code fragment :) So I guessed many things without really knowing the background ...
* horizontal wheel / Z value? What is Z value? :) Sorry about the stupid question :)
* byte-4: what are those values exactly?
* bytes 5 and 6: what are those? Actualy, I guess it's the values given by the CPLD on Entermice, but what are the "current" values so I can "fake" them?
* is it possible to switch between modes, or it can be only done on the hardware "by hand"?
* "watchdog" seems to be an answer of my question, that "shifting" can be out of sync by a software bug etc, and nothing will work from that point. But what is the time value for the watchdog, and what exactly it does? Reseting the "nibble counter" to zero?

Thanks for your patience :)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #20 on: 2016.March.19. 01:27:23 »
Well, I've just discovered (hmmm, re-discovered ...) the wiki page, it's quite a good one! It can explain many things, even some of my questions, though not all of them. What I can't still get it: in my naive implementation, "shifting" nibbles are "circular" ie, after max number of nibbles for the given protocol, it warps around to the beginning of the "cycle". What is the correct behaviour? It should be endlessly emits bytes '0' if it does not know entermice stuffs, and just start again after a time of "silence" of query (the so called watchdog)? And is it the same policy in alll protocol modes? Eg, with entermice protocol extension, byte 7 is device id which seems to be constant. Now that's 16 nibbles, what happens if I endlessly try to "shift" for the next nibble, I will get the nibbles of the 0x5D (entermice device id), or only its last nibble, or it warps around to byte 0? Sorry, this sounds a bit cryptic for me, that how it works ...

Online gflorez

  • EP addict
  • *
  • Posts: 2557
  • Country: es
  • OS:
  • Unknown Unknown
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #21 on: 2016.March.19. 02:05:48 »
Lets see if I can explain it easier.

You already know that the Enterprise has two controller ports, allowing each one four directions and a fire button. There is even an Exos call and Basic commands to read them.

But the real capacity of the controller ports is triple than that, if you see at the pinout there is the J "normal" common, but also the K and L commons.

These possible buttons haven't been used in the past, except for the Boxsoft interface, but only by necessity.  The Neos mouse has a strange pinout that shares the main button lead with the \Select lead on the same pin. This produces the freezing of the pointer if the left mouse button is pressed while moving the mouse. Tim Box opted to use the right button as main button instead, but connected it to one of the undocumented alternate commons, L.

It is the Neos mouse wich limited the Boxsoft interface to only one button. Of course EnterMice doesn't have that limitation.

Translated to code, the J common is read on bit 0 of 0xB6 port, K on bit 1 and L on bit 2. Three bits as columns, by ten rows give us 30 possible buttons.

EnterMice is exactly the same as Boxsoft, but bit 0 is avoided to not collide with the joysticks , instead it is read on K column, bit 1. I name the columns J, K and L because they match with the J, K and L commons on the controllers pinout.

Second button? It is a physical button, not like 3, 4  and 5 that are software read by the protocol. Every controller port only has one fire button, so Pear, Zozo and I opted to maintain  the left button on row 0, L column, and the right button on row 0 K column. You have a detailed  graphic about this in the EnterMice wiki.

Z is the relative movement of the vertical wheel since the last lecture.

The following nibbles only describe internal versions inside EnterMice, not very useful for you. A Microsoft three or five buttons with wheel mouse has an id of 4, hardware version is 1.4, and firmware is 1.9.

You can make the EnterMice emulate the Boxsoft, easy, as basically the movement is send to bit 0(J column) intead of bit 1(K column). You only have to move a switch.

On the software side, the universal mouse driver can read all types of controller. You can change it at system variable 189. For example from Basic: SET 189, 3 sets the Boxsoft as controller. On Exdos you can use for example the command VAR 189 4 to set the EnterMice as controller.

About the watchdog, ask Pear....
« Last Edit: 2016.March.19. 02:48:14 by gflorez »

Online gflorez

  • EP addict
  • *
  • Posts: 2557
  • Country: es
  • OS:
  • Unknown Unknown
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #22 on: 2016.March.19. 02:29:09 »
The Msx protocol is driven by a 50 Hrz interrupt. Once the reading begins, the mouse sends packets until it detects a big pause, then it doesn't obeys the \Select signal until the next interrupt(It doesn't detect the interrupt, only waits the estimated time).

Pear discovered that a great amount of nibbles can be potentially sent between interrupts, so he implemented his re-extended protocol...

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #23 on: 2016.March.19. 02:47:10 »
The Msx protocol is driven by a 50 Hrz interrupt. Once the reading begins, the mouse sends packets until it detects a big pause, then it doesn't obeys the \Select signal until the next interrupt(It doesn't detect the interrupt, only waits the estimated time).

Pear discovered that a great amount of nibbles can be potentially sent between interrupts, so he implemented his re-extended protocol...

http://xep128.lgb.hu/files/xep128-entermice.exe

I'm not sure if it helps (the file name is missleading, since it's not Entermice yet at all ...). It tries to implement a watchdog with about 1500usec (timed by the Nick raster counter because it's "free" - almost - in the emulator to be implemented), but after reading 4th nibble, it "stucks" on the 5th, giving always zero and only the watchdog resets that on timeout. It seems SymbOS still work with this at least ... So I guess if I add more nibbles (eg Entermice stuffs) SymbOS will still work (I mean in this form with its 'boxsoft-only' method as well) as it queries mouse less frequently than the watchdog, so it will never "see" the extra nibbles. The :XEP EMICE stuff still works (as I talked about) but now it only toogles which lines the mouse use, it's nothing about the available nibbles. I am curious, if this changes anything for you.

Thanks for the lots of explanation. I guess, I start to understand it. I didn't know too much about thie "watchdog" and that was the reason I couldn't understand, what kind of 5th nibble etc in a 4 nibble "protocol", warping around, etc.

Offline pear

  • EP lover
  • *
  • Posts: 754
  • Country: pl
  • Z80 only
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
Re: Xep128
« Reply #24 on: 2016.March.19. 08:19:48 »
Watchdog is a timer which is started before beginning to wait for a long-term process.
If the process is completed at the expected time, the watchdog timer is stopped. Otherwise, the timer triggers an emergency procedure.
In this case, it has been used to reset the counter of nibbles after expire 1500 μs since of receiving last nibble.
« Last Edit: 2016.March.19. 08:25:11 by pear »

Online gflorez

  • EP addict
  • *
  • Posts: 2557
  • Country: es
  • OS:
  • Unknown Unknown
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #25 on: 2016.March.19. 09:19:08 »
Maybe if you study how NYYRIKKI implemented his Arduino Ps\2 to Msx adapter you understand fully the protocol.  The Arduino code is similar to C.  Take in account that EnterMice emulates the Neos-Boxsoft hardware, and it has inverted the \Select signal respect to a Msx mouse.


http://msx.fi/temp/mouse_draft.zip

Those are the changes that must be done in the code:

From:

void sendMSX(char c)
// Optimized for Atmel328
// NOTE: Fixed pins!
{
while (digitalRead(JoyPin8)==LOW) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c>>2)) & 60));
while (digitalRead(JoyPin8)==HIGH) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c<<2)) & 60));
}

To:


void sendMSX(char c)
// Optimized for Atmel328
// NOTE: Fixed pins!
{
while (digitalRead(JoyPin8)==HIGH) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c>>2)) & 60));
while (digitalRead(JoyPin8)==LOW) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c<<2)) & 60));
}

And also modified this:


void JoyHigh()
{
DDRD=(DDRD | 0x3C);
}

To:


void JoyHigh()
{
DDRD=(DDRD | 0xFF);
}

Online gflorez

  • EP addict
  • *
  • Posts: 2557
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
Re: Xep128
« Reply #26 on: 2016.March.19. 11:05:18 »
I'm sorry, but your second attempt is even more ungovernable with the mouse driver in Boxsoft mode. On the other side it works with SymbOS.

Online gflorez

  • EP addict
  • *
  • Posts: 2557
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
Re: Xep128
« Reply #27 on: 2016.March.19. 11:34:29 »
On the Arduino draft zip you must go directly to the MSXmouse.ino file. Then, in the code, ignore other options than EmuMode= 1, 2 or 3, as the program emulates other MSX pointer devices not related with Enterprise.

Mode 1 is the strictly Neos-Boxsoft-MSXstandard protocol(4 nibbles). Mode 2 is the extended protocol(eight nibbles) that still can work with programs that expect a simple mouse(4 nibbles). Mode 3 is a mixed Mouse(mode 2)+joystick emulation, not absolutely necessary on the Enterprise side.

Your target is EmuMode 2. I think that excluding the Arduino hardware aspects, the routine is very easy to implement on your XEP128 code.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #28 on: 2016.March.19. 14:46:30 »
Now the same http://xep128.lgb.hu/files/xep128-entermice.exe

Not so much change, and I have no idea why it does not work, but now you can configure your mouse at least. :XEP EMICE is gone, :XEP MOUSE is used now! There are six mouse modes, identified by a number. 1, 2, 3 means J-column query 2, 4, 8 bytes protocol, values 4, 5, 6 are the same but for the K-column. Default is mode 1, which should be the good old boxsoft.

Note, that without mouse grab (ie you clicked into the emulator window and PC mouse cursor is gone), the mouse emulation is not so much usable or correct ... Maybe you should try that before any mouse-related functionality is used. Though there is a try in emulator to detect mouse usage (even OSD shows that with SymbOS) it may or may not work with other software and/or mouse modes.

Also, I've commited the changes into github repository, so you can see the source here: https://raw.githubusercontent.com/lgblgblgb/xep128/master/input.c

I've tried to comment things, and so on. If you have time and mood please have a look, maybe it helps to identify problems. Now mouse_buffer is used, which is a 8 byte array according to the JPG image you have posted (and found in the wiki). On RTS signal changes, the nibble_counter increments, incrementation by two is one byte further in the buffer (the lowest bit of course is about low/high nibble selection). mouse_protocol_nibbles limits the buffer fetch (ie, read will provide nibble of zero if reached, not from this buffer anymore!) for the selected mouse mode, ie for boxsoft it's 4 (2 byte protocol, 4 nibbles). The key functions are mouse_read() which is called when port 0xB6 is read, and mouse_check_data_shift() which is called when port 0xB7 is written. watchdog is used with about 1500 usec timeout to reset the nibble counter.

SymbOS seems to work in all mouse modes where J-column is used, no wonder, as I guess SymbOS reads mouse from video interrupt or such, so watchdog resets the nibble counter before SymbOS has the chance to see "new" nibbles, even if the full 8 bytes (16 nibbles) mode (mousemode 3 in my emulator) is selected.

Even if this works in the future, it's still a task for me to update mouse_buffer, for extended buttons and wheel ... Of course it can be only read, if the correct mouse mode is selected, anyway ... Note, that currently, if mousemode is 1, mouse_buffer won't ever been read further than 2 bytes, even if you see there the next byte ... In mousemode=1 the next nibble will be zero if tried to be read. But if you use mousemode=2 for example, nibbles of bytes 3 and 4 are also read before the "constant" zero nibble answer.

Well, I've written this during the night :) I haven't looked too much about your new posts here, but I will :)
« Last Edit: 2016.March.19. 15:03:22 by lgb »

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #29 on: 2016.March.19. 21:48:05 »
Watchdog is a timer which is started before beginning to wait for a long-term process.
If the process is completed at the expected time, the watchdog timer is stopped. Otherwise, the timer triggers an emergency procedure.
In this case, it has been used to reset the counter of nibbles after expire 1500 μs since of receiving last nibble.

I see, that explains why SymbOS works even now, that - as I thought too - my watchdog implementation expires before new mouse query of SymbOS, so it will always read only four nibbles, even if I implement much more. Now, SymbOS seems to work, even if I enable 16 nibble protocol, but using the J-column (not so surprising that it won't work with the K ...).

Now what I can't see clearly: what exactly stops the watchdog. Only the data read, or the RTS signal change as well? I mean, my idea after reading many posts in this topic, that, after the expected nibble number (ie 4 for boxsoft, 8 for extended MSX) I must provide zero mibbles basically *forever*. So if I keep trying to read without giving chance for watchdog to expire and reset the counter, I will only read zeros then, till the lifespan of the whole Universe :) The *only* (??) way to to begin with 0th nibble again is to wait at least 1500usec so watchdog expires and it resets the nibble counter, so next nibble read will be again 0th nibble, and everybody is happy.

Now as gflorez noted, my implementation based on these ideas still does not work :( well, it's even more worse ... :-/ Even in boxsoft mode, where SymbOS works nicely, according my own tests. I basically have run out of ideas soon what I should done then ... I really pray for a more simple like parallel protocol :D OK, it's just my lameness, that I can't implement that, it's not the protocol's bad. Of course :)

Currently, I check expiration of watchdog only at read (of port 0xB6). So application can send RST pulses, but it does not affect at all the state of the watchdog. Hmmm, I have the suspect, that the problem can be with my code https://raw.githubusercontent.com/lgblgblgb/xep128/master/input.c

In mouse_read() I check the watchdog, if that expires I resets the nibble counter. However still, the *old* nibble is returned, which was zero (or some other if not all nibbles were read before). Maybe, with resetting the nibble counter, I should also provide a new value on read. But if it's true, I don't really understand why SymbOS still works and not confused by the "exra" zero. Now, I am more or less sure that my problem is about the exact "places" to reset / check watchdog, and similar things, that it does not comply to the rules ...