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!

Yes, it works. I have saved and loaded a Basic program as usual.

The XEP DIR and CD commands also work.

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!

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

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

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

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?

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 Thanks for spotting! Also it contains the already experimental stuff, FILE: load/save, and SD card write ability on VHD image level.