Enterprise Forever

:UK => Emulators => Topic started by: gflorez on 2016.February.21. 01:37:04

Title: Xep128
Post by: gflorez on 2016.February.21. 01:37:04
I will better study the XEP code.

If I understand well, the "mechanics" of your code is to read the mouse and keyboard PC caption, and put the appropriate information on input ports B6h and B5h. Then the EP emulator reads the ports like on the real machine.

Making your emulators "EnterMice-movement compatible" is as easy as to clone bit 0(J column) on bit 1(K column) of input port B6h.

The buttons are a little more complex because the Neos mouse use only one button, the Right one, as main button, and you have put both buttons as main.

Making the EnterMice retro-compatible with the Boxsoft adapter(Boxsoft mode), Pear has implemented a secondary button, at the Left.

EnterMice on the other side has the main and secondary buttons put like on a PC. The mouse driver reads the Main and Secondary button depending on the mode selected, but it must be also done on the hardware(your emulator input.c I/O code). No problem as the Right button is always at the L column row 0. The Left is at the J colum on the Boxsoft and on the K column on the EnterMice.


As you say, by the moment there isn't any program that use more than one mouse button so, the fast solution is cloning bit 2(column L) and 1(column K) on row 0 of port B6h, similar to what I've said for the movement.

But Entermice has been made compatible with Prodatron's Extended MSX mouse protocol, and soon the port of SymbOS for EP will use the five mouse buttons and wheel that a PS/2 mouse can provide....  

----------

Now I only want to know why that jumpy movement with the actual mouse driver version. On real hardware it works, so it must be a little difference on sync.

---------

Useful? I don't mind if it is... Fun is what I look for... The fun of making things work properly.
Title: Re: Xep128
Post by: lgb on 2016.February.21. 02:49:53
For Xep128, _mouse_dx and _mouse_dy are for relative movement (d for delta) in X and Y directions. These are updated by SDL movement events, signed values. Function mouse_check_data_shift() is the key stuff in input.c. As you can see there is the _mouse_read_state variable which iterates over four possible values, two "half" bytes for X and two for Y directions. After X or Y is read, those delta values are zeroed. Well, this is what I could understand for MSX protocol + boxsoft, and it seemed that implemented this way allowed both for EGI and SymbOS to work using the mouse. I haven't mentioned the buttons here, but it's simplier case than the movements. Function mouse_check_data_shift() is called from cpu.c in _pwrite(), when 0xB7 port is written by the CPU, the mentioned mouse function checks if the bit changed (bit mask 2) in an "edge triggered" way (so if it changed only). When 0xB6 port is read, and it's for mouse (check function _pread() in cpu.c) function mouse_read() is called, it's in input.c of course. That uses the "half data" stuff set by mouse_check_data_shift(). It also set the button state bit using a variable set by SDL event handler for button change (up/down).

Or something like this :) I only wrote this, to help understanding/following my probably not so well structured code :)

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.
Title: Re: Xep128
Post by: gflorez on 2016.February.21. 17:36:50
This is the actual Boxsoft injection routine:

Code: [Select]
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;
}

And this can be for EnterMice:

Code: [Select]
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;
}

Fast compability can be achieved putting 6 for row 0 and 3 for rows 1 to 4, but Boxsoft can be incompatible with some programs that expect only a joystick on joyport 1. Is for it that the EnterMice is read on bit 1 and not on bit 0. Bits 1 and 2 where never used, except for the Boxsoft main button.

For now this is a fix for only the main button.
Title: Re: Xep128
Post by: gflorez on 2016.February.21. 18:32:48
And now for the "jumpy movement".

Code: [Select]
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;
}

As I said, EnterMice is compatible with Prodatron's extended MSX mouse protocol. This adds at least 2 more bytes on every lecture cycle. That makes 8 nibbles, not only 4 like on your emulator.  The extra lectures fool your routine because it  only sends 4 nibbles.

The Mouse driver then receives the correct movement alternated with (-1,-1) movement, as it reads 255,255(no movement) when it ask for the rest of the data.

You can fix the problem limiting the lectures to four on every lecture cycle(frame), just like the Neos mouse does.

If case is greater than 3 then you must put 0 on the fifth nibble . This indicates to the Mouse driver that  a two mouse button is connected, and it stops asking for more data.

This is enough for now.
Title: Re: Xep128
Post by: gflorez on 2016.February.21. 19:10:50
Only to check your emulator, here (https://www.dropbox.com/s/gn6sj8165ytep22/sdcard.rar?dl=0) you have your SD image loaded with the EGI and modified to auto-start on it with the actual mouse driver version.

It is set to Boxsoft mode(sytem var 189 set to 3) on the EXDOS.INI batch file, but you can change it inside FMAN on the EGI, with the Menu, EGI/System (: ).

Type  "VAR 189 4" to set EnterMice mode.

Then you can check the controller mode typing "MOUSE".
Title: Re: Xep128
Post by: gflorez on 2016.March.09. 23:29:15
Please, can you add EnterMice emulation? I gave you the hints on the three previous messages.
Title: Re: Xep128
Post by: lgb on 2016.March.10. 00:38:52
Please, can you add EnterMice emulation? I gave you the hints on the three previous messages.

Now I am a bit confused, your examples are code fragments in Xep128, however this is the JSep topic. Which emulator do you mean exactly?
Title: Re: Xep128
Post by: gflorez on 2016.March.10. 00:56:37
There isn't a XEP128 thread in English and you said that your two emulators use similar approach to emulate the Boxsoft interface.

Title: Re: Xep128
Post by: lgb on 2016.March.10. 01:02:16
There isn't a XEP128 thread in English and you said that your two emulators use similar approach to emulate the Boxsoft interface.

Similar, however I should know which one you are interested in still :)

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

In theory this is the version with the changes you've described, I have no idea if it works, SymbOS does not work this way, I've tested that at least.
Title: Re: Xep128
Post by: lgb on 2016.March.10. 01:21:14
OK, I have to overwrite the previous version ... Now it goes in the original 4 nibble, etc mode, but you can change it run-time with typing the following EXOS commands:

:xep emice
:xep emice 1
:xep emice 0

For query, set and disable Entermice mode. The same EXE above, the URL is my previous post.

The changes from the previous Xep128 version, so you can see:

https://github.com/lgblgblgb/xep128/commit/db5fa219951a182313a2b7170e8541dcb444d92d
Title: Re: Xep128
Post by: gflorez on 2016.March.10. 01:49:18
It moves jumpy... only if I press the main button... I will study your code tomorrow to see why.

Please use the SD-image I posted on 2016.February.21. 19:10:50. It contains an EGI initialisation that must work with the mouse driver. SymbOS only reads the Boxsoft interface.

The EGI starts with the internal Joystick as controller, but it can be changed on the mouse driver to Boxsoft or EnterMice with the system var 189.

:VAR 189 3 sets the controller to Boxsoft.
:VAR 183 4 sets the controller to EnterMice.

You can see the actual controller type with the command :MOUSE without parameters.

Thanks for your interest.
Title: Re: Xep128
Post by: lgb on 2016.March.10. 01:51:26
By the way ... Sorry, I don't follow every topic too closely recently because of other (official) works ... But do you have the mouse interface in the form of a ROM too?
Title: Re: Xep128
Post by: gflorez on 2016.March.10. 01:57:36
I would like to have the driver in Rom.... But I am just a beginner at Z80 coding.

Now the driver is very stable, I've removed several errors inherited from its creators and added some new features(Like the extra buttons and wheel). I go slooooowly.
Title: Re: Xep128
Post by: gflorez on 2016.March.10. 02:25:12
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.

You can see that the difference between Boxsoft and EnterMice is only the bit where the information is extracted, 0 or 1. It was moved to not collide with the external joystick 1, that is also read on bit 0.

Edit: The driver searchs for a 0000 on the fifth nibble. If found it is a two buttons mouse and it stops the reading cycle. If diffent of 0000 is read then an eight nibble protocol is expected. This is applicable on the Boxoft and EnterMice side.

Yes, also eight nibbles on the Boxsoft side, it may seem confuse, but in reality is was a simplification of the protocol when the extra buttons and wheel where implemented..
Title: Re: Xep128
Post by: lgb on 2016.March.10. 09:05:55
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.

Maybe, it's only me who is confused now :) You've written "that makes 8 nibbles, not only 4 like on your emulator". Now, in Entermice mode it does that, and as you can see with the "switch" construct, the first four nibbles are handles as it was before, and with the new "default" part it gives zero as the "new" last four nibbles.

https://github.com/lgblgblgb/xep128/blob/master/input.c

From line 95.
Title: Re: Xep128
Post by: gflorez 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...
Title: Re: Xep128
Post by: lgb 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.

Title: Re: Xep128
Post by: pear 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.
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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 :)
Title: Re: Xep128
Post by: lgb 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 ...
Title: Re: Xep128
Post by: gflorez 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....
Title: Re: Xep128
Post by: gflorez 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...
Title: Re: Xep128
Post by: lgb 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.
Title: Re: Xep128
Post by: pear 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.
Title: Re: Xep128
Post by: gflorez 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);
}
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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 :)
Title: Re: Xep128
Post by: lgb 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 ...

Title: Re: Xep128
Post by: 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.
Title: Re: Xep128
Post by: lgb on 2016.March.19. 23:48:53
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 ...
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: pear on 2016.March.20. 07:59:53
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.
Title: Re: Xep128
Post by: lgb on 2016.March.20. 14:42:11
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!
Title: Re: Xep128
Post by: 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.

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 :)
Title: Re: Xep128
Post by: lgb on 2016.March.20. 15:52:44
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 :)
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: pear on 2016.March.20. 17:15:15
Okay, I admit, a little messed up. Sorry :oops:

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
  1. ----------------------------------------------------------------------------------
  2. -- Company:
  3. -- Engineer:       pear
  4. --
  5. -- Create Date:    17:17:52 08/30/2015
  6. -- Design Name:    EnterMice logic matrix
  7. -- Module Name:    EnterMice - Behavioral
  8. -- Project Name:   EnterMice
  9. -- Target Devices: XC9572-PC44
  10. -- Tool versions:
  11. -- Description:
  12. --
  13. -- Dependencies:
  14. --
  15. -- Revision: v3
  16. -- Revision 0.01 - File Created
  17. -- Additional Comments:
  18. --
  19. ----------------------------------------------------------------------------------
  20. library IEEE;
  21. use IEEE.STD_LOGIC_1164.ALL;
  22.  
  23. -- Uncomment the following library declaration if using
  24. -- arithmetic functions with Signed or Unsigned values
  25. --use IEEE.NUMERIC_STD.ALL;
  26.  
  27. -- Uncomment the following library declaration if instantiating
  28. -- any Xilinx primitives in this code.
  29. -- library UNISIM;
  30. -- use UNISIM.VComponents.all;
  31.  
  32. entity EnterMice is
  33.     Port ( KB : in  STD_LOGIC_VECTOR (9 downto 0);
  34.            J1_Fire1 : in  STD_LOGIC;
  35.            J1_Fire2 : in  STD_LOGIC;
  36.            J1_Fire3 : in  STD_LOGIC;
  37.            J1_Up : in  STD_LOGIC;
  38.            J1_Down : in  STD_LOGIC;
  39.            J1_Left : in  STD_LOGIC;
  40.            J1_Right : in  STD_LOGIC;
  41.            J2_Fire1 : in  STD_LOGIC;
  42.            J2_Fire2 : in  STD_LOGIC;
  43.            J2_Fire3 : in  STD_LOGIC;
  44.            J2_Up : in  STD_LOGIC;
  45.            J2_Down : in  STD_LOGIC;
  46.            J2_Left : in  STD_LOGIC;
  47.            J2_Right : in  STD_LOGIC;
  48.            M_Left : in  STD_LOGIC;
  49.            M_Right : in  STD_LOGIC;
  50.            M_Data : in  STD_LOGIC_VECTOR (3 downto 0);
  51.            M_JoyMode : in  STD_LOGIC; -- 0=std mouse, 1=joystick mode
  52.            KB_J : out  STD_LOGIC;
  53.            KB_K : out  STD_LOGIC;
  54.            KB_L : out  STD_LOGIC);
  55. end EnterMice;
  56.  
  57. architecture Behavioral of EnterMice is
  58. begin                                                                                                                                  
  59. -- inverted logic - 0's active
  60.         KB_J    <=      (M_JoyMode or KB(0) or J1_Fire1) and            -- Joystick 1
  61.                                 (M_JoyMode or KB(1) or J1_Up) and
  62.                                 (M_JoyMode or KB(2) or J1_Down) and
  63.                                 (M_JoyMode or KB(3) or J1_Left) and
  64.                                 (M_JoyMode or KB(4) or J1_Right) and
  65.                                 (KB(5) or J2_Fire1) and                                                 -- Joystick 2
  66.                                 (KB(6) or J2_Up) and
  67.                                 (KB(7) or J2_Down) and
  68.                                 (KB(8) or J2_Left) and
  69.                                 (KB(9) or J2_Right) and
  70.                                 (not M_JoyMode or KB(0) or M_Left) and          -- Mouse in joystick mode
  71.                                 (not M_JoyMode or KB(1) or M_Data(0)) and
  72.                                 (not M_JoyMode or KB(2) or M_Data(1)) and
  73.                                 (not M_JoyMode or KB(3) or M_Data(2)) and
  74.                                 (not M_JoyMode or KB(4) or M_Data(3));
  75.                                
  76.         KB_K    <=      (not M_JoyMode or KB(0) or J1_Fire2) and        -- Joystick 1
  77.                                 (M_JoyMode or KB(0) or J1_Fire2 or not M_Left) and      -- Mouse button priority
  78.                                 (KB(5) or J2_Fire2) and                                                 -- Joystick 2
  79.                                 (M_JoyMode or KB(0) or M_Left) and                      -- Mouse in standard mode
  80.                                 (M_JoyMode or KB(1) or M_Data(0)) and          
  81.                                 (M_JoyMode or KB(2) or M_Data(1)) and
  82.                                 (M_JoyMode or KB(3) or M_Data(2)) and
  83.                                 (M_JoyMode or KB(4) or M_Data(3));
  84.                                
  85.         KB_L    <=      (KB(0) or J1_Fire3 or not M_Right) and          -- Joystick 1 (Mouse button priority)
  86.                                 (KB(5) or J2_Fire3) and                                                 -- Joystick 2
  87.                                 (KB(0) or M_Right);                                                             -- Mouse button right
  88. end Behavioral;
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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!
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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.
Title: Re: Xep128
Post by: 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 ...
Title: Re: Xep128
Post by: lgb 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 ...
Title: Re: Xep128
Post by: lgb 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 :)
Title: Re: Xep128
Post by: lgb 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 :)
Title: Re: Xep128
Post by: gflorez on 2016.March.21. 13:34:37
I want to answer your questions before testing the XEP128...


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.
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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 ... :D
* 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
Title: Re: Xep128
Post by: lgb 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).
Title: Re: Xep128
Post by: 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. 
Title: Re: Xep128
Post by: lgb on 2016.March.21. 17:15:37
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 :D
Title: Re: Xep128
Post by: pear on 2016.March.21. 17:23:05
* 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).
Title: Re: Xep128
Post by: pear on 2016.March.21. 17:26:22
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 :D
In EnterMice the number of available bytes is given explicitly (at 9th nibble). No need to look for nibble 0000.
Title: Re: Xep128
Post by: lgb on 2016.March.21. 17:34:53
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.
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: pear on 2016.March.21. 17:49:05
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.
It lets to preserve the full compatibility between protocols :)
Title: Re: Xep128
Post by: gflorez on 2016.March.21. 20:03:56

* 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.
Title: Re: Xep128
Post by: lgb 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.
Title: Re: Xep128
Post by: pear 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.
Title: Re: Xep128
Post by: lgb 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 :)
Title: Re: Xep128
Post by: pear 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.  
Title: Re: Xep128
Post by: lgb 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 ...
Title: Re: Xep128
Post by: pear 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.
(https://enterpriseforever.com/hardware/entermice-joy-ps2-mouse-interface/?action=dlattach;attach=13115;image)(https://enterpriseforever.com/hardware/entermice-joy-ps2-mouse-interface/?action=dlattach;attach=13117;image)
Title: Re: Xep128
Post by: gflorez 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 (https://enterpriseforever.com/programming/universal-mouse-driver/?action=dlattach;attach=14685).

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.
Title: Re: Xep128
Post by: lgb 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 ...
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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]
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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 ...
Title: Re: Xep128
Post by: gflorez 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.
Title: Re: Xep128
Post by: lgb 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 ...
Title: Re: Xep128
Post by: gflorez 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...
Title: Re: Xep128
Post by: gflorez on 2016.March.23. 01:27:33
No, it doesn't print anything on the console.
Title: Re: Xep128
Post by: gflorez on 2016.March.23. 01:41:22
Ok in reality the console launches it as an independent task, forget  what I've said before. I can have multiple instances of Xep128 launched from the same Dos console, all working independent.

I tried "help Xep12" and it returns "This command is not compatible with the Help utility. Try x /?"

But "xep128 /?" does nothing.
Title: Re: Xep128
Post by: lgb on 2016.March.23. 01:43:53
No, it doesn't print anything on the console.

Hm Windows is odd, really odd piece of beast ... Some kind of odd output buffering it uses according to some google searches by me. Please be so kind to do again now with the same URL as I've posted in my previous post (I've put some windows specific output buffering settings now, suggested by some MSDN resources ...). Also please try this: xep128-entermice.exe -h

So it prints the help (note, xep128 uses the standard UNIX notion for options ie minus sign, not the CP/M inherited then DOS then Windows / stuff) or not, also that it prints anything in case of "normal" emulation start, without command line parameters. Thanks a lot in advance.
Title: Re: Xep128
Post by: gflorez on 2016.March.23. 02:07:29
Still no help string nor text. Sorry.
Title: Re: Xep128
Post by: lgb on 2016.March.23. 02:18:18
Still no help string nor text. Sorry.

Windows is very odd, again, no wonder why I don't want to use it :D Ok, thanks for the tests, I will ask a Windows programmer I guess :D
Title: Re: Xep128
Post by: IstvanV on 2016.March.23. 09:24:35
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.
Title: Re: Xep128
Post by: lgb on 2016.March.23. 10:51:43
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.

Yes, thanks, I've just tried to get some information ... It seems a GUI application can "mimic" stdio with freopen("CONOUT$", "w", stdout); though it's not a true one, as it cannot be piped etc, and can only be seen if app was started from a cmd window. At the other hand, it seems there is some kind of AttachConsole() and AllocConsole() stuff where you can manually "play the game" to create console, forward stdio there etc. Confusing for me, enough ...
Title: Re: Xep128
Post by: lgb on 2016.March.23. 16:56:55
Still no help string nor text. Sorry.

And now? :) Same usual entermice exe ;) Of course if it's started from console and with -h switch.
Title: Re: Xep128
Post by: gflorez on 2016.March.23. 18:05:59
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.

Only two details I have  noticed: when XEP opens its window there is a little blink, a window of  the same dimensions opens, then immediately it is closed but then the definitive XEP window appears.

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.
Title: Re: Xep128
Post by: gflorez on 2016.March.23. 18:38:07
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.
Title: Re: Xep128
Post by: lgb on 2016.March.23. 20:32:01
The only difference is, when I type the option "/h" or "/?", a little window opens warning about the use of "-" instead of "/".

I did that because you mentioned that you tried to your /? :) But you tried -? and -h as well (and from cmd/console window, not in "Run ...", by typing there xep.....exe -h), and still no content? Very odd. I asked some windows experts :) and I tried to use native windows console management functions to attach to parent's console if exists (so if you start xep128 from a cmd window already) or create a new console if it's not the case. It seems somehow I would have had Windows to test myself otherwise this topic will be looooong and boring to ask you every time to test :D

Quote
Nothing more, sorry. Still no help text nor debug messages.

No debug messages, that's OK, now only help should have be seen (I only tried that for now!). But it's possible the console is there just disappears because end of the program? It may be even that blink you talked about! The odd thing that you started xep128.exe with -h option from a cmd window, it should attach that console and print there, instead of creating a new console ...

Windows is really ugly btw, its API too brrrrr ... It's a great thing that I don't need to interact with too many native Windows things thanks to SDL ... It seems Windows has some braindead policy to make a strict difference between "console" and "GUI" mode apps. And GUI mode apps does not have console, and extra tricks needed if you still need it ...

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

Hmm, that's "normal"l, though a bug of mine :) It's because the windows console attach function (which does not seem to work anyway ...) put the warning at the begining, but again with the normal command line parser finds the same problem :) So two windows actually after each other, that's why you need to click twice, thanks for notice!

Quote
EDIT: The immediate mode has the same blink.

Immediate mode? What do you mean?

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

Well, there are multiple problems here. First, it does not seem even if I can open a console by will :D Second: if someone wants to use command line, he wants to see the help. But if help can't be seen only with a complex switch :) then it's a chicken and egg problem :) Now I only try to make help visible but even that does not work, since Windows treats Xep128 as a "GUI mode app" and does not want to provide console ... The debug messages are not so important, what you can see (well, would see ..) on console, that's even stored in debug file if requested, so that's not the main point. The main point is the visible help message *and* later some console based monitor for the emulator.
Title: Re: Xep128
Post by: gflorez on 2016.March.23. 21:42:14
With immediate mode I mean running XEP128 without the console, directly from Windows. A brief window is opened and closed, and then appears the definitive one. The two are of the same dimensions.

When I run other Windows programs they only open one window.
Title: Re: Xep128
Post by: gflorez on 2016.March.23. 21:47:54
Some slavery remains between the little warning window and the console, because if I close the console while showing the warning window and then I click OK, another console is opened, but blocked, and I have to force it to close.


I hope this helps you...
Title: Re: Xep128
Post by: lgb on 2016.March.24. 00:19:31
I hope this helps you...

I wish it can help, but as you know now I am totally lame with windows even at user level I have no experience maybe since windows 3.1 for some hours :) Since then I never used windows too much just when eg my wife asked to help, but usually I couldn't. Which is funny at the other hand since I work for an Internet Service Provider (working/planning/implementing various UNIX system based solutions, firewalls, servers, etc) and even software developing sometimes, so I can't be totally lame with IT in general :-) Hey, life is odd, what my work couldn't force ever on me (to have attention on Windows, I always thought it's a "secretary"/gamer-guys/etc system mainly not a "serious" stuff ...) maybe Enterprise and its emulation can :-D at least a bit. Sorry for all here in the forum that I am boring with my feelings/life and being too honest :-P Hopefully nobody felt I want to insult with my opinion on Windows. I didn't mean that way.

Ok, after my touching novel on my feeling :) I put another version with the usual name "entermice" :) Now I put a dialog box at the end, so Xep128 won't exit after requesting help (with -h option) thus you have time to see (hopefully) if any console appeared, or any new content can be seen in existing console (cmd? cmd32.exe? I don't know what it is on Windows too much). If there is something, please be kind to copy all of the texts exactly, especially the first WINDOWS: line if you can see. From both of running "xep128-entermice.exe -?" from an already cmd/console window and running without it (hmm "Run dialog" of windows or such? I don't know).

By the way: http://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application/494000#494000

Really lovely how complicated on Windows to do a really simple task, not needed even to think on UNIX where GUI / console etc but regardless you use or not you always GUI and/or console have stdio if you need, let it be console or whatever you can imagine - via piped through ssh even through the Internet :)

I think, I need to stop this topic soon, since it's useless to be so off-topic with my windows problems and not-so-much EP related test questions all the time. :)
Title: Re: Xep128
Post by: lgb on 2016.March.24. 08:44:34
At the other hand, I "fired my Raspberry pi up" and tried to compile Xep128 on it (with SDL 2.0.4 which has support). Guess what, without a single bit changed in the source it compiled and worked! However the CPU usage is about 80% and audio is not even enabled (I can't test now, only HDMI is connected to my monitor). The high CPU usage is not so much surprised with that ARM CPU I guess ... Xep128 does not even emulate EP too well eg no interlace only 25FPS screen refresh etc, I am afraid Raspberry PI is just too slow for a decent emulation :( At least on the model 1 B+ ... I guess it would run better on later models, especially with the new model 3 ... But it's also true that still it's "real-time" just at the edge of the hardware performance ... and no optimization is done for the given CPU ...
Title: Re: Xep128
Post by: gflorez on 2016.March.24. 09:13:49
Still no good results. Only this time another little window opens when I type correctly the help option, "-h" or "-?". if the wrong help option is typed then I have to close the two warning windows plus the new one....

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

I am glad that you have compiled successfully Xep128 in ARM. It is a great step towards an Android build.....

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

I will be in the countryside for two days, no Windows to test there, only my Android tablet. I will tell you when I'm back, sorry.
Title: Re: Xep128
Post by: lgb on 2016.March.25. 09:54:28
Btw, in the Hungarian forum, I've posted a somewhat lame :) youtube video on running the stuff on Raspberri pi on a TV. Quite lame indeed, and boring, and not too much happens at the first part of the video.
Title: Re: Xep128
Post by: gflorez on 2016.March.25. 10:07:54
This is the link:

https://m.youtube.com/watch?v=n-qYMUGZaAs

For me is wonderful, that little Raspberry thing has "something" like an enterprise inside....
Title: Re: Xep128
Post by: lgb on 2016.March.25. 10:40:02
Indeed. This little machine would be especially fast for some semi-emulation. ie emulate a Z80 and leave it for free-run basically and have a modified SymbOS without too much actual hardware emulation of any machine or hardware besides the Z80 (even there, timing etc can be left out totally). Then it could be quite fast, and you have a fast SymbOS machine for example - even on a Raspberry Zero or similar quite "small" stuff. Of course a proper emulation of a hardware takes more time ...
Title: Re: Xep128
Post by: gflorez on 2016.March.25. 18:29:02
I am again at home. We can continue testing if you like.
Title: Re: Xep128
Post by: lgb on 2016.March.25. 20:56:24
I am again at home. We can continue testing if you like.

Thanks for being so keen, to be honest, I didn't want you to bother with these stuffs all the time. But since you offered your help (thanks!) you can try the current version with the usual xep128-entermice.exe URL :)
Title: Re: Xep128
Post by: gflorez on 2016.March.25. 21:17:29
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.
Title: Re: Xep128
Post by: lgb on 2016.March.26. 21:59:09
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.

OK, new version (usual place), it seems promising, as it produces window with content with "wine" at least, but I couldn't test with real Windows ... Now, unless help is requested, the console window will close automatically, but there is even a new "-conwin 1" switch (windows only) which keeps the console window open.

My adventures :) ---> http://stackoverflow.com/questions/36235641/console-output-stdio-does-not-work-on-windows-cross-compiled-with-mingw32

Btw, this version has some compiler specific optimization mode and variable / allocation alignment adjustments (it seems it's OK on x86 too to do, but especially on ARM/raspberry PI, it lowers CPU load from 80% to about 70%). Hopefully it won't cause any problems, it shouldn't ...
Title: Re: Xep128
Post by: gflorez on 2016.March.26. 22:32:14
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.
Title: Re: Xep128
Post by: lgb on 2016.March.26. 22:57:41
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.

I'm not sure if I understand fully, but maybe that's the expected behaviour you've described ...

Xep128 normally (now, I mean) tries to open a console whatever option you've used. If help is not requested, it will close on start of the emulation, so you'll see a console appearing and disappearing within a moment. If you want the console window to stay, you need to use the (new) "-conwin 1" switch. In this case, the console should remain during the emulation as well.

About the help: indeed, if you try '/?' it will warn you, and you can see only the part of the output, till you click OK on the warning dialog.

The important thing: if console was open (regardless because of help or -conwin 1 mode during the emulation) and Xep128 tries to exit, it should warn you to "click to close", this policy is introduced to be able to read the content of the console. Currently, Xep128 always tries to open a new console, it won't use the parent's one (ie: started from cmd window, which is already a console ...), since it's problematic to "mix" output of two programs into one console (because cmd.exe will continue to run, so output of both programs within the same console would be well "strange" and also makes impossible to future use of console - ie to able to input from there, with implementing some monitor-like program). Also, it seems it would be problematic to use the parent's console, if it's administrator privileged etc. I think it's a more clean way to always use an own console, and also it's consistent behaviour at least!
Title: Re: Xep128
Post by: gflorez on 2016.March.26. 23:20:50
Then, congratulations!

I forgot to say that always on XEP128 exit a warning little window opens and asks to confirm the closing. But I didn't mentioned it because it already happens since many versions. Is for that I said "starts normal", sorry.

Only for curiosity I will test that "-conwin 1" option.
Title: Re: Xep128
Post by: lgb on 2016.March.27. 00:23:48
Another challenge is try an Android build :) Just I am so lame with Android SDK , I couldn't even figure out, how it should be installed before even any Xep128 related work can be done then :-/ That's an interesting thing to do, because the code base is still native (ARM machine code) even on Android with SDL2, only a "wrapper" layer as Java class called "SDL activation" which basically pass control to the native code. Or something like that ... :)
Title: Re: Xep128
Post by: gflorez on 2016.March.27. 00:50:40
Your "conserve window" option works very well, all the action has its echo there.


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

I think Android is now more extended than Windows, with more future also. And over all, it is based on Linux. (It will not produce you allergy....)


Surely you have at least one Android phone near you to test..., but I would be glad to test your builds on several different Android devices searching for incompatibilities.

But, by now let's your sharp mind find how to do it....
Title: Re: Xep128
Post by: gflorez on 2016.March.27. 01:02:42
I realise now:

The common Android is based on Arm 32 bits, but there is also an Arm 64 bit and since a few years even an Intel x86 build.

This is, some Android phones sold today(mainly high spec ones), have processors that are compatible with x86 architecture.

http://www.androidauthority.com/arm-vs-x86-key-differences-explained-568718/
Title: Re: Xep128
Post by: lgb on 2016.March.27. 03:02:44
Quote
But, by now let's your sharp mind find how to do it....

Oh well. Android is Linux, at the kernel level, every other stuff is about nothing in common with a Linux OS can be found on a PC for example :) You can see, that SDL makes it easy to port stuffs, even to Windows or Raspberry Pi, and Android is also supported by SDL (btw, MacOSX as well ...). The problem is more related about the build environment and similar things.

Sharp mind of mine ahhhh, do you remember my difficulties to understand mouse related topics? :)

About the CPU issue: I guess 32 bit ARM code should run on 64 bit ARMs as well. About the x86, that's interesting, I haven't thought about it yet.
Title: Re: Xep128
Post by: gflorez on 2016.March.27. 03:15:50
You have understood on a week what cost me two years. At least sharper than mine....
Title: Re: Xep128
Post by: lgb on 2016.March.27. 13:01:57
Just to tell, what my idea is with this console window stuff ... The usual place/name (I mean the exe file) :) Console window closes on normal execution. Now if you press the numeric keypad minus button (during the emulation already), console is shown. You can see a prompt there (Xep128> ). In the future, it will be possible to give "monitor" commands. Now it does nothing, whatever you enter, you will only get back some feedback on entered line, and also Z80 register values (and Dave "MMU" registers) are printed. But it will be possible to use memory dump, disassembly, break point declarations, etc commands ... I'm not a big fan of GUI, as you know, I like more these kind of stuffs :) Also it's much easier to implement in a platform-independent way (without also using a custom widget library, or writing GUI for multiple systems with their native ones errrr ....) so it's about the same on Linux for example (just there, the console is standard I/O, no system level console window. For Windows it's a must, because of the Windows policy on strict enforced difference between "console" and "GUI" applications ... Interesting that I learnt about Windows more than ever before during developing Xep128 heheheheee ...).
Title: Re: Xep128
Post by: lgb on 2016.April.01. 16:48:40
I've just borrowed an X-box controller from a friend to write/test joystick emulation with real joystick/gamepad. It's funny, that it seems to work even connected to a Raspberry Pi :-D
Title: Re: Xep128
Post by: lgb on 2016.April.01. 18:17:03
If someone would like to try ... I can test windows build only with wine on Linux, it seems to work there. The "usual" -entermice prefixed distribution URL is used :-)

The "only" problem is mapping to controller events. Ie modern controllers have even about a dozen of button ID, axes, even "hats". For software, they don't know what are those buttons, axes, etc for real, only "button 1" or "axis 3", and these IDs means totally different things on different pads/joysticks, or even on different operating systems (maybe version dependent too ...) and drivers! Thus, now only there is a single hard wired config which seems to work here on Linux and X-Box controller, but that's all. It can be tricky to try to find, which controller element does "UP" or "FIRE" :) In the future, I would need some calibration possibility, so user can set it in an interactive way, then Xep128 stores that (also with the "GUID" of the controller - that's an identifier for a given controller -, so it will now that different controller needs another calibration ...) and can re-use it later.

Currently, only one gamepad/joystick is recognized with the fixed mapping I've talked about. Now, the events are distributed for both of the external joysticks on the same time, and still, numeric keypad can override, and can be used as an "external joystick". I'm also thinking on the possibility to have option for using game controller/joystick to emulate the internal joystick, but as we know, it's a different issue, as that's part of the "main keyboard matrix".

A hint: in IS-BASIC you can enter this command ":XEP showkeys" (also on the console/monitor window, without the :XEP part then, only "showkeys"). It causes Xep128 will give visual feedback (via OSD) about every pressed key and joystick emulation event. Now button #0 and axes #0/#1 are used only. Issuing the mentioned command again caused to turn this "debug mode" off.

In theory, Xep128 supports hot-plug (add/remove) the USB controller (try plug pad in/out while Xep128 is running), and it will show via OSD about the event. Anyway, not so useful, as only one config is used with the joy #0 on the system only.

Interesting, that SDL has some support for the "haptic" stuffs (I have no idea about the meaning of this word to be honest, SDL names that way ...), ie to "rumble" the controller. I have no idea if it's useful for anything for an Enterprise emulator :)
Title: Re: Xep128
Post by: gflorez on 2016.April.01. 21:51:08
I can test some controllers, even analogue ones, only I have to search for them.

I have at hand one of this HID controllers (https://www.ultimarc.com/minipac.html) to play with MAME (http://mamedev.org/) old acade games. I can try this now. It is completely configurable, so may be I can mimic the Xbox pad settings. Let's see...
Title: Re: Xep128
Post by: gflorez on 2016.April.01. 22:57:56
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...
Title: Re: Xep128
Post by: lgb on 2016.April.01. 23:04:38
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...

In SDL joystick interface at least, I always gets axis information as a 16 bit signed integer ... I tried to use some "clever algorithm" (not so much a big deal anyway, just I don't know the exact word for this in English) to avoid "bouncing" between values at a given limit, ie, the a higher level is needed to set joy direction to 1, but releasing the handle a lower limit needs to hit to fall back to zero. Currently, the high limit is 20000 and low is 10000. Of course the same at the "opposite" (negative) direction for a given axis.

You can see some values, if you enable that showkeys mode, I've mentioned though ...

Xep128 emulation allows three fire buttons btw ... Just it's not "configured" to do so :) Some configuration possibility is a must, ie, even allowing to use EP external joy 1-2 as two handled on the same pad, or from two different pads, etc, the joystick emulation abstraction layer in Xep128 (between the emulated EP and the SDL level functionality) would allow this ...
Title: Re: Xep128
Post by: gflorez on 2016.April.01. 23:25:08
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.
Title: Re: Xep128
Post by: lgb on 2016.April.02. 00:04:33
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.

Something like that, but I guess not exact values always, eg user can't push for +32767 totally or plastic case deformed, whatever :) The other issue with analogue stuff, that treating that as a digital (I need that, since EP use that ...) creates some odd "bounces" between phases near the limit, that's why I implemented the increasing limit and decreasing limit as a separated values, what I've already written about in one of my previous posts.

I have really no idea what digital joysticks behaves from the point view of SDL ... Even on the X-Box controller I borrowed there is that (well I am not a game expert, do not laugh ... a lot, at least) stuff, like a + sign. That it seems generates "hat" events, I don't know what is the correct notion. It seems it's another control type besides buttons, and axes. I don't support hats currently ... Hopefully a digital USB joy wouldn't behave as hat, or I should implement that too :) There is another control type left: "ball". Again, I have no idea what's that :) According to the documentation of SDL it gives relative X, Y motion info, so I guess it's something like a trackball, or whatever :) So, an upside-down mouse :D
Title: Re: Xep128
Post by: gflorez on 2016.April.02. 00:42:34
Yes, it is for a mouse or a trackball. You can have several mice connected to a PC, this is,  electronically they are individual, but stupid Windows treats all of them as the same. In MAME simulators you can have one mouse for every player of a game.
Title: Re: Xep128
Post by: lgb on 2016.April.02. 16:56:29
Ok, the new version supports "hats" as well. To be able to re-use code and decrease complexity, they are mapped as "virtual axes". But should work the same way. Now that's shame that Xep128 is hard-wired to use axes 0 and 1 for joy emu, so it does not help too much to have support :) Even without "calibration" (user friendly way) I need to implement a command line config option to set axis numbers for joy emu, at least :)

But at least with enabled SHOWKEYS mode (:XEP showkeys) you can see the events also with virtual Y/N info as well (Y for hats, mapped to axes after the "real" axes reported by the joystick/controller). It can be also useful if it turns out that true digital USB joysticks implements only "hats" ... As hats seem to be digital, indeed, only positions like up, upright, etc, no other info like with "axes".

And btw: it seems I like useless things :) Now there is haptic/rumble support as well :D On the first joy scan from EP software makes Xep128 to send a rumble event to the controller, if it does support it at least. Not so much useful, just I was curious :)
Title: Re: Xep128
Post by: lgb on 2016.April.07. 17:03:28
http://xep128.lgb.hu/

Newer "official" build. There is even some ChangeLog link there.

I think, maybe the most interesting feature is the ep128emu-like FILE: support. That is, it's possible (only LOAD now!) to LOAD programs directly from the host OS. It can be useful when testing software, no need to write to SD image first, etc etc, but it can be loaded directly from Windows/Linux, or whatever the emulator runs on. In theory, it's even possible to include EXDOS.INI (I haven't tested yet!!) on the SD card image with commands like this:

Code: [Select]
XEP CD C:\users\xyz\ep-files
LOAD FILE:sysext1.xr
LOAD FILE:sysext2.xr

... then Xep128 will execute the CD XEP command (which selectes the directory the FILE: functionality uses, the parameter is a host OS - ie Windows - directory with drive letter etc), then tries to LOAD something from there. The CD stuff is needed as there is a limitation of EXOS file name length, would be surely too short with full "windows" path for LOAD ... Btw, the default directory for FILE: is the files sub-dir inside the preferences directory.

See the "ChangeLog" link at the page above for more details. Please note, that it seems Win32 API has some surprises, ie I guessed unistd-like file read/write functions are unbuffered etc compared to fread() and friends. Well, it seems not on Windows ... Without the O_BINARY flag, there were serious problems with "truncated" reads etc ;) Hopefully it's OK now, at least it works for me tested with wine on Linux.
Title: Re: Xep128
Post by: gflorez on 2016.April.07. 18:20:12
Thanks for the Skiplogo option!

I must try an try the EDCW extension and it is annoying mandatorily to press a button to start.

Soon a mouse-click has to be implemented to skip the logo.....

Also thanks for the host LOAD, CD, and DIR commands. They work great for me.
Title: Re: Xep128
Post by: lgb on 2016.April.07. 18:37:16
My future plan with the whole stuff:

First, implement snapshot support. Eg even loading ep128emu snapshot. Though saving snapshot it's problematic, that it can't carry all the information, eg what ep128emu can't emulate (SD cartridge, mouse, ....). As far as I can see, the snapshot format is expandable ... (maybe then it cannot be loaded to ep128emu ...).

Second, "fastboot" option. Ie, if the configuration (ROMs, RAM size, etc) hasn't changed (and fastboot option is used), XEP ROM tries to load an already saved snapshot, or create one at XEP ROM init time. Thus, next time of starting emulator with the same config, it's possible to get to a working machine more quickly without waiting for EXOS memory test, SDext init, etc etc.

Then, a "load" option, which is implemented by XEP ROM again, to allow specify file to LOAD in the command line. Personally I would love to test my EP programs this way, almost no time lost, and my program loaded from the host OS file system directly ... Without need to wait for EXOS, writing to that to the SD card image first, typing to LOAD in the emulator, etc ...
Title: Re: Xep128
Post by: IstvanV on 2016.April.07. 18:53:36
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.
Title: Re: Xep128
Post by: lgb on 2016.April.08. 14:27:24
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.

I thought somehow ... It's nice you implemented an extensible format :) But surely, I remember something from JSep where I implemented of loading ep128emu snapshots. I guess it's useless to invent a new format by myself :)
Title: Re: Xep128
Post by: lgb on 2016.April.11. 02:09:02
Gflorez, would you be so kind to test the new (well, I stuck with the -entermice.exe name somehow ...) version? I had to rewrite most of the part about FILE: handling, and I am not so sure if it still works on Windows ... In theory it should even allow to save/write something with FILE:, not jist load/read now ... Thanks!
Title: Re: Xep128
Post by: gflorez on 2016.April.11. 03:05:04
Ok, but you have to wait until tomorrow, as I am now on the tablet.
Title: Re: Xep128
Post by: gflorez on 2016.April.11. 11:13:57
Yes, it works. I have saved and loaded a Basic program as usual.

The XEP DIR and CD commands also work.
Title: Re: Xep128
Post by: lgb on 2016.April.12. 20:51:56
Yes, it works. I have saved and loaded a Basic program as usual.

The XEP DIR and CD commands also work.

Thanks! Another write support, just now on the SD card image (I mean that EP should be able to also write not just read the emulated SD card) not FILE: ;-)

http://xep128.lgb.hu/files/xep128-sdext-wr-test.exe

Warning, there is no guarantee that your SD card image won't be corrupted, etc, please back it up, if it's important :) Though I haven't seen any issue like this, but who knows with new stuffs, safety first ;)
Title: Re: Xep128
Post by: gflorez on 2016.April.12. 22:44:43
I don't see any error. All goes like it should be. I mean, it saves and loads perfectly what I've saved before.

Congratulations!
Title: Re: Xep128
Post by: gflorez on 2016.April.14. 11:00:51
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?
Title: Re: Xep128
Post by: lgb on 2016.April.14. 13:07:21
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?

Actually, you seem to do it well. Line too long is a bit odd error. I guess there is some confusion with the fgets() function that for some reason it reads more than one line as a single one. Please send me your config file, I am curious. I need the exact file, maybe the line breaks (eg \r\n or \n) etc, can be the problem. And thanks for mentioning it, I will include the definition in the standard config too, somehow I forgot, it seems ...
Title: Re: Xep128
Post by: gflorez on 2016.April.14. 13:33:47
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.
Title: Re: Xep128
Post by: lgb on 2016.April.14. 19:36:43
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.

Well, that's odd. Just check the file out with a hex editor/viewer. It seems line endings are 0xD characters, I doubt Xep128 can write such a template config file ... In theory, Xep128 writes "native" line endings, ie in case of Windows CRLF endings (0x0D 0x0A), and just 0x0A in case of UNIX-like systems. Your file contains line ending other than either of these ... I have the suspect that your editor messed up the line endings on save, but I have no idea why. Xep128 simply uses the C89 standard fgets() function to read lines. With these non-standard line endings cause that fget treat your whole file as a single line, as it cannot identify any line endings to form more lines. Thus you have a quite long line, which causes the error message that line is too long. Even your file is shorter :) still it's meaningless as it shouldn't be *one* line (or more, but with invalid line endings). Please note, that this is an operating system + operating system library (ie, Windows or Linux and their standard libraries) issue, nothing to do with Xep128 too much ... Of course I can work-around this anyway with using own line reader routines instead of the functionality of the host OS itself ... But still, it's kinda odd, how can you produce such a line endings :)
Title: Re: Xep128
Post by: gflorez on 2016.April.14. 20:14:30
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.
Title: Re: Xep128
Post by: lgb on 2016.April.14. 20:32:26
I use Notepad++ to edit text files, that supposedly doesn't modifies end of lines.... or at least I thought it.

Exactly, that's the headache for me. Many editors has the ability to detect line endings and using that while editing. ie, then you can edit Windows created text files on Unix, or vice versa. What I can't understand why (in your code) notepad++ converted existing line endings to new ones, instead of detecting the right one and use that? Especially since those are "native Windows" EOLs, we can't even say that it's "alien" for Notepad++ to have UNIX-style EOL on Windows ... I tried to be careful to use "native" EOLs on both of UNIX and Windows in config files, and console/monitor writes as well to avoid possible problems in the future. It seems I failed with this task :)

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

Don't say that ... A user is not expected to deal with line endings, when he is interested in an emulator only :) Just I'm really surprised with these line endings, as it would disturb every single programs using C standard fgets() then, not just Xep128 ... This line endings were popular maybe in pre-MacOSX (MacOS 9?) era, I guess ... Interesting.

Btw: http://superuser.com/questions/479756/eol-in-notepad-and-notepad

Isn't that possible that at some time, you set some fixed EOL in notepad++ thus that's why it converted all EOLs for you?
Title: Re: Xep128
Post by: Zozosoft on 2016.April.14. 20:47:47
I use Programmer's Notepad (http://www.pnotepad.org/). It is can use Windows (CRLF), UNIX (LF), Machintosh (CR) line endings, and easy to convert the text to any version.
Title: Re: Xep128
Post by: lgb on 2016.April.14. 21:22:10
Ok, new Xep128 version, now at the standard :) distribution zip for Win32 build. It contains by default now the right shift as well. it seems somehow I missed to include in the default mapping :oops: Thanks for spotting! Also it contains the already experimental stuff, FILE: load/save, and SD card write ability on VHD image level.
Title: Re: Xep128
Post by: gflorez on 2016.April.16. 11:41:35
I've added a Link to the XEP128 emulator web page on the EnterMice wiki, on the list of compatible programs.
Title: Re: Xep128
Post by: lgb on 2016.April.16. 18:57:23
I've added a Link to the XEP128 emulator web page on the EnterMice wiki, on the list of compatible programs.

Nice to see, thx! :) Now I should step over my lazy attitude, and build a usable EP setup to use my EnterMice for real at the first time too :) I guess ...
Title: Re: Xep128
Post by: gflorez on 2016.April.16. 20:19:10
Lazy? You are not saying it seriously, aren't you?

What happens is that always there are other things that capture your mind, something to attempt, or fix, or even learn. The EnterMice is already done, not attractive enough  when there is so many knowledge to acquire.
Title: Re: Xep128
Post by: lgb on 2016.April.16. 20:30:48
Lazy? You are not saying it seriously, aren't you?

I'm :) I'm the kind who can wait even years (!) to start something, and just thinking/dreaming about that. It's another question that if I really start at last, I can work with that during nights, etc :) It's even true for Xep128, the first version with different name has been started around 2000 (!) then I didn't have any work on it too much till 2015 ... When I restarted from zero, with new name, etc. Then again a large pause, about half a year, doing nothing. Nowadays I am quite OK with it. So you see ;) I can lost my interest too easily, or not even get it really :) That's why it's nice if I get requests what others would need into Xep128, so I have some work to keep my lazy me away :)
Title: Re: Xep128
Post by: lgb on 2016.April.17. 13:01:04
Though I promised that I never want to write any advanced UI other than command line, monitor console/prompt, OSD, whatsoever ... Well things can change :) I guess nobody worries too much in this case, if I change my mind ...

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

In this version I tried to utilize native Win32 API file selector function. It means that with loading something with FILE: but with empty file name, an open dialog box will appear to allow to select a file to load. I mean:

LOAD"FILE:super.bas"

This still should load super.bas without any further interaction from the user (if file.bas can be found in the current FILEIO - host OS - directory of course ...).

However now, you can say this too:

LOAD"FILE:"

In this case, since filename part is empty, Xep128 (at least the test version only for now!) should display a native Windows open file dialog, and you can select what you want to load. Moreover, if you move to another directory, it should be remembered, ie then even the :XEP DIR etc should reflect the change that the new FILEIO host OS directory is the one you loaded program from at the last time. Honestly, the idea is from ep128emu :) But not the implementation of course (ep128emu uses its own widget set, not native win32 functions, I think). On Linux, GTK is used by the way.

Warning, this can be buggy: it seems there are issues (sometimes?) that window/GUI events "escapes" from native widgets to SDL events, ie selecting a file etc, and then Xep128 interprets some of the old interactions (ie key presses) by itself too, like "stucking enter key" if you used enter in the file dialog box, whatsoever. Or even entering into mouse grab mode, since the mouse click is detected by SDL/Xep128 later ... I think I will try some "SDL event queue emptying" solution after using non-SDL stuffs in Xep128. It seems GTK/Linux case is more affected by this than on Windows, by the way.

I plan to re-use file selector for various other things later, ie changing SD card image, also for FILE: save at some point (now it's not handled). If this native GUI elements thing seems to be OK, later it's even possible to present a GUI solution for the disassembly/memory dump etc stuffs (which exists already but only in console/monitor, and XEP: interface), so at some point it will be possible to use debugger like functionality in a graphical window. Who knows if I have willpower to do, especially in this way, with cross-platform GUI aware way, ie both on Linux and Windows. My tests on Windows version is done with the "wine" on Linux only as usual. So there can be issues I can't see this way :)
Title: Re: Xep128
Post by: gflorez on 2016.April.17. 15:16:45
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.
Title: Re: Xep128
Post by: lgb on 2016.April.17. 15:25:38
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.

Sorry for the possible silly question, but are you sure you used the test version whose URL I provided (not -entermice this time, but -test). It should provide an open file dialog window, however if you does not select a file there (ie: cancel, etc), then you will get that error, that's right. However if you choose a file, Xep128 should be able to load it then. If there were no file selection dialog box at all, something interesting happens (compared to my test with wine ...) or the other possibility that you tried another version of Xep128 not the one I mentioned :) But again, that's my bad, that I want to blame you at the first glance using the wrong exe, instead of myself to find the bug :D Sorry :)
Title: Re: Xep128
Post by: gflorez on 2016.April.17. 16:04:57
I reassured of it to be the indicated one  downloading it a second time, sorry.
Title: Re: Xep128
Post by: lgb on 2016.April.17. 16:20:48
I always feel amused about the great problematic stuffs when doing even the simpliest thing with Win32 API :) Even following MSDN descriptions closely (and at the end it turns out there are cases even Microsoft does not document to well. That's one reason I hate Windows ... not logical at all, not well documented, etc). Anyway :)

I tried to compile another version (put online with the mentioned URL for now), this should display a window about error code from dialog box. Hopefully at least that window is shown for you and we can see then what kind of numeric error code I have to deal with :-D And thanks for your tests again!

Btw a thing what you can try though besides the basic problem (which I would like to know what kind of error code is shown): change FILEIO directory to C:\ or whatever (with :XEP CD) and try FILE: with empty file name again then, if it cause any difference ...
Title: Re: Xep128
Post by: gflorez on 2016.April.17. 18:49:08
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.
 




Title: Re: Xep128
Post by: lgb on 2016.April.17. 19:21:05
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.

FFFF phewww ... That's the general error code (CDERR_DIALOGFAILURE) that something is wrong but not specified what. Windows is really smart about error handling, I must say :D I would like to get another error code (there are bunch of them - with "nice" exact meaning, but really FFFF is the worst ...), but that's life. I never understand why people wants to use Windows, really (sorry, that's not an offensive thinking against you or anybody, just I am a bit sad ...) . But hey, at least I am not bored :-D Ok, I guess I will "steal" my wife's notebook she has some old aged Windows XP at least :-)

Hmm. Again like with console window, I am out of luck. It seems it's a windows incompatibility between windows versions (f**k Microsoft ...), since it works on XP, I've just tried - on wife's notebook (well, interesting, it was 15 minutes - !!!! - go the a usable desktop, the same for Ubuntu on the same machine is under 20 seconds) ... Wait, or do you use it with XP too? Then it's kinda interesting ...

Anyway, new version is put online. It seems one special case is mentioned by Microsoft "programming" documents (I would say "guessing documents" since it's full of "for example one reason" without mentioning ALL, which should be a must for a decent API documentation to tell all the error cases ...) with problem of parent window's handler, so I tried to use null value without parenting the dialog box to a the main window. I have no idea what it causes though ...
Title: Re: Xep128
Post by: gflorez on 2016.April.17. 19:53:07
Of course I work on XP. For me is ok, not obsolete at all, although Microsoft says otherwise...

Bill Gates is like Sauron on the Lord Of The Rings saga:

One ring to rule them all, One ring to find them,
One ring to bring them all and in the darkness bind them.

Title: Re: Xep128
Post by: lgb on 2016.April.17. 19:55:13
Meanwhile I've edited my previous post about a new version :oops:
Title: Re: Xep128
Post by: gflorez on 2016.April.17. 21:05:51
Now LOAD "FILE:" opens the file handler and suspends mouse caption. Once selected the file to load  and clicked on "Open", XEP continues with the mouse caption and the file is loaded.


Good work!
Title: Re: Xep128
Post by: lgb on 2016.April.17. 22:01:19
Btw, I am still open to receive a gift, a decent application icon for Xep128 which can be used freely in Xep128, instead of my avatar, which is heh, little selfish and makes no sense, just I had no other idea :) 96*96 little stuff wanted :-D
Title: Re: Xep128
Post by: gflorez on 2016.April.18. 01:13:37
May be something like this? repeating  the Enterprise logo, but a little reiterative.
Title: Re: Xep128
Post by: lgb on 2016.April.18. 01:58:18
Oh! I more or less joked only, but thanks :-D

https://github.com/lgblgblgb/xep128/commit/a90f0ecfb1ab54600b7ff8fae09b515a2e4d28cb

:)
Title: Re: Xep128
Post by: IstvanV on 2016.April.18. 10:09:07
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.
Title: Re: Xep128
Post by: lgb on 2016.April.18. 10:11:35
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.

Aha, I see. Newer GTK3s has something similar it seems btw, I've just seen. Anyway, I didn't want to introduce a new dependency just for this on Windows (DLL hell of Windows ...), especially because currently it's the only "extra" GUI element over SDL I have :D
Title: Re: Xep128
Post by: gflorez on 2016.April.18. 10:46:51
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.
Title: Re: Xep128
Post by: lgb on 2016.April.18. 12:16:45
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.

Nothing forces you to use combined.rom :) It simply the concatenation of ROM images. So if you need another extra ROM, append that to its end, just be careful, to have 16K dividable size for the result. However. The problem, that if you have combined.rom, segment 07 will be covered by ROM already, it's not so much possible to assign SRAM or anything there then (since combined.rom is loaded from segment 0 using all segments linearly, based on its size). Also, I think (by heart now, I can be wrong), if you want to use segment 7 as SRAM, SD card won't work, since it would be the SD card cartridge otherwise. I suggest always use :XEP RAM command it check the memory layout, btw, even for the built-in config, or if you try to configure your own memory layout. In console/monitor window (you can ask for console with the numeric key bad minus key, and btw, console by default is not -conwin option anymore, but -console, but you don't need it, as you can ask for console later with that keypress) it's without :XEP of course, so just "ram" command. By default you will see something like this (it's on Linux, of course on Windws, you will see some other path with drive letter etc for the ROM image):

Code: [Select]
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

Now, if you try to assign SRAM segment to segment 7, it won't work too much, as segment 7 is already used by ROM (that's why I told, you should always check the result with the RAM command to see if your RAM/ROM config is OK as you would expect ...).

Ok, now let's see what you can do for real. Xep128 by default uses that big-all-in-one combined ROM. However, you are not forced to use this way, just it's the most simple way to do. You can assign ROM images by segment/ROM image basis as well. Xep128 has the -rom@XX options, where XX is a two digit hex number for sement number, and the parameter is a file name. It will load a ROM image into a given segment. If you just load something to segment 00 (EXOS) it will override all of the combined.rom, as only the starting segment matters. Thus in my case, the following command (on Linux again, with my directories, etc):

Code: [Select]
xep128 -rom@00 /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
Xep128 will complain on start-up that no SD card ROM found. That's OK as it really does not exist in our case, you can ignore. Now, the "ram" command shows the following:

Code: [Select]
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

As you can see, Xep128 internal ROM is always assigned after the last used ROM segment. Thus, if it's at "wrong" position, try to load _some_ ROM at a higher segment, so Xep128 XEP rom will be moved after that (ok, it's not so nice, I should provide an option to be able to tune XEP ROM's position ... it's not from combined.rom anything, XEP ROM itself is built-in the xep128.exe ...).

Of course meanwhile, you can use other -rom option with another segment, but it's a problem, if you try to load something used by another ROM image. Also, of course you can use a config file (beware of tricky end-of-line markers, we discussed already ...) instead of command line switches, the syntax would be something like this:

Code: [Select]
rom@00 = /home/lgb/vega/prog/xep128/rom/EXOS24UK-NOILLOPS.rom
Just remember, that ROM images should have sizes dividable by 16K exactly. Example command line (ok, now you can imagine the config file syntax from it easily):

Code: [Select]
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
I have no EPDOS 2.x and it's just an example. You can see with :XEP RAM or RAM (console/monitor) the result:

Code: [Select]
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

You can see, that Xep128 internal ROM ("XEP ROM") is really placed after the last used ROM. And now 04-1F is free. So you can also try to put an SRAM segment now to 07:

Code: [Select]
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
If you try this, you will get two warnings from Xep128. One if the SD card ROM missing, OK. The second says something about segment 7. It's not a problem: by declaring segment 7 as SRAM, Xep128 tries to load/save segment content. As you probably don't have saved segment 7 in preference directory, Xep128 will complain, but you can OK the warning and continue. By utilizing RAM command again, you will see this:

Code: [Select]
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)

Now it's close what you would like, I guess :) However in my case one problem: as EXOS detects the SRAM segment at 7 as RAM, it will use as page zero :) Even IS-BASIC "info" command says that you have more RAM as usual. As far as I remember, EPDOS2 uses its own (?) memory test (?) to skip/hide SRAM from EXOS, but I don't know too much about this topic ... And these were my examples, not actually with EPDOS2, just with "some" ROM image, it's just a co-incidence to use EPDOS-1.9 :D I know that EPDOS 1 and 2 are totally different topic, btw.

This:

Code: [Select]
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
would something like this, in config file:

Code: [Select]
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

If you are tired because of long file names for ROM images, you can try to use the trick, that any file name starting with '@' is the preferences directory. So if you keep your ROM images there, the config file would be:

Code: [Select]
rom@00 = @EXOS24UK-NOILLOPS.rom
rom@20 = @EPDOS-1.9-beta.rom
ram = @=07,F8-FB

Of course, you can create another config file, and use the -config filename option for Xep128 command line to load the given config file. I am not so sure these features are very well tested though, so be careful :) Also, please note that the '@' symbol in the parameter of 'ram' means totally different (it means complex config, in opposite of a simple decimal number ...) than in @filename syntax, where it means the preference directory. Also the '@' in rom@20, it's another different meaning, there it's part of the config option itself, nothing to do with the meaning above. Hmm, maybe I am confusing ... :-/

Some maybe outdated documentation on Xep128 in this topic:

https://github.com/lgblgblgb/xep128/wiki/Emulator-configuration
https://github.com/lgblgblgb/xep128/wiki/RAM
https://github.com/lgblgblgb/xep128/wiki/XEP-ROM

Ok, maybe I helped with this huge amount of blah-blah here :)
Title: Re: Xep128
Post by: gflorez on 2016.April.18. 12:40:02
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.
Title: Re: Xep128
Post by: lgb on 2016.April.18. 13:08:13
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.

Something like that, indeed. However Xep128 sadly only support SD card as a "mass-storage" device. So since there is no floppy, I doubt how can you use EPDOS without any storage device then, ok, you can use FILE: to load your stuffs :) But that's not EXDOS compatible device for sure. Also you need "ram = ..." option to define SRAM segment as well. If you can put EPDOS to other places and also the SRAM, you can have SD card as well. it's also possible maybe then to use the very same combined.rom (but it has EPDOS1 as well, dunno if it's problem) leave it alone, and load just EPDOS2 to another rom segment (let's say 0x20 with rom@20), so don't give rom@00 option as well to preserve combined.rom and all its content then. Of course, you still need "ram" option then to define SRAM segment and some extra RAM as well (since if you use "ram" option in "complex" mode indicated by prefix '@' then you need to define all RAM/SRAM by yourself which is other than VRAM, also the "default" 64K expansion RAM built-in in EP128).
Title: Re: Xep128
Post by: gflorez on 2016.April.18. 16:59:18
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.
Title: Re: Xep128
Post by: lgb on 2016.April.18. 17:29:24
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?

I have no idea. Do you mean that Xep128 reports SD image not found? But it should not happen based on the fact that another ROM is loaded or not. Of course, I can only tell about the emulator part. I can't be sure what EPDOS-2 does on the "Ep128 level" maybe it does not like the EXDOS you have in combined.rom (which is on the SD card cartridge itself by segment number btw, as it would be there probably in case of a real EP + SD card cartridge as well), or other incompatibilities between loaded ROM. Also, as I've told, combined.rom already contains EPDOS 1.9 or something like that. Maybe EPDOS 2 does not like this situation.

:XEP commands are "gateway'ed" between EXOS and emulatorts through the Xep128 internal ROM (you can see with the "ram" command, at the memory layout). That "ROM" of mine behaves an EXOS_ROM signature ROM from the viewpoint of EXOS itself. However since it's hooked up in EXOS as other ROMs, of course there can be problems if your system has other problems otherwise as well with some odd situation of used ROMs together, or similar issues. Then of course I can't solve that problem, since it's not an emulator level problem at all.

However, I find your problem quite interesting and I would like to see myself too ... Can you send me the EPDOS 2 rom image? And also the config file you try to use (however if it's that only EPDOS-2 from 0x20 segment then I can imagine, but still I am not sure where you want to put SRAM segment too, and it's really true that EPDOS-2 uses the right segment for SRAM really not an empty or ROM area, which can answer some odd problems then, I think ...).

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

I have no idea, even not that how you mean this. I guess your old problem we talked about and this one has a relation: somehow your editor (used to edit config files) messes up end of line markers. If enough lines are "messed up" the resulting line is really long and causes "too long line" error. If only "some" lines are affected, or short ones, or config file is short, the resulting may be not too long (if I remember, 1024 bytes is the limit) but still the line in result of course is invalid because they should be separated line. I think you should check the config file with a hex viewer / editor. First check config-sample, which is the configuration sample written by the emulator. You should see 0x0D 0x0A (CR LF) after each line in Windows, this is the "standard" line ending marker in Windows, which is inherited from DOS, which is inherited from CP/M and which is inherited from DEC systems and teletype machines according to the rumours :) UNIX uses only 0x0D btw, as Linux too. Xep128 tries to use the native line endings, ie CR LF on Windows and just CR on Linux. Then check your config file out you've edited. I have really no idea what your editor does with your file, the file you've sent me some days ago had only LF characters ... And what is even more strange DOUBLE LF characters. (I mean 0x0D). Maybe this time you only have the problem at the end of one line, that's why two lines are parsed as one. But as I've told, the really heart of config file parsing is the fgets() function. It is not even done by me, but the standard (C89, C99, and also POSIX.1-2001 standards) C library function is used to get a single line. If it fails, it's more like an operating system problem, or having an issue with text itself (ie, not proper line endings are used, or the software which produced/edited that text).

I'm really curious why your editor does this with text files which ones even have proper Windows EOL marks, not the case that you have Unix EOLs on Windows, or other problems ... You should really try another editor which tries to keep lines in a good shape :) Also in theory I can rewrite to use my own "smart" function instead of C standard fgets() to read a line to handle odd situations like this, but that creates another problem (besides the complexity) for example that line numbers won't be intact. Ie, your config file had double 0x0D markers which are not standard not even on Windows or UNIX. If some kind of "intelligent" code also marks 0x0D as line ending, then double means a line then an empty line ... So you see the situation is even more ugly :D Ok that at least won't result in badly parsed cfg file, but eg a syntax error in the name of an option would report bogus line number because of the invalid EOLs. Funny that a little problem like this creates a huge amount of problems, don't you think? :)
Title: Re: Xep128
Post by: gflorez on 2016.April.18. 18:07:21
First the command line configuration:

I have saved copy of the two roms on the config directory, to be able to use the @ character on the paths. This especial Epdos2-1.rom(below) has been poked to search the Sram at 50, not at 07 segment.

On the config, I have created a single sram segment at 50. Below you have the actual config file.

Then I have typed this on the console where I have XEP: ">xep128-test -rom@00 @combined.rom -rom@20 @epdos2-1.rom"


-----

I have tried also to do the same in the config file modifying the Rom line to this:

rom@00 = @combined.rom

rom@20 = @epdos2-1.rom

But then Xep parses the two lines like only one.

I am using Programmers Notepad as suggested by Zozo. Is for it I have discarded the other error.
Title: Re: Xep128
Post by: lgb on 2016.April.18. 20:12:27
Did you attend to the "competition of bizarre line endings"? :) Ok, sorry, it was a bad joke. But this file has "0D 0D 0A" _three_ character long EOL sequence all the time :D Again it's not Windows standard, not even Unix ... 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 :) And then create a totally new file and type in things, since it seems the already existing bad EOLs disturbs all the editors or even worse then ... I'm really wondering how you are so "lucky" with this EOL problem, fgets() is a basic C standard stuff used by many softwares since ages, but indeed it *will* fail (no wonder ...) with EOLs like your files has, it's not fget's or the C standard's fault :( You can see for example here in a hex viewer:

00000040 69 6c 65 2e 0d 0d 0a 23-20 46 65 65 6c 20 66 72 |ile.???# Feel fr|

Your previous file had 0d 0d .... The DOS/Windows standard for this is 0d 0a and UNIX is just a single 0a, but now you have three byte sequence at every EOL position, that's even more interesting.

Ok, about the other problem. I stilll think it's not an emulator related problem at all. It just some incompatibilities of the used ROM stuffs, or whatever. I've tried this command line without any config file this time (combined.rom should be not mentioned as it's the default as not overridden for rom@00):

Code: [Select]
-rom@20 ~/Downloads/EPDOS2-1.ROM -ram @C0-CF,F3-F5,30-3f,40-4f,=50
This creates the following memory layout:

Code: [Select]
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)

Even :dir command hangs, which nothing to do witch Xep128's internal ROM and XEP own commands. So I really believe it's not an emulator issue ...

Code: [Select]
-rom@00 rom/EXOS24UK-NOILLOPS.rom -rom@20 EPDOS2-1.ROM -ram @C0-CF,F3-F5,30-3f,40-4f,=50
This would not use combined.rom just EXOS and EPDOS-2. It's even worse, just reboots after EPDOS's own memory test. Maybe Zozo's EXOS (2.4) is not even compatible with EPDOS-2? Or I don't know ...By the way this EXOS is an "also IS-BASIC included one ...". I've just modofied Xep128 to disable *ALL* of the Xep internal ROM if it causes the problem, but the same, EPDOS makes system unstable, unusable or even cyclic rebooting. Since this is the first time I see EPDOS-2, maybe I am not the right person to judge though :)
Title: Re: Xep128
Post by: Zozosoft on 2016.April.18. 20:25:07
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.
Title: Re: Xep128
Post by: lgb on 2016.April.18. 20:36:42
By the way, since I've already begun the "wonderful" world of GUI programming, I think my next task will be a GUI based ROM/RAM layout editor with the optional feature to also save the configuration for later usage. To avoid too much manual config file editing task :)
Title: Re: Xep128
Post by: gflorez on 2016.April.18. 20:52:07
About carriage return and line feed, I thing the therms are inherited from the typewriter machines.

When you push the "carriage return lever", at the same time a mechanism "feeds lines" as selected on a little lever.

Sorry for the inconveniences. I though that problem as fixed.

Don't worry about Epdos2-1, I was only using it to test how to add another Rom to Xep. The most difficult example...

In reality I'm no more interested on Epdos2-1(mouse use speaking). I will test the config with other roms.

Thanks, for thinking of a Gui for the Rom config. I think Zozo wants the same on the Xep Hungarian topic.
Title: Re: Xep128
Post by: Zozosoft on 2016.April.18. 21:13:31
CHR 10&13 on EXOS VIDEO: device, everything works as logical :-)
[attach=1]
[attach=2]
Title: Re: Xep128
Post by: lgb on 2016.April.18. 22:20:59
CHR 10&13 on EXOS VIDEO: device, everything works as logical :-)

:) Don't even mention it ... I have some headaches because of this. Since host OS handles EOLs differently in case of Windows / UNIX, but also EXOS has the given official EOL, so I convert between them in some cases especially in case of XEP command results, and console/config file writes, etc :-P
Title: Re: Xep128
Post by: gflorez on 2016.April.18. 23:16:15
Other added roms have worked perfectly on XEP128, for example ZT or ESP.ROM.

Don't worry about EPDOS2-1, it cost me a lot of intents to find an EP128emu config that worked. Even so it was very unstable.
Title: Re: Xep128
Post by: gflorez on 2016.April.20. 23:28:48
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.
Title: Re: Xep128
Post by: lgb on 2016.April.21. 00:05:08
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.

Then HEASS for some reason wants to use file FILE: interface ... Have you downloaded newer xep128-test.exe recently? Since I've uploaded some new ones (for example today - oh well, yesterday, it's "tomorrow" since 2 minutes here :) - as well) which may shouldn't be used (that's why I haven't mentioned here) for other purpose than testing various FILE: features discussed with Zozo in the Hungarian Xep128 forum. Or you used DDN (default device name) related options, also from the newer versions not mentioned here, in the English topic?
Title: Re: Xep128
Post by: gflorez on 2016.April.21. 00:07:44
No. I've used the last test version you put in this topic.
Title: Re: Xep128
Post by: lgb on 2016.April.21. 00:11:01
No. I've used the last test version you put in this topic.

Then I have no idea. File selector is shown if FILE: device handler is called for "open channel" with no filename given. It simply means, that someone want's to open the filename "FILE:". Otherwise it's not possible because of the code flow. Also, the device handler is called from EXOS, so someone seems to really use "FILE:" somewhere, unless DDN feature is used but it exists only since today (errr, yesterday ...) so it can't cause this as it simply didn't exist in older versions :)
Title: Re: Xep128
Post by: gflorez on 2016.April.21. 11:44:30
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.
Title: Re: Xep128
Post by: lgb on 2016.April.21. 11:55:28
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.

Dunno ... It's possible that at some places you have file name reference "FILE:" which forces Xep128 then to use internal fileio and since there is no filename after the device name (FILE:) the selector window appears.
Title: Re: Xep128
Post by: lgb on 2016.June.05. 19:38:02
Recently I was busy with my other emulator project(s), Commodore 65 (and Commodore LCD and Commodore VIC-20 too). It's also interesting, that it was a good (and more simple) test case for optimizing things in Xep128 too, later. However, currently there are many things collected already for the Xep128 before this too. So I would like to know if anybody know about "serious" bugs in Xep128 (not the lack of feature, which is a different case ...). So just please tell me, if you know something :)

The newest build is at (as usual, and this page is preferred to download in contrast of direct URL to zip/exe, as it can change!): http://xep128.lgb.hu/    "Quick link here though for downloading the win32 build"

Thanks!
Title: Re: Xep128
Post by: gflorez on 2016.June.19. 16:21:52
I think that he best way to install Xep128 is..... to share a clone of my installation.

Just above is the link to the Windows port of Xep128. Expand it to a directory at hand, for example C:\Users\XXXX\Desktop\Xep .

Here is my SDcard image (https://www.dropbox.com/s/gn6sj8165ytep22/sdcard.rar?dl=0) loaded with all my EnterMice related projects. Expand it to the same directory than Xep128.

To modify the image, the best way is to use ImDisk Virtual Disk Driver (http://www.ltr-data.se/opencode.html/#ImDisk) as it allows to enter all the little partitions, and suits all Windows versions.

Once created the Xep directory with the necessary files, you can enter and execute the file named "xep128.exe".

The first time a Dos window and a little window will open informing of a config. file created at a given path, usually something like this "C:\Users\$$$$\Appdata\nemesys.lgb\XEP128\". It is important to know this path, because is where you must put the config. files of my installation.

If you close this little window clicking at OK, probably the Dos windows will close and another definitive emulator window will open.


Now you have the default config of Xep128 loaded on your PC screen. But you are insatiable, you want more....

Then close the emulator pressing F9.

Download my config. directory (https://www.dropbox.com/s/g4flw4sct1ppbyx/xep128.rar?dl=0) inside the nemesys.lgb\ path and simply try again executing XEP128.exe.

Now all things will work right, but you can find on the SD image some in-progress versions mingled with the definitive versions. Sorry. Check the date of creation of the files to know the last version.


Edit: for more ease of configuration, a direct access to the config dir can be created inside the executable dir.

Just download this file (https://enterpriseforever.com/emulators/xep128-1331/?action=dlattach;attach=15900) and rename it as "config.lnk". it will show a little arrow over the icon. It is a direct access.
A direct access can only be configured with windows.


 It is a mater of right click on the icon marked with a little arrow and select proprieties on the appearing menu.

A little window like this will open:

(https://blog.netspi.com/images/Scott_BreakingOut_Img_8.png)

Then, paste the XEP128 config path on the "Target" option and leave empty the "Start in" option. Click on Apply to set, and on OK to leave.

Place the config  link where you like.
Title: Re: Xep128
Post by: lgb on 2016.June.19. 17:30:38
I think that he best way to install Xep128 is..... to share a clone of my installation.

Just please be careful with words, since main design concept of Xep128 that it does not need installation, and it does not have installer :) I mean not in the traditional way, of course you can still put custom config, image etc, to be used then, and you can call that installation :)
Title: Re: Xep128
Post by: gflorez on 2016.June.19. 18:04:30
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?

Title: Re: Xep128
Post by: lgb on 2016.June.19. 18:13:24
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?

That directory you mentioned is an SDL stuff, I mean, the "preference directory" is "calculated" by the SDL layer itself (not mentioning the app specific part, ie nemesys.lgb/Xep128 of course). This is needed to be cross platform application, ie working on multiple operating systems, and their multiple versions. The reason not using the directory of the executable itself, is also the flexibility, you can copy the exe in a system wide accessable directory somewhere in the PATH, still multiple users can have their own configuration files though! The user may don't have even write access to the directory where executable is. This is for example a common scenario with Linux, that application installed system wide, and using per user specific configuration thoughs. So the reason is again the maximal possible flexibility, to be able to be used in any scenario, any OS, any version ... Maybe not even just Linux/Windows, but Android etc in the future, so whatever SDL would be able to support otherwise.

I have not so much user experience with Windows, as you know, in Linux/UNIX like OS'es some can still use symlinks to link directories to another place in the directory tree, so user can still create a different layout if it's desired because of some reason.
Title: Re: Xep128
Post by: gflorez on 2016.June.19. 19:02:25
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.
Title: Re: Xep128
Post by: lgb on 2016.June.19. 19:42:20
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.

That's not true in this form. In Xep128 there is a function responsible for open files, ie for ROM image to load, the config file to be parsed, and so on. This function has some heuristic logic designed (by me, I mean) to avoid some headaches. Ie, the default configuration (even without config file) would use "combined.rom" for ROM images, which is searched at MULTIPLE places, INCLUDING the directory where the EXE is. So the preferences directory is not the sole place it tries to be used, especially for reasons you mentioned as well, for a simple user "download & try" experience, it's just enough to put every files in a single directory, EXE, combined.rom, etc, and will work, even without the user know anything about the "preferences directory" and its role. The default sdcard.img SD card image file is similar, ie is tried to be opened from the EXE's directory as well, for the same reason: the user can just download the EXE (and DLL, btw), ROM image and an SD card image file, putting all of them into a single directory, and it will work, without any configuration file, or the preferences directory. What I tried to be done it to provide a cross-platform, multiple OS/multiple version, single/multi user "installation" etc capable solution *WITH* also the possibility to provide the most simple approach for "try it", with just putting files into a desired directory, and that's all. This is somewhat different from ep128emu, where you have to do some work before the emulator is able to be used.

With the FILE:, you have some truth, however, I consider FILE: as an "advanced" stuff which is not the "very basic" usage of Xep128, so it needs more knowledge on the emulation details, directories etc, what emulator uses. By the way, if you check xep128.h out in the source, you will see this:

Code: C
  1. #define COMBINED_ROM_FN         "combined.rom"
  2. #define SDCARD_IMG_FN           "sdcard.img"
  3. #define PRINT_OUT_FN            "@print.out"
  4. #define DEFAULT_CONFIG_FILE     "@config"
  5. #define DEFAULT_CONFIG_SAMPLE_FILE "@config-sample"

File names begin with '@' means the preferences directory. File names without that (or given path) are tried to be guessed with opened at multiple places, ie in the current directory, in the directory which contains the EXE (and even the preferences directory, also on Linux/UNIX, the "data directory" it tried to open the given file as well). So you can see, that the default ROM image and default SD card image can be found even without anything in the preferences directory itself, though the default configuration file is indeed, tried to be opened from the preferences directory.

And yes, of course: you're right, of course if you want some "complex" the situation is more complex, it's quite logical :) While the default basic usage of Xep128 does not need to any deal with custom/pref/etc directories, and paths, if you have something more complicated, you need to know more on Xep128 details. I can't see it can be avoided easily, to also provide the simple case, while also serve the purporse of multi platform / multi user / system installed EXE, etc all of the cases at the same time.

Quote
I understand your reasons. Of course I don't want to influence your future work with Android.....

:) it was just an example :) But of course it's possible. However even *only* with Windows/Unix, and different usage needs, you can see the problematic part here, and the need of some "interesting" solutions :)

Quote
Symlinks?  I only know about "direct accesses", but I think they only deal with the Windows GUI, not with the deeps of DOS.

Symbolic links in UNIX OSes, maybe "shortcuts" in Windows, just in UNIX, it's a kernel level OS stuff, so I can "symlink" a file or directory to another name and/or directory, and I can "see" that directory/file there too. Maybe Windows is lame enough not to have this capability? :) It's a kinda elementary knowledge about UNIX OSes (btw, there are even hard links, but i's another question).

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

Sorry, I don't clearly understand what you mean here. I assume, "config directory" is the "preferences directory", ie the stuff with "nemesys.lgb" in its PATH. What would you do with it?

Quote
Then the final user doesn't need to know where the config is.

That is correct, this is the exact reason why Xep128 works without *any* configuration file at all, just putting ROM image, EXE, DLL, sd card image into the same directory and that's all :) But you can't avoid the complexity if you want to retain this possibility as well also with other use cases and goals at the same time. WHat I've already mentioned, of course.

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

Ah, so that should be the Windows-like notion of "symlinks" :) However I can't do anything with this file, it's a data garbage, no idea what it is, maybe it's a Windows stuff :) Unix symlinks are not like that, the link itself cannot be saved, because it's a link, if you try to save, the pointed file is saved, what it should do, I think :)
Title: Re: Xep128
Post by: lgb on 2016.June.19. 20:03:52
In addition of my previous long mail, the main thought: that you can download the zip, extract the content, DLL/EXE/combined.rom (and maybe even the sdcard.img file) to any directory where you want, and it should work without any additional installation/configuration/etc, but also giving the possibility for more complex stuff/needs which then of course needs more complex solutions, indeed (including "messing" with the preferences directory, etc).
Title: Re: Xep128
Post by: gflorez on 2016.June.19. 22:17:37
I have added an explanation (https://enterpriseforever.com/emulators/xep128-1331/msg56458/#msg56458) on how to put the direct access to config dir.


Probably shortcuts can be created, but I am not(and also don't want to be...) an expert user of Windows....
Title: Re: Xep128
Post by: lgb on 2016.June.19. 22:28:48
Well, sorry to be shown myself stupid, but I am still a bit lost to understand your intent here. I've downloaded that Xep128.rar should be the "config directory" according your terms, but it does not contains anything which is needed by Xep128. If you have the intent to distribute/use your sdcard.img file, it's better to say, that extract xep128 ZIP distribution to any directory user wants (it contains the exe, dll, rom, ....), and also your sdcard.img file. and that's all. Since Xep128 by default tries to use file name "sdcard.img" as SD card image, with searching it through several 'default" directories *including* the directory where EXE is, it will work without any configuration step, or other magic you mentioned. For this, you don't even need to know anything about "fancy directory names" or anything, also no need for Xep128.rar you provided. To put it another way: to use a custom sdcard.img, it's just enough to put it with this name in the same directory where exe is, period. No other steps needed.

But it's possible that only I can't understand what you would like to do here ...
Title: Re: Xep128
Post by: gflorez on 2016.June.19. 23:04:04
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. 
Title: Re: Xep128
Post by: lgb on 2016.June.19. 23:08:33
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.

Aha, I see. Another idea is to use command line switches for the exe, and you can create a .bat file for your needs. Then again, you don't need to know too much about the preference directory, and you can use command line switches as well to set amount of RAM, ROM images, etc. Then you can use the BAT file which would contain start of xep128.exe with your desired switches (remember, in Xep128, the config file content and the command line switches has about 1:1 mapping, ie the same parser inside Xep128 handles both, so you can use config file instead of switches, or vice versa). Some examples:

What you had in the config file:

rom@00 = combined.rom
rom@20 = @SPEMU128.ROM

Basically, it would be something like this with switches:

xep128.exe -rom@00 combined.rom -rom@20 @SPEMU128.ROM

However, please note, that with @SPEMU128.ROM you select the "hated" :) preferences directory, so you may want to to forget it that "@" sign, and allow Xep128 to search for it, as @ would restrict to use only from the prefereces directory. Also, don't forget, that rom@00 = combined.rom is the default, so you can even forget that. That is, it's enough:

xep128.exe -rom@20 SPEMU128.ROM

But for sure, feel free to add more options, like:

xep128.exe -rom@20 SPEMU128.ROM -mousemode 4 -audio 1

So you can write this command line into a batch file, so you don't need to enter the whole command with parameters again and again. With this, you need only a one line long batch file, instead of long description how to get to know the preferences directory, write config file etc etc.
Title: Re: Xep128
Post by: gflorez on 2016.June.19. 23:28:39
Xep is complex, isn't it?

Thanks.
Title: Re: Xep128
Post by: lgb on 2016.June.19. 23:33:20
Xep is complex, isn't it?

Kind of :) However my main goal with Xep128 to allow the 'easy" usage (no config file, extra dirs) and complex setups as well, that's the reason there are multiple solutions for the same problem. However for a given problem, the more simple solution always looks better :) Also, I wanted to do it modular, ie I didn't want to write command line parser and config file parser with very different syntax, but basically there is a single parser core can be used with command line switches and config files as well :) And similar example (ie: XEP commands are monitor commands as well, etc). This looks complex, but from the other point it's also more simple, as you don't need to learn new options/syntax at multiple usage areas too much.
Title: Re: Xep128
Post by: gflorez on 2016.June.19. 23:52:08
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...

Title: Re: Xep128
Post by: lgb on 2016.June.20. 01:02:55
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...

Hmmm, well, I think, if you emulate something for a certain features, you can't avoid to be able to configure the way it emulates those, you cannot avoid it. Maybe the difference to be able to find a good balance of simple case / default settings and advanced modes. Somehow I felt it complicated as how ep128emu does this, to have initial configuration step etc, I wanted to be sure that Xep128 is able to work without any installation/pre-configuration step, if a user want to try it only, or don't want something "extra". That's another point how (un)successful I was with this thought, though. If we have a *good* SD card image with almost all EP software, and suggesting that file to download, maybe it's a good idea, that not too much extra stuff is needed, *usually* at least. I don't think ep128emu has less options btw. Also, I can write 100000000 options available, not so much problem, if 99.99% users only needs some :)
Title: Re: Xep128
Post by: lgb on 2016.June.20. 11:14:36
But of course, I don't feel that I am the smartest guy and I have to say everything as the global truth. So I am open for suggestions, just *currently* I don't feel how to solve the problem in a way which is both of simple and flexible (in the sense that multi-platform, multi usage method friendly, etc, etc what I've already discussed).
Title: Re: Xep128
Post by: gflorez on 2016.July.26. 08:53:17
This may be an obvious question but, how an EP128emu snapshot is loaded in Xep128?
Title: Re: Xep128
Post by: lgb on 2016.July.26. 09:39:07
This may be an obvious question but, how an EP128emu snapshot is loaded in Xep128?

That's ep128emu's own snapshot format, it's not possible to load it into Xep128. Well, in theory it can be done (my javascript based emulator - JSep - could do that) but there can be compatibility issues (the exact machine state may be not reproduced as the internal state of ep128emu which is stored in the snapshot cannot be mapped 1:1 to other emulator because of different internals - I mean the the different ways the two emulators are constructed/works etc). Surely, "some" limited (maybe it can fail sometimes if a software wants very precise state at the snapshot back - but I guess usually it should work). Just I need to write it :) I even have an issue ticket assigned to this task :-)

https://github.com/lgblgblgb/xep128/issues/25
Title: Re: Xep128
Post by: gflorez on 2016.July.26. 11:58:33
Is that issue what I have read... I understood it as done, sorry.
Title: Re: Xep128
Post by: lgb on 2016.July.26. 13:47:02
Is that issue what I have read... I understood it as done, sorry.

Well, maybe not so hard to implement that feature at least at a "basic" level that it "should" work on most cases :-P The real problem if the precise Nick and Dave internal state needs to be restored as well not just port values, memory and Z80 registers, etc ... That is because of course Xep128 and Ep128emu don't work the same way, some of the data en ep128emu snapshot does not even mean too much for Xep128 because it uses another way for the given emulation task, etc. I'll take a look on the problem tonight if it's important for you.
Title: Re: Xep128
Post by: gflorez on 2016.July.26. 16:14:26
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.

One of that "easy things" I want is to create a snapshot that I could send to this web to show some aspect of a program, etc

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.
Title: Re: Xep128
Post by: lgb on 2016.July.26. 18:29:11
Important..... nah.

First of all, everything for users :D

Second: :) I mean about the priority. It's quite possible that my priorities with Xep128 development is quite different as users would think :) It's often the case with software development ... Since developers are too much "in", viewing from inside, while users are really interested about the usage not the internal structure too much being bad or good if it works, it's good :)

With my "if it's important for you" i meant that it's always interesting see what users find useful with more priority to develop against other features.

Now I try to make OSX version just because it seems there is at least one user who would be interested :D For me, that's not so important as I don't use OSX. Same for Windows, I don't use Windows, but I guess it would be a huge limiting factor if I refuse Windows support ... So you see ...

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

it's big enough already with code complexity :D Ok, just joking here.

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

IstvanV's snapshot format is quite good one actually. it builds up from blocks (with type fields etc), so it's easy to extend with additional things, ep128emu can't emulate, ie state of SD card etc. If you have ep128emu snapshot loading in Xep128 _now_ it also means of course that you can't use SD card emulation neither :XEP stuffs as those are "private" to Xep128. However often it's not a problem and someone just wants to try something, then it's OK. Another thing is saving snapshot, is the opposite direction: if Xep128 is able to save snapshots it won't work too much with ep128emu, at least ep128emu would not care about XEP ROM code, SD card emulation, mouse, etc ... So, the inter-ermulator snapshot compatibility is limited by logical reasons, as you can see. However, surely, it can be still useful not to re-invent the wheel with my very own snapshot which is not compatible with ep128emu at all. OK, so in nutshell, I will support ep128emu snapshot format, though with the limitations caused by the nature of the problem of different emulators ...
Title: Re: Xep128
Post by: gflorez on 2016.July.26. 20:37:25
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.

And, on your hard way you are learning a lot, what maintains your enjoyment.........
Title: Re: Xep128
Post by: lgb on 2016.July.27. 08:36:08
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.

Don't get me wrong, it's important for me too, if for no other reason then for the challenge.  :) What I meant here however is that as "user" of my own work, I wouldn't use it, as I have no OSX, that's all :)
Title: Re: Xep128
Post by: lgb on 2016.July.30. 13:10:17
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.

http://download.lgb.hu/travis/?repo=xep128

Download xep128.exe from "Build #17" (not the xep128 without extension, it's a Linux binary). You need 2.0.4 SDL2 DLL file, if you still have the 2.0.2, you need to download newer:

http://xep128.lgb.hu/files/SDL-2.0.4.dll

Rename it as "SDL2.dll". Loading a snapshot can be done with command line, ie:

xep128.exe -audio 1 -snapshot ...directory....\game.ep128s

Of course "-audio 1" is not compulsory (it just enables the lame audio support), also can be done in the config file, for sure (well, even the snaptshot option can be put into a config file but usually you don't want that for obvious reasons).

For sure, there are serve issues if a snapshot from ep128emu uses EXDOS/WD as Xep128 can't emulate that currently ...
Title: Re: Xep128
Post by: IstvanV on 2016.July.30. 14:11:17
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.

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.

Quote
For sure, there are serve issues if a snapshot from ep128emu uses EXDOS/WD as Xep128 can't emulate that currently ...

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.
Title: Re: Xep128
Post by: lgb on 2016.July.30. 14:19:49
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.

Yes, just currently I was "lazy" :) even with current LPB etc stuff. So I just restore the I/O registers and LPT address but not even the current LPB. Also with dave, state of latches etc are not restored. Currently only blocks  0x45508001, 0x45508002, and 0x45508003 are used, the rest are checked (for existence in the snapshot) but not used otherwise. As far as I can say, with testing some snapshots, it's already enough to deal with most of them, but surely it's very far from a perfect solution. It's just the initial work, not the final :)

https://github.com/lgblgblgb/xep128/blob/master/snapshot.c

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

Yes, that's understandable after all ...
Title: Re: Xep128
Post by: lgb on 2016.July.30. 14:38:55
And by the way, now Xep128 uses a bit different timing code.

First of all, the time difference measurement can use the "Xep128 classic" getimeofday() call (which we know is problematic on Windows, because of the bad precision of the emulation of this unix-style call) and an SDL method (that second one is used now by default). That uses  SDL_GetPerformanceCounter() call difference divided by the result of SDL_GetPerformanceFrequency(). This method seems to be architecture independent, at least the difference is at SDL level, that is not so my task to deal with the problem but SDL's.

Second, the actual sleeping. There is usleep() call, SDL's SDL_Delay() usage, and use of nanosleep() call. Currently on Linux and OSX nanosleep() is used, for Windows it's usleep (but probably that's only a call "emulated" by MingW for sure).

https://github.com/lgblgblgb/xep128/blob/master/main.c

functions  get_elapsed_time() and emu_sleep()

The next interesting development will be the audio buffer handling, ie taking account the audio buffer fill state to slightly modify the timing for real-time sync'ed audio which is not done yet. SDL 2.0.4 supports both of callback for audio buffer filling and "manual buffer queuing push" the later will be prefered I think, since you can even ask then about the real "amount of sent bytes to the hardware" (well or to the software if it's some kind of software audio layer eg with PulseAudio on Linux) information. I guess, this will result in better audio support than the callback version which is quite tricky to deal with the buffer status measurement values.