Uint8 mouse_read(void)
{
Uint8 data = _mouse_button_state ? 0 : 4;
if (kbd_selector > 0 && kbd_selector < 5)
data |= (_mouse_data_half >> (kbd_selector - 1)) & 1;
_mouse_pulse = 0;
return data;
}
Uint8 mouse_read(void)
{
Uint8 data = _mouse_button_state ? 0 : 2;
if (kbd_selector > 0 && kbd_selector < 5)
data |= (_mouse_data_half >> (kbd_selector - 1)) & 2;
_mouse_pulse = 0;
return data;
}
void mouse_check_data_shift(Uint8 val)
{
if ((val & 2) == _mouse_last_shift) return;
_mouse_last_shift = val & 2;
_mouse_pulse = 1;
switch (_mouse_read_state) {
case 0:
_mouse_data_byte = ((unsigned int)_mouse_dx) & 0xFF; // signed will be converted to unsigned
_mouse_dx = 0;
_mouse_data_half = _mouse_data_byte >> 4;
break;
case 1:
_mouse_data_half = _mouse_data_byte & 15;
break;
case 2:
_mouse_data_byte = ((unsigned int)_mouse_dy) & 0xFF; // signed will be converted to unsigned
_mouse_dy = 0;
_mouse_data_half = _mouse_data_byte >> 4;
break;
case 3:
_mouse_data_half = _mouse_data_byte & 15;
break;
}
_mouse_read_state = (_mouse_read_state + 1) & 3;
}
Please, can you add EnterMice emulation? I gave you the hints on the three previous messages.
There isn't a XEP128 thread in English and you said that your two emulators use similar approach to emulate the Boxsoft interface.
I've seen your attempt to implement an 8 nibbles protocol, but it is unnecessary, as a two buttons PS/2 mouse only writes four nibbles. You must put a 0000 on the fifth and subsequent nibbles, and the driver detects it and does the rest, waiting for the next reading cycle on the next interrupt.
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.
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:
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.
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.I thought about this when writing firmware.
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...
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...
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.
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.
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):
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.
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.
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 ...
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.
* 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 :)
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 :DIn EnterMice the number of available bytes is given explicitly (at 9th nibble). No need to look for nibble 0000.
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 :D 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.
* 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 eighth bit the PS/2 mouse provides.
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.
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.
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.
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.
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.
No, it doesn't print anything on the console.
Still no help string nor text. Sorry.
No, it doesn't print anything on the console.
If it has been built as a GUI application (-mwindows with MinGW), then it does not print anything on the console, that is a normal "feature" of Windows. On the other hand, when compiled and linked as a console application (by removing -mwindows), it will always create a console window when run, which can be annoying. If a Windows GUI application is run with Wine, then the console output is not lost.
Still no help string nor text. Sorry.
The only difference is, when I type the option "/h" or "/?", a little window opens warning about the use of "-" instead of "/".
Nothing more, sorry. Still no help text nor debug messages.
About your little warning window, there are two in reality, I have to click two times the OK rectangle in it. If I move it to other zone of the screen and click on the OK rectangle, the second little window appears on the original place waiting me to click OK again.
EDIT: The immediate mode has the same blink.
I have an idea. You can open a window to print debug text if it is set in the config, just like you print it to a file.
I hope this helps you...
I am again at home. We can continue testing if you like.
Don't worry I like boring stuffs...
This time is like the last one, but a console window has been added. It does nothing and closes itself when the XEP process closes, both if started from the console or from windows.
This time you are very near....
Both the wrong and the correct help create a new console window and write there the help text. The wrong one stops the text in the middle and produces the little warning window. I click OK and the remained text is written and a "click to close" little window appears just over the second created console. If I click on it, the second console closes.
Both if XEP128 is launched from the console or from Windows, it produces a brief second console, this time with text, but it is too fast to read something. When it closes, the emulator starts normal.
But, by now let's your sharp mind find how to do it....
It has worked at the very first time!
Even if it is set as an analogue joystick. The fire button is precisely the first of the 32 I can configure...
It seems that SDL treats analogue and digital lecture the same. I don't have a pure digital Pc joystick now, I have to look for it, sorry.
But I figure that a digital joystick gives you X=+32767 when Right is pressed and X=-32768 if Left. The same on Up and Down. Of course Centre gives you 0.
XEP CD C:\users\xyz\ep-files
LOAD FILE:sysext1.xr
LOAD FILE:sysext2.xr
As far as I can see, the snapshot format is expandable ... (maybe then it cannot be loaded to ep128emu ...).
ep128emu ignores unrecognized data blocks. The block types could be for example 0x584550XX, or anything that does not conflict with those that are already in use.
Yes, it works. I have saved and loaded a Basic program as usual.
The XEP DIR and CD commands also work.
A silly question:
Actually the Right Shift key is not defined on XEP128.
I assume that it could be done as this:
epkey@85 = Right Shift # SHIFT
I've been trying to add the new definition on the config file but then XEP refuses to start, showing an error "line too long".
How can I do it?
I don't think there are the line breaks, as I copied exactly the Left key definition, the following blank line and the carriage return from the original file, then I pasted it and at last I modified the line.
I use Notepad++ to edit text files, that supposedly doesn't modifies end of lines.... or at least I thought it.
When I only modified the single settings it stayed good, but adding one line more it has changed all the lines at reformatting the text.
But then I will re-assure that in my config the end of lines are as required, sorry for the inconveniences.
I've added a Link to the XEP128 emulator web page on the EnterMice wiki, on the list of compatible programs.
Lazy? You are not saying it seriously, aren't you?
Attempting with LOAD "FILE:" to enter the Windows file handler, XEP128 returns this error: "*** Host OS No file selected", and does nothing.
The other FILE:, DIR and CD commands, all work.
The little window shows:
"DEBUG: Windows CommDlgExtendedError: FFFFh"
And if I try on the root of C: it shows the same.
I have tried the former version on C: and it shows the same "*** Host OS No file selected" message.
Honestly, the idea is from ep128emu :) But not the implementation of course (ep128emu uses its own widget set, not native win32 functions, I think)
It uses Fl_Native_File_Chooser, which shows the native file dialog on Windows and Mac OS X, and the FLTK file chooser on other platforms.
Please LGB, how can I add the Epdos2.1 Rom to the combined Rom? or, does it exist a method to test a Rom on XEP128 without modifying the combined rom?
I have already created the Sram segment on 07.
00-0C ROM /home/lgb/vega/prog/xep128/combined.rom
0D-0D ROM (Xep128-internal)
0E-F7 unused
F8-FB RAM
FC-FF VRAM
RAM: 8 segments (128 Kbytes)
Dave: WS=no CLK=8MHz P=F8/FF/FF/00
xep128 -rom@00 /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
00-03 ROM /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
04-04 ROM (Xep128-internal)
05-F7 unused
F8-FB RAM
FC-FF VRAM
rom@00 = /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
xep128 -rom@00 /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom -rom@20 /home/lgb/vega/prog/xep128/rom/EPDOS-1.9-beta.rom
00-03 ROM /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
04-1F unused
20-21 ROM /home/lgb/vega/prog/xep128/rom/EPDOS-1.9-beta.rom
22-22 ROM (Xep128-internal)
23-F7 unused
F8-FB RAM
FC-FF VRAM
xep128 -rom@00 /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom -rom@20 /home/lgb/vega/prog/xep128/rom/EPDOS-1.9-beta.rom -ram @=07,F8-FB
00-03 ROM /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
04-06 unused
07-07 SRAM
08-1F unused
20-21 ROM /home/lgb/vega/prog/xep128/rom/EPDOS-1.9-beta.rom
22-22 ROM (Xep128-internal)
23-F7 unused
F8-FB RAM
FC-FF VRAM
RAM: 9 segments (144 Kbytes)
xep128 -rom@00 /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom -rom@20 /home/lgb/vega/prog/xep128/rom/EPDOS-1.9-beta.rom -ram @=07,F8-FB
rom@00 = /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
rom@20 = /home/lgb/vega/prog/xep128/rom/EPDOS-1.9-beta.rom
ram = @=07,F8-FB
rom@00 = @EXOS24UK-NOILLOPS.rom
rom@20 = @EPDOS-1.9-beta.rom
ram = @=07,F8-FB
I can move the Sram to other area, only poking the value into the Epdos2.1 Rom. Zozo said it.
Then, if I want to add the Epdos2.1 rom I must put it on the list like this:
rom@00= /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom rom@20=/home/lgb/vega/prog/xep128/rom/EPDOS2-1.rom
Isn't it?
With my own directories.
The @ character works very well and saves a lot of typing on the command line. I am able then to load the combined.rom at 00 and the Epdos2-1.rom at 20. The emulation starts, but as the SD image is not found the start-up ends on Basic without a medium to load a file. Xep commands hang the emulation.
Why this happens?
On the other side, attempting to load more than one rom by the config file gives me an error, as the two lines are parsed as only a continuous one. This a different error than the end of line one.
-rom@20 ~/Downloads/EPDOS2-1.ROM -ram @C0-CF,F3-F5,30-3f,40-4f,=50
00-0C ROM /home/lgb/vega/prog/xep128/combined.rom
0D-1F unused
20-20 ROM /home/lgb/Downloads/EPDOS2-1.ROM
21-21 ROM (Xep128-internal)
22-2F unused
30-4F RAM
50-50 SRAM
51-BF unused
C0-CF RAM
D0-F2 unused
F3-F5 RAM
F6-FB unused
FC-FF VRAM
RAM: 56 segments (896 Kbytes)
-rom@00 rom/EXOS24UK-NOILLOPS.rom -rom@20 EPDOS2-1.ROM -ram @C0-CF,F3-F5,30-3f,40-4f,=50
I have the suspect that though you changed your editor, your loaded the *bad* file (with bad EOLs) thus even your new editor won't be OK what to do with the already bad EOLs too much just extended with an extra byte further :) I guess if you changed editor, you need to delete your file and burn it :)At Tools/ Line endings can force select which mode needed.
CHR 10&13 on EXOS VIDEO: device, everything works as logical :-)
I tried to compile Paszians on XEP128 with Heass, but when I wanted to load the assembly within the program, Xep's file handler pops out and I can't access to the SD-image.
No. I've used the last test version you put in this topic.
Today at work I am able to use Heass inside your XEP128. No errors.
I can't understand why there are aspect that work on a computer and not on another. Both Pcs have the same XP installation.
I think that he best way to install Xep128 is..... to share a clone of my installation.
Yes, Xep doesn't need an usual installation to work, but it creates the config file on a fixed place that, on the other side, is different on every computer and version of Windows.....
Is for that I give importance in my explanation to copy the right path of the \nemesys.lgb\XEP128\ directory when the config. file is created.
This is not a complaint. Xep is OK for me as it is.
But, to make your emulator more easy to configure, why don't you put the config dir on the same dir where is the executable?
Also the files to use with FILE: are searched there and the Roms to install. The occasional user doesn't need to know the place, but if somebody wants to emulate complex things, it will be very important.
I understand your reasons. Of course I don't want to influence your future work with Android.....
Symlinks? I only know about "direct accesses", but I think they only deal with the Windows GUI, not with the deeps of DOS.
I have an idea, just like you create the config and the directory, put a direct access to the config directory on the executable dir.
Then the final user doesn't need to know where the config is.
Here is a copy of the direct access I use to reach the config dir. I have deleted the LNK tag it had, because windows doesn't treat it as a normal file.
Sorry, I've corrected the file.... I renamed the config file to config.bk to test the explanation. Then I forgot to reverse it...
My configuration is set to show the use of all programs related to EnterMice, so it is necessary to load the SPEMU128 Rom, 1024Kb of Ram for SymbOS and mouse mode 4.
Xep is complex, isn't it?
Complex to make it easy, yes. I was meaning that...
I only hope new users of XEP don't be overwhelmed by all that options at hand on the first execution...
This may be an obvious question but, how an EP128emu snapshot is loaded in Xep128?
Is that issue what I have read... I understood it as done, sorry.
Important..... nah.
Only that I would like to use more your emulator. There are "easy things" that we do with Ep128emu that we can't still do with XEP128. I only want your emulator be BIG.
I understand the incompatibilities, it is wonderful to try to converge the two emulators, but Ep128emu is stalled and yours not. Sooner or later your emulator will be more actual. I think you must look for your own snapshot while maintaining some short of legacy snapshot mode for backwards compatibility.
For me is also important if you make an OSX implementation of XEP128. No mater if actually there is only one user of it. I think that the best form of expandability of a program is its universality of use.
Now Xep128 can load ep128emu snapshots. Note, that it's still buggy as not everything is restored, ie internal dave/nick exact state, etc, only the I/O ports, memory and Z80.
For sure, there are serve issues if a snapshot from ep128emu uses EXDOS/WD as Xep128 can't emulate that currently ...
Most of the time it would probably be enough to restore a few internal registers, such as the interrupt state in DAVE, and the current LPB, and line and slot count in NICK. By ignoring unsupported block types, it would also be possible to load demo files as snapshots.
The WD state is not stored in snapshots, ep128emu just resets the floppy controller on snapshot load. Of course, this does not work if a snapshot is saved during a disk operation, but the lack of the original image file would cause problems then even if saving/restoring WD state was implemented.
I am glad to see that LGB's useful web page (http://ep.lgb.hu/) is again active, or almost...
May be you can mix what you have with what is stored on the WayBackMachine (https://web.archive.org/web/20180405015635/http://ep.lgb.hu/).Amazing!
Edit: But surely you already have thought on that...
LGB's useful web page (http://ep.lgb.hu/)Is there also a Primo Emulator for the Enterprise? I didn't remember.
May be you can mix what you have with what is stored on the WayBackMachine (https://web.archive.org/web/20180405015635/http://ep.lgb.hu/).
Edit: But surely you already have thought on that...
Also just to mention I'm not so active unfortunately in Ep topics nowadays, since i'm busy with this:Wow! I should visit you soon! :-)