Author Topic: Xep128 (Read 110189 times)

gflorez · « **Reply #30 on:** 2016.March.19. 23:41:10 »

The actual version of SymbOs doesn't care the fifth nibble, it stops requesting nibbles at the fourth. I remember well, I gave Prodatron the original Boxsoft four nibbles reading routine.

lgb · « **Reply #31 on:** 2016.March.19. 23:48:53 »

Quote from: gflorez on 2016.March.19. 23:41:10

The actual version of SymbOs doesn't care the fifth nibble, it stops requesting nibbles at the fourth. I remember well, I gave Prodatron the original Boxsoft four nibbles reading routine.

Yes, I know that, as my original naive mouse implementation did automatic warp-around to nibble zero after the last nibble

And SymbOS worked that way, so it could be the only explanation, I guess. If it would have read extra nibble, it would have been out-of-sync badly ...

gflorez · « **Reply #32 on:** 2016.March.19. 23:54:01 »

Please take a look at the Arduino code:

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

At the .ino file. Surely you find the answer there.

pear · « **Reply #33 on:** 2016.March.20. 07:59:53 »

Quote from: lgb on 2016.March.19. 21:48:05

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).

Exactly this is so (3 cases):
1) The original BoxSoft has no timeout at all (no watchdog, unless it have a monostable multivibrator with time less than 20 ms, triggered by the first change of RTS - I don't know). Always after four nibbles resets the counter.

2) In the extended MSX protocol (NYYRIKKI) after fourth nibble starts the timer with time of 3000 μs. If at this time there is no change RTS, the counter of nibbles is reset.

3) In EnterMice always after each change of the RTS is started timer/watchdog with time of 1500 μs. If during this time there will be no change on the RTS line (change on this line means the request to read the next nibble), the nibbles counter is reset.

lgb · « **Reply #34 on:** 2016.March.20. 14:42:11 »

Quote from: pear on 2016.March.20. 07:59:53

Exactly this is so (3 cases):
1) The original BoxSoft has no timeout at all (no watchdog, unless it have a monostable multivibrator with time less than 20 ms, triggered by the first change of RTS - I don't know). Always after four nibbles resets the counter.

2) In the extended MSX protocol (NYYRIKKI) after fourth nibble starts the timer with time of 3000 μs. If at this time there is no change RTS, the counter of nibbles is reset.

3) In EnterMice always after each change of the RTS is started timer/watchdog with time of 1500 μs. If during this time there will be no change on the RTS line (change on this line means the request to read the next nibble), the nibbles counter is reset.

Thanks. So besides of watchdog, what happens after all nibbles (for the given mode/protocol) is read? As far as I can see, in case of BoxSoft, the counter automatically warps around, so reading the last nibble then RTS change causes that again the first nibble is read. This is confusing, as - if I remember correctly - gflorez told, that trying to read another nibble with even original BoxSoft reads a nibble which is always zero ... Even EnterMice wiki says: "If the device only supports the BoxSoft protocol, the fifth nibble is always equal to 0000". Ok, but here then there is a conflict, that it reads zero or again the first nibble (because of - as you said - "Always after four nibbles resets the counter"). So I'm lost again

Of course the same question for extended MSX and Entermice as well ... The key question of mine is still: is it true that after reading the last nibble (for a given portocol) zero nibble can be read even if you tries million times, and the only method to start again is to leave RTS line alone for the watchdog expiration, so it can reset the nibble counter? Well, it seems it's not true for boxsoft as you said, or I don't know now, hmmm.

Here is a draft on mouse emulation modes in the emulator, of course it does not work yet this way, so it's only a plan (some of the mouse modes are meaningless maybe):

https://github.com/lgblgblgb/xep128/wiki/mouse-emulation#emulated-mouse-modes

Please note, that there is a possible confusing fact here. When I say "emulation in Xep128" I always think about the point of view of Enterprise-128 itself, what it can read/send in I/O ports. I am not so interested in Entermice internals or its communication with the given mouse, as for Xep128, it should emulate the behaviour of I/O ports only, used by software which would like to utilize mouse.

Currently, I extended the SDL event loop with extra buttons and mouse wheel, which is passed to the mouse emulation layer, so I will support that too. All of these plans, changes and even that wiki page of Xep128 is currently not found in the "released" version of Xep128 (neither in the github source repository) so it can't be tested now

Sorry, I really feel stupid. You and gflorez nicely wants to help, but it seems whatever both of you tell, I am not helped to much, and I simple can't understand this topic

Even gflorez's mentioned mouse_draft.zip couldn't help. Maybe this topic simply isn't compatible with my brain at all. Please tell, if I am already to boring with this topic again and again. I just would like to have good mouse support in an Enterprise-128 emulator

Thanks for all!

pear · « **Reply #35 on:** 2016.March.20. 15:03:31 »

The BoxSoft after the fourth nibble read out all 4 bits of data are set to 0000. I wrote that I don't know how exactly BoxSoft works. But it seems that it has a delay circuit.

I don't fully researched the extended MSX protocol, but certainly after the eighth nibble it also set all four bits to 0000.

EnterMice works a little differently, but retains compatibility. After each change in the RTS are issued successive nibbles of data and run watchdog (1500 μs). If before this time there will be no change in the RTS, all 4 data bits are set to 0000. The data buffer EnterMice has 16 bytes, but the firmware has been written so that it can be read any number of nibbles (even odd).
Additionally EnterMice uses the time after triggered watchdog to refresh data from the PS/2 mouse (for this reason is faster ready to re-read data).

Perhaps I tortuously explain, but I patiently explained as long as necessary

lgb · « **Reply #36 on:** 2016.March.20. 15:52:44 »

Quote from: pear on 2016.March.20. 15:03:31

The BoxSoft after the fourth nibble read out all 4 bits of data are set to 0000. I wrote that I don't know how exactly BoxSoft works. But it seems that it has a delay circuit.

Hmm, you see, these are confusing for me

When you say that boxsoft automatically warps around nibble counter of the last nibble, it's really not the same as what you say here that nibble zero is read. Anyway, I think it's simple does not worth to lament too much on this, EnterMice behaviour is enough for me.

Hmm, I think, if EnterMice is good enough

for compatibility etc reasons as well, I should not implement other mouse solutions, but only the behaviour of EnterMice, surely, in multiple modes (J/K column, etc). Since, if compatibility seems to be OK with Entermice and "old" software (not designed for Entermice originally) then it's a good solution. Anyway, from the view point of EP, still only some lines on I/O ports ... It's nothing from the view point of EP and its softwares how Entermice works _internally_ and its communication between the mouses. So what I would like is to have a good enough mouse support as it would be an Entermice card with a real Enterprise. With possible jumper settings etc. Just I worried that Entermice's boxsoft mode and real boxsoft mouse is the same enough existing software not to have problems ... I'm still not sure if it's a good strategy, but as far as I can see, nobody complained that Entermice has compatibility problems with software which cannot be resolved at least selecting the correct jumper settings maybe?

So, when I say "boxsoft mode" I more mean about the "mode" Entermice can provide.

A question: what's about that CPLD on the Entermice? Have you used VHDL (hmm, or Verilog)? If so, and it's available can I see the source, or it is not free in this manner? I 'speak" a very little VHDL, maybe that would help

I am very far from being a VHDL expert, but I can say, it's sometimes more easy to understand VHDL than C code which tries to emulate a hardware

No wonder, as VHDL is a hardware description language (HDL) while C is not

gflorez · « **Reply #37 on:** 2016.March.20. 17:04:52 »

Your point of view must be of an external device attached to the EP, not the EP ports point of view.

The device you want to emulate is a provider that only answers to the RTS signal(its input) putting nibbles on the joystick port(its output).

It doesn't matter what combination of hardware is connected. I have tested all the possibilities:

-Neos mouse with Boxsoft interface clone or the opto-coupler clone I made.
-MSX mouse with the Boxsoft opto-coupler clone I made, with the inverted Select signal.
-Ps/2 mouse with a Ps/2 to MSX converter I bought from Ebay, with the Boxsoft opto-coupler clone I made.
-Ps/2 mouse with an Arduino acting as Ps/2 to MSX converter, with the Boxsoft opto-coupler clone I made.
-Of course EnterMice, that can be adapted to all the previous controllers....

About mice I have connected a few of them, MSX Phillips, 1350 Commodore, FM Towns, and on the Ps/2 side everything that has fallen into my hands.

The driver has been adapted to read 4, 8 and more nibbles, both on the J and K columns.

It searchs for a 0001 fifth nibble, and then for a ninth nibble≠0000 to continue. It works with all the possible combinations of hardware.

pear · « **Reply #38 on:** 2016.March.20. 17:15:15 »

Okay, I admit, a little messed up. Sorry

EnterMice "Compatible with BoxSoft" mode is the only change the line from K to J. Nothing else.
The behavior of the firmware in both modes is the same.
From the point of view of the old software created for the original BoxSoft, both algorithms (EnterMice and original) give the same results.
At the same time I managed to improve the performance of the interface so that it can operate without any modifications with EP processor clocked in the range of 4 up to 10 MHz (it was the main goal which I set for myself).

Sources for CPLD are written in VHDL. It's free. Firmware source isn't.

Code: VHDL

----------------------------------------------------------------------------------
-- Company: 
-- Engineer:       pear
-- 
-- Create Date:    17:17:52 08/30/2015 
-- Design Name:    EnterMice logic matrix
-- Module Name:    EnterMice - Behavioral 
-- Project Name:   EnterMice
-- Target Devices: XC9572-PC44
-- Tool versions: 
-- Description: 
--
-- Dependencies: 
--
-- Revision: v3
-- Revision 0.01 - File Created
-- Additional Comments: 
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
 
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--use IEEE.NUMERIC_STD.ALL;
 
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
-- library UNISIM;
-- use UNISIM.VComponents.all;
 
entity EnterMice is
    Port ( KB : in  STD_LOGIC_VECTOR (9 downto 0);
           J1_Fire1 : in  STD_LOGIC;
           J1_Fire2 : in  STD_LOGIC;
           J1_Fire3 : in  STD_LOGIC; 
           J1_Up : in  STD_LOGIC;
           J1_Down : in  STD_LOGIC;
           J1_Left : in  STD_LOGIC;
           J1_Right : in  STD_LOGIC;
           J2_Fire1 : in  STD_LOGIC;
           J2_Fire2 : in  STD_LOGIC;
           J2_Fire3 : in  STD_LOGIC;
           J2_Up : in  STD_LOGIC;
           J2_Down : in  STD_LOGIC;
           J2_Left : in  STD_LOGIC;
           J2_Right : in  STD_LOGIC;
           M_Left : in  STD_LOGIC;
           M_Right : in  STD_LOGIC;
           M_Data : in  STD_LOGIC_VECTOR (3 downto 0);
           M_JoyMode : in  STD_LOGIC; -- 0=std mouse, 1=joystick mode
           KB_J : out  STD_LOGIC;
           KB_K : out  STD_LOGIC;
           KB_L : out  STD_LOGIC);
end EnterMice;
 
architecture Behavioral of EnterMice is
begin                                                                                                                                   
-- inverted logic - 0's active
        KB_J    <=      (M_JoyMode or KB(0) or J1_Fire1) and            -- Joystick 1
                                (M_JoyMode or KB(1) or J1_Up) and
                                (M_JoyMode or KB(2) or J1_Down) and
                                (M_JoyMode or KB(3) or J1_Left) and
                                (M_JoyMode or KB(4) or J1_Right) and
                                (KB(5) or J2_Fire1) and                                                 -- Joystick 2
                                (KB(6) or J2_Up) and
                                (KB(7) or J2_Down) and 
                                (KB(8) or J2_Left) and
                                (KB(9) or J2_Right) and
                                (not M_JoyMode or KB(0) or M_Left) and          -- Mouse in joystick mode
                                (not M_JoyMode or KB(1) or M_Data(0)) and
                                (not M_JoyMode or KB(2) or M_Data(1)) and
                                (not M_JoyMode or KB(3) or M_Data(2)) and
                                (not M_JoyMode or KB(4) or M_Data(3));
                                
        KB_K    <=      (not M_JoyMode or KB(0) or J1_Fire2) and        -- Joystick 1
                                (M_JoyMode or KB(0) or J1_Fire2 or not M_Left) and      -- Mouse button priority
                                (KB(5) or J2_Fire2) and                                                 -- Joystick 2
                                (M_JoyMode or KB(0) or M_Left) and                      -- Mouse in standard mode
                                (M_JoyMode or KB(1) or M_Data(0)) and           
                                (M_JoyMode or KB(2) or M_Data(1)) and
                                (M_JoyMode or KB(3) or M_Data(2)) and
                                (M_JoyMode or KB(4) or M_Data(3));
                                
        KB_L    <=      (KB(0) or J1_Fire3 or not M_Right) and          -- Joystick 1 (Mouse button priority)
                                (KB(5) or J2_Fire3) and                                                 -- Joystick 2
                                (KB(0) or M_Right);                                                             -- Mouse button right
end Behavioral;

gflorez · « **Reply #39 on:** 2016.March.20. 17:29:30 »

As Pear says, the two wired buttons are arranged different, but the movement is transmitted exactly the same on J or K common lines, on Boxsoft or EnterMice modes.

lgb · « **Reply #40 on:** 2016.March.20. 18:23:12 »

Btw, as I've said: mouse emulation only called if mouse is "grabbed" that is you clicked into the emulation window and your "PC mouse cursor" disappears (after a warning dialog box). Without that, reading port 0xB6 does not even call the mouse emulation related function, so no wonder if detection/etc of mouse fails then! It must be done this way, as some software do not work without that, fooled by the boxsoft/joystick collusion, like EPDOS. At least, Xep128 tries to detect, if someone wants to use mouse (ie: sending RTS pulses), it shows an OSD (On Screen Display) message that you may want to click into the emulation window to enable mouse usage. That works fine with SymbOS. However, it's possible, that other software may fail, because it tries to detect mouse, and its type, etc, so you are already too late to activate the mouse emulation. You may want to try your test (ie, before you load the driver, or anything!) in "mouse grab mode" before it even touch anything related to the mouse support!

gflorez · « **Reply #41 on:** 2016.March.20. 19:20:26 »

No problem with that case. The driver attempts to read, if nothing is connected it receives 255 and 255(0,0 as the port works inversely), interpreted as -1,-1. The pointer will go slowly to the right-down corner.

lgb · « **Reply #42 on:** 2016.March.21. 00:47:57 »

Well, I've rewritten most of the stuff now ... I have the suspect that it still won't work, I would be too lucky for that :-/ At the negative side, SymbOS stops working without going into "mouse grab" mode with click before starting it. If I start SymbOS in already mouse grab mode, it still works ... At the other hand, testing with SymbOS shows that now right button is the main button, I guess it's the natural way in the real case too, if I remember correctly ...

Win32 executable (hopefully your browser hasn't cached the old one or so?): http://xep128.lgb.hu/files/xep128-entermice.exe
Current source of mouse related stuff: https://github.com/lgblgblgb/xep128/blob/master/input.c
Source changes: https://github.com/lgblgblgb/xep128/commit/f45853b514afa72fa6e35871776149f35f74f713

I removed the ugly warning dialog box on entering mouse grab mode, it's annoying in my opinion, OSD still tells what happened. There is major re-organization of port B6 reading and so on too, not so important here. And if you see the source of input.c, now the mouse modes are defined and used from a quite detailed structure, so at least on source code level, it's easy to modify any parameters (even mapping PC mouse buttons, so buttons can be swapped, etc) for a given Xep128 mouse mode. Extra buttons and mouse wheel is supported (of course only if the choosen protocol supports that ...), though I haven't tested that, maybe it wouldn't work at all.

lgb · « **Reply #43 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 ...

lgb · « **Reply #44 on:** 2016.March.21. 01:57:17 »

Hmm, I've just checked the new version with the EGI SD card image you've posted, and it seems to work for me (again, right button is the main button). I've only seen EGI for glances, now it looks quite interesting especially the System window, and it's funny that I can type XEP commands too, so it's possible to eg modify mouse emulation parameters from there too

However I haven't tried that, just only starting EGI with the default "mode-1" of Xep128 ... Interesting, that it looks working even without mouse grab mode first, where SymbOS now seems does not work without the grab mode used before starting it ...

Author Topic: Xep128 (Read 110189 times)

gflorez

Re: Xep128

lgb

Re: Xep128

gflorez

Re: Xep128

pear

Re: Xep128

lgb

Re: Xep128

pear

Re: Xep128

lgb

Re: Xep128

gflorez

Re: Xep128

pear

Re: Xep128

gflorez

Re: Xep128

lgb

Re: Xep128

gflorez

Re: Xep128

lgb

Re: Xep128

lgb

Re: Xep128

lgb

Re: Xep128