What XML trick?
Just change the renderer setting to sdl and save settings should be enough.
New upcoming release?
Does this go for Android too?
I wonder if there is going to be more SN76489 emulation.
http://map.grauw.nl/resources/msx_io_ports.php
I also want to see V9990.
No, Android will still not be released.
What do you miss in SN76489 emulation?
What do you mean with the V9990 remark?
It would be great if this issue https://github.com/openMSX/openMSX/issues/248 can be fixed. I already did the directory link trick but I also need to set OneDrive to not sync the OpenMSX dirlink on every PC I own. The workaround on github still creates the persistent files on the original directory (in my case the OneDrive location).
We need help from a Windows developer for that.
What XML trick?
Just change the renderer setting to sdl and save settings should be enough.
Ill try and let you know
Ir just implement a new setting? Either using and environment settings or via settings.xml. The last one actually is respecting the OPENMSX_USER_DATA environment setting.
A setting that tells where the settings are stored? Chicken/egg problem?
Well the OPENMSX_USER_DATA already enables the settings.xml to be placed elsewhere. But it does not apply to the persistent stuff (sram, hdd images). These keep being created in the "My Documents" or similar. If it is not fixable because it is a windows thing, it might be interesting solving it by putting the location in settings.xml.
So not a settings where the settings are, a setting where the persistent store will be.
Yes it is a crappy solution, but it might be a solution. "A windows developer needs to fix this" is a problem that has been around for years now, it does not really lead to a solution. If you don't like the suggestion, than leave it as is. I have to do the workarounds in the future as well. No problem.
My point is that I do not feel comfortable changing things that I cannot test myself.
Anyway, looks like you want to be able to override the openMSX user dir, which is currently hardcoded to 'openMSX' in the home dir. Note that the data dir is by default the openMSX user dir, with /share behind it. See https://github.com/openMSX/openMSX/blob/master/src/file/File... and around there.
Look how much Windows specific code is in that file...
I'm a bit hesitant to make changes in this, as it may break a complete installation for a user. But let's think about it some more. (By the way, it is not something I will block the release for...)
By the way, Sjaaq, did you include the USERPROFILE override, as described in the workaround?
After cleaning up everything again I came to the following:
Setting the USERPROFILE to D:\Emu\MSX\OpenMSX\Profile, works, but somehow it still created a OneDrive directory there, so for example:
D:\Emu\MSX\OpenMSX\Profile\OneDrive\Documents\openMSX\persistent\Panasonic_FS-A1GT2_int\untitled1\fs-a1gt.sram
I tried setting the ONEDRIVE environment variables as well, but could not get it to work any better than this.
While having this is very messy, and whenever I start Catapult (so not setting any environment variable) it reverts back to the C:\Users (etc) and I still have openMSX user dirs everywhere. Also since I have OneDrive business as personal at the same time, sometimes it uses the OneDrive business directory for persistent storage, and sometimes the personal one (I am guessing it is dependent one whatever you configured first at that machine).
Anyways lets leave it like it is until a Windows Developer can do something about it.