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

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

It has worked at the very first time!

Even if it is set as an analogue joystick. The fire button is precisely the first of the  32 I can configure...

It seems that SDL treats analogue and digital lecture the same. I don't have a pure digital Pc joystick now, I have to look for it, sorry.

But I figure that a digital joystick gives you X=+32767 when Right is pressed and X=-32768 if Left. The same on Up and Down. Of course Centre gives you 0.

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.

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:

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.

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