Oh! I more or less joked only, but thanks

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

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

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

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

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:

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:

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

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:

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:

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:

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 I know that EPDOS 1 and 2 are totally different topic, btw.

This:

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:

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:

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

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

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

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

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

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

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

-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

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

CHR 10&13 on EXOS VIDEO: device, everything works as logical
[ Guests cannot view attachments ]
[ Guests cannot view attachments ]