Regarding symlinks... I added a "fdd.xml" symlink into the extensions directory pointing to Sony_HBD-F1.xml this makes it much quicker to add a disk drive to a machine that normally does not have one. Perhaps something to add to the default install?
openmsx -machine msx1 -ext fdd
Manuel, regarding issue 1118 you still have open:
scripts/*.tcl files apparently not being loaded at startup · Issue #1118 · openMSX/openMSX · GitHub
And described here:
https://github.com/openMSX/openMSX/issues/1118
I found the solution:
I found this bug while developing screenshotter, so I would like to show you how to solve it and the reason why this bug appears on latest releases (I hope we are talking about the same bug).
Sympthom:
You create an empty text file under Windows and TCL file loads but it doesn´t work giving multiple errors
Cause:
Format differences between Linux and Windows creating and processing text files
Explanation & solving:
Under Linux each line of text is ended with a "jump line" character aka LF (ASCII code 0A)
Windows otherwise uses Carriage Return aka CR instead of line feed (ASCII code 0D)
OpenMSX process the TCL as a linux formatted text and it receives a messed up text, in other words it expects @LF instead of @CR at the end of each line
Solution:
Force openmsx look for @LF and @CR instead of only @LF (I solved in my program using @CRLF)
I Hope it helps solving the bug
Do you really think it's the same issue? The poster of that issue did not install any custom scripts, as far as I know (he said he used a clean install).
Windows (and DOS), do not use CR, it uses both CR and LF.
openMSX does not expect LF only, as far as I know. You said you are already using CR and LF, but that is the Windows standard way to end lines. How did you create your text files?
I think if you create a script with just Notepad and save it, it will use CR and LF and it will work fine in openMSX under Windows (but also Linux). Can you please try again?
Yes Manuel, I think that is the same bug
Regarding Notepad it does not support LF, only is supported in last build of Windows:
https://www.theverge.com/2018/7/12/17563704/microsoft-window...
The bug is a bit tricky because you open the file and everything seems to be fine, but openmsx reject it internally (the part that process TCL scripts at least), and breaks the execution of commands in the TCL script and refuses to load the TCL file, simply dropping an error and does not load the script but in fact after debugging you see that OpenMSX loads it but cannot process it and drops errors (but this problem seems not to affect OpenMSX 0.13 on Windows).
Even if you have a valid TCL file, open the file with notepad change some line, save it and everything goes to hell, and the worst part is that file seems to be OK but is not.
I had to add debug code to find the real problem using multiple chains and using files created under linux with standard linux EOL codes, mixed and windows ones, even I played with multiple encodings UTF8 & Ansi.
If you try the TCL file created on Linux under linux build everything works ok and Windows build only if you use a linux text file, also I tested this issue using SED.
For those reasons I believe we are talking about the same bug, if it is not the same bug/limitation it is so similar that would surprise me, but hey, programming sometimes is tricky :D
I think is worth it to look at it.
Notepad uses CR+LF, not only just LF. Both. That's the way it goes on Windows, DOS and MSX-DOS.
We use the standard Tcl interpreter, which is (as far as I known) not sensitive to end-of-line markings. We certainly didn't change it.
I will do some tests with CR+LF line endings on Linux.
What are the exact errors you get?
Why do you think it's the same problem as the other guy, when he didn't even add scripts or something like it?? I don't understand that.
Actually I think I read Windows 10’s Notepad also writes LF in a file which is already using LF? Instead of mixed LF/CRLF as it would before. Any text file reader worth its salt though nowadays would treat CRLF and LF the same…
I will do some tests with CR+LF line endings on Linux.
I changed in one script to CR+LF line endings and the script loaded fine... so I expect that will also be no problem on Windows.
I also asked the Tcl experts: there should be no sensitivity for line endings in scripts.
So, please tell me the details on the errors you got. I'd like to debug this issue.
Regarding symlinks... I added a "fdd.xml" symlink into the extensions directory pointing to Sony_HBD-F1.xml this makes it much quicker to add a disk drive to a machine that normally does not have one. Perhaps something to add to the default install?
openmsx -machine msx1 -ext fdd
Thanks for the suggestion. However, I'm a bit reluctant about these symlinks. They have a disadvantage: they cause identical/duplicate items to appear in the OSD menu where you can select hardware. Still, if you like it you can always make one yourself, of course.
Can't the OSD menu discard duplicate names?
Building latest version from github atm on xubuntu 18.04,
is there anything specific I should test or just a general check on my normal use with it?