Welcome, Guest. Please login or register.


Author Topic: Xep128 (Read 21769 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • 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 #60 on: 2016.March.21. 20:12:02 »
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 eighth bit the PS/2 mouse provides.

Well,  it's a signed 8 bit  I think, so the range is -128 ... 127. However it's still enough (?). But also note, that mouse seems (for me) still too fast in Xep128 window, this is because the motion event routine maybe scaled by PC screen size but interpreted by/for Xep128 then as a "normalized" value. So it's more easy (in theory?) to saturate the value.

Offline pear

  • EP lover
  • *
  • Posts: 697
  • Country: pl
  • Z80 only
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #61 on: 2016.March.21. 20:20:18 »
The Arduino code simply ignores that ninth bit the PS/2 mouse provides.
EnterMice read the full 9 bits and divides the result by 2.

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • 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 #62 on: 2016.March.21. 20:31:59 »
Ok, as I always say, I only "see" the problem from the EP emulation side, where I have 8 bits signed only :)

Offline pear

  • EP lover
  • *
  • Posts: 697
  • Country: pl
  • Z80 only
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #63 on: 2016.March.21. 20:41:39 »
Dividing 9-bit signed number by 2 the result has 8 bits (preserving sign) :)
You may also like that (replace MSB bit):
Code: ASM
  1.         mov     a,mouseX        ; X
  2.         rl      a
  3.         mov     c,mouseXsgn     ; insert 9th sign bit at MSB bit
  4.         rrc     a              
  5.         cjne    a,#080h,mc_negx
  6.         inc     a               ; for correct negation if X=-128
  7. mc_negx:
  8.         cpl     a               ; X:=-X
  9.         inc     a               ; result correction
  10.         mov     msxX,a          ; store delta X (positive is move left)
  11.  
« Last Edit: 2016.March.21. 20:52:21 by pear »

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • 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 #64 on: 2016.March.21. 20:58:15 »
Ok, besides the previous topic ... Now I have the plan to get rid of the problem of collusion joy-1 and J-column mouse (boxsoft). K-column entermice mode wouldn't be problem in the future :) But still is brothers me that I need to turn on/off joy emu etc and has something with the mouse too ... So, what I thought: sending a pulse on RTS would set set a variable, if reading port B6 see the value set, it assumed that (J-column, if K-column is the mode, I don't need this game) mouse is asked so I provide mouse stuffs, otherwise I provide the joy-1 stuffs. However this logic would fail, if some mouse user software would produce an RTS pulse then it would read port B6 multiple times for some reason, thinking that it will got the same value (as it would be without RTS pulse on a real stuff). Maybe I should limit number of B6 port reading times after an RTS pulse which counts as mouse (J-col) query. It would be nice that the guessing algorithm can provide emulation for both of joy-1 an J-col mouse without the need to manually "switch" between them (ie: mouse grab mode enter/exit).

OK, I mean a counter really needed, as with a pulse, port 0xB6 may be read about 5 times, to "scan" different rows of course (5?) ... A software wouldn't (hopefully) tries to read port 0xB6 more times ie reading the same scan row for some reason multiple times ...
« Last Edit: 2016.March.21. 21:04:12 by lgb »

Offline pear

  • EP lover
  • *
  • Posts: 697
  • Country: pl
  • Z80 only
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #65 on: 2016.March.21. 21:11:52 »
Between turning the RTS line and reading the data takes around 90 μs at first read and 65 μs all another.

Online gflorez

  • EP addict
  • *
  • Posts: 2415
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
Re: Xep128
« Reply #66 on: 2016.March.21. 21:57:39 »
When I ended the implementation of the EnterMice re-extended protocol I adjusted the delays to the minimum  "safe" time. As Pear says the delays where fixed at 90 μs the first read and 65 μs the following ones.

But for the versions data(ninth nibble onwards) I experienced errors whit that short delays, so I added more time. Take in account that the EnterMice nibbles are only read at the driver initialisation and when the information is demanded, typing the "MOUSE" command on EXOS.

Is for this that is not so important to emulate all the chain of nibbles, only up to the eighth one.

I've not put the complete mouse reading routine in the wiki, only the shortened 8 nibbles one. If you want to see how the long one works, it is on the Mouse.xr disassembly here.

Edit: I don't know if I have explained it correctly. Ninth and following nibbles aren't read always on every reading cycle, only the first eight nibbles.

The nine and following nibbles are only read if the EnterMice versions information is requested by typing the "MOUSE" command on the EXOS console.

On the other side the Entermice adapter is able to return the extra nibbles every read cycle if they are requested. Pear said once that the chain of nibbles can be extended to a big number, I don't remember how much.
« Last Edit: 2016.March.21. 22:11:53 by gflorez »

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • 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 #67 on: 2016.March.22. 01:01:32 »
My (now only private) development shows that the auto switch between joy-1 and j-column mouse emulation works nicely! I did this by introducing another watchdog. It's not mouse/entermice/hardware related unlike the nibble counter reset stuff, but Xep128's emulator-only based stuff. On each RTS changes it is started/cleared. On port 0xB6 read it's checked if more than 10000 usec passed since the last pulse. If no, mouse behaviour is emulated if yes, joy-1. Of course, if k-column is used (entermice) this is not needed at all. In this way SymbOS and EGI still seems to work. Moreover applications like EPDOS which were confused by mouse existence (j-column, because of expecting a joy-1 there) now are not confused: it does not provide RTS pulses, so Xep128 emulates joy-1 behaviour. A mouse aware application normally pulses RTS more frequently than 10000 usec (but maybe other value would be better ...) so it will get mouse mode while it does. And even if it stops doing that for a loooong time, the next RTS pulse will "pull back" the mouse mode. Also, in case of a "random" RTS change (ie some program do a pulse for whatever reason ... but not because it wants mouse) won't cause to stuck in mouse mode, because the new watchdog expires shortly. Also leaving mouse aware program results in expired emulation mode watchdog. Etc ... etc.

Now situation is more clean, mouse grab / no grab mode has *nothing* about the emulation mode any more! It merely only affects that mouse events are updated in the emulation or not. This also means, that mouse pointer does not move when you leave mouse grab mode, as the application still pulsing RTS so Xep128 provided the mouse emulation mode, just without any update on the movement/buttons from the PC mouse via SDL (only that needs mouse pointer grab).

Again, in case of mouse on K-column, this algorithm is not even needed as there is no conflict ... Currently my code chocks on this, and I would like to fix this issue as well ...

Online gflorez

  • EP addict
  • *
  • Posts: 2415
  • Country: es
  • OS:
  • Unknown Unknown
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #68 on: 2016.March.22. 01:21:33 »
I've been testing your sound implentation, and it is very good for me. The only problem are some clicks now and then even when in silence.

Surely you will find the problem soon.

On the last official win32 compilation the mouse movement seems to have being fixed, without the glitch when moving fast.

Thanks for all the effort you put  on your Xep128.

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • 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 #69 on: 2016.March.22. 01:59:39 »
I've been testing your sound implentation, and it is very good for me. The only problem are some clicks now and then even when in silence.

Well, that's the problem :) Currently sound is only an ugly hack (that's the reason audio is not enabled by default, it's so lame). Ie, the sampling rate is set to be about the same as Dave emulation "should" work. However since there is a slight difference (integer can't be float number ...) and also the load of the PC and the OS's scheduler to run Xep128, it won't be perfect ever, so audio buffer undeflow happens. Or at extem cases the opposite. Etc :) The correct solution would be the sound buffer state to be calculated into the main emulation sleep loop, but I haven't got the mood/time to deal with that too much :( Honestly, I am even surprised that audio is "so good" now if you consider the fact that it shouldn't even work this way too much :-/

Quote
On the last official win32 compilation the mouse movement seems to have being fixed, without the glitch when moving fast.

Interesting as nothing should cause changes there, hmmm. What you mean about "official"? The "-entermice.exe" or the regular xep128-win32.zip stuff?

Quote
Thanks for all the effort you put  on your Xep128.

Thanks for your help in mouse related topics :) Ep128emu is still more accurate and advanced by light years :) but unfortunately it does not support some things, like SD card, or well ... mouse, for example :) And also it's fun to try to write an own emulator, that's the another point ...[/quote]

Online gflorez

  • EP addict
  • *
  • Posts: 2415
  • Country: es
  • OS:
  • Unknown Unknown
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #70 on: 2016.March.22. 07:42:31 »
I mean the Xep128-win32.zip. May be it is glitch-free now because I am testing it on another PC?

It can be the sound is so good to me only because it exists.... It is a great step from the total silence.

You are reaching more and more milestones with Xep128. May be it is not accurate, but just now is a great emulator.

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • 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 #71 on: 2016.March.22. 23:54:46 »
I mean the Xep128-win32.zip. May be it is glitch-free now because I am testing it on another PC?

Not impossible ... as there is no correct sync with audio buffer and delay code it's maybe depends on many "random" things how it behaves ...

Quote
It can be the sound is so good to me only because it exists.... It is a great step from the total silence.

:D Sound drives me mad by the way, it's kinda hard to do it well :-/ It seems humans are much more picky about sound than even the video output. Eg if video output stalls for a frame in every one second or so, it can be noticable but maybe not so annoying. But if audio does this ... :D

Quote
You are reaching more and more milestones with Xep128. May be it is not accurate, but just now is a great emulator.

Well, yes, the good thing with that if you can do something you feel the power to solve another problem :D What can be bad, if you can't do it something too much for long time, the mood can go away to continue the whole work :-/ Especially with hobbies which are not "compulsory" and should be done for fun. This is the reason I start different parts all the time with Xep128, so I can find some place for improvement everywhere :) Like sound, it was a good try to have *something* ... then I started another thing, like better mouse support ... But I am sure I will go back to sound some time ... If you understand my point ;) Or maybe I am just an odd person to think that way ...

The old topic:

Can you test the new xep128-entermice.exe? Well it sould behave the same ... At least it shouldn't be worse ... But again I had to rewrite some parts of the code, it was already ugly. Now two joysticks with three buttons are supported, but of couse no code yet in Xep128 which can send the events for that ... Also, the "emulation mode watchdog" is implemented, so in case of colliding mouse/joystick-1 (if J column is used for mouse) Xep128 tries to detect with RTS pulses that it must be a mouse query but reverts back into joy mode if no RTS pulses for a longer time. Now (more or less as a debug) even OSD tells if control port emulation mode changes, you can see it. At least I tried that with EGI, SymbOS, and tested if EPDOS is not confused by the usual mouse existence, all of three seems to be OK, but I am not a good test person :) Also I tried only mousemode 1.

A new topic ... :-)

Another question, if I can have ... I don't have any windows. Funny, but I compile for Windows (with Linux) that I can't even test if works :) I also don't have experience (even not as a user ...) with windows. That's why I ask this: what happens if you start the exe from a console (DOS?) window? Does it print anything? I ask this, because mingw cross-compiler (basically gcc, targeted for windows, with limited posix emulation) supports -mwindows and -mconsole switches. According to the documentation, this sets a flag in the windows PE executable that it's a GUI or soncole application ... I really don't know that it does, honestly. I guess, in case of console app, window is always open if an application produces (textual) output on "stdout". SDL for windows sets that for -mwindows so I guess it won't happen now with Xep128 win32 builds, however I have no idea what happens if you run Xep128 from a "console" already :D Ok, maybe it was a stupid question ...

Online gflorez

  • EP addict
  • *
  • Posts: 2415
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #72 on: 2016.March.23. 00:55:25 »
You say: Can you test the new xep128-entermice.exe?  But I don't know what or where it is.

The last compilation I have(yesterday) is the Xep128.exe from your page, and it works good for me.

I've tested it from a Dos console and it works flawlessly. It opens the Xep128 windows the same and gives it the control. If you close the emulator then the control returns to the Dos console windows.

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • 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 #73 on: 2016.March.23. 01:12:28 »
You say: Can you test the new xep128-entermice.exe?  But I don't know what or where it is.

The usual place for that :) http://xep128.lgb.hu/files/xep128-entermice.exe
I mean that URL if I say "xep128-entermice.exe", but indeed, sorry for the not so clear statemant ...

Quote
The last compilation I have(yesterday) is the Xep128.exe from your page, and it works good for me.

Yes, but it is not the rewrite (again!! heh...) of mouse stuffs I mentioned. Unfortunately, it's hard to say "it's OK, leave it that way" because even if it works great, the code can be a mess which is a limtation on further development then. I often want to understand things resulting messy code, and if I understand, and works, I should rewrite in a much cleaner way :)

Quote
I've tested it from a Dos console and it works flawlessly. It opens the Xep128 windows the same and gives it the control. If you close the emulator then the control returns to the Dos console windows.

Ok, but I mean does it print messages to the DOS window, or anything? I mean things like this:

Code: Text
  1. Xep128 Enterprise-128 Emulator v0.3 (C)2015,2016 LGB Gabor Lenart http://xep128.lgb.hu/
  2. GIT 826ce8cd7728f004deee1374fe37c2e9988c2317 compiled by (lgb@vega on Linux 4.2.0-34-generic) at (Tue, 22 Mar 2016 23:22:53 +0100) with (gcc)-(5.2.1 20151010)
  3. Platform: (Linux) (32-bit), video: (x11), audio: (pulseaudio), SDL version compiled: (2.0.2) and linked: (2.0.2) rev (hg-8297:be2102f000d0)
  4.  
  5. PATH: executable: ./xep128
  6. PATH: SDL base path: /home/lgb/vega/prog/xep128/
  7. PATH: SDL pref path: /home/lgb/.local/share/nemesys.lgb/xep128/
  8. PATH: data directory: /usr/local/lib/xep128/
  9. PATH: Current directory: /home/lgb/vega/prog/xep128/
  10.  
  11. LICENSE: Xep128 is a GNU/GPL version 2 (or later) software. <http://gnu.org/licenses/gpl.html>
  12. LICENSE: This is free software; you are free to change and redistribute it.
  13. LICENSE: There is NO WARRANTY, to the extent permitted by law.
  14.  
  15. OPEN: trying file "@config-sample" [mode: r] as path "/home/lgb/.local/share/nemesys.lgb/xep128/config-sample" [pref-dir]: (fd=7) OK
  16. CONFIG: sample configuration @config-sample (/home/lgb/.local/share/nemesys.lgb/xep128/config-sample) already existis, skipping to create.
  17. OPEN: trying file "@config" [mode: r] as path "/home/lgb/.local/share/nemesys.lgb/xep128/config" [pref-dir]: *FAILED*: No such file or directory
  18. OPEN: no file could be open for "@config"

Of course the exact output would be different especially paths on Windows ...

Online gflorez

  • EP addict
  • *
  • Posts: 2415
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #74 on: 2016.March.23. 01:22:59 »
Sorry, I've realised that you put the new versions always in the same link.

Now I have tested it and your "emulation mode watchdog" discriminates correctly the use of the mouse or the joystick even in grab mode.

For example Manicminer is one of the games that doesn't work with a Boxsoft mode mouse(column J) connected on controler port 1. Now it works perfect.

Your Xep works better than the emulated machine...