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.

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

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

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

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!

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

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/