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

I tried to compile Paszians on XEP128 with Heass, but when I wanted to load the assembly within the program, Xep's file handler pops out and I can't access to the SD-image.

No. I've used the last test version you put in this topic.

Today at work I am able to use Heass inside your XEP128. No errors.

I can't understand why there are aspect that work on a computer and not on another. Both Pcs have the same XP installation.

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!

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

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.

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:


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.

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

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

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?

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.

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