> > The turbo Rs do not. I don't know about the various MSX2+ models.
>As far as I know, the MSX2+ models have a tape connection. The tape port only
>got removed from the standard as of the MSX turbo R.
No, at least the Panasonic FS-A1WSX does not have a cassette port.
Greetz,
Patriek

Op maandag 23 juni 2003 18:46, schreef Maarten ter Huurne:
> On Sunday 08 June 2003 15:09, Joost Yervante Damad wrote:
> > Slightly offtopic, but just out of curiousity, do the "modern" MSX
> > machines like the Turbo-R still have a tape connection?
>
> The turbo Rs do not. I don't know about the various MSX2+ models.
As far as I know, the MSX2+ models have a tape connection. The tape port =
only=20
got removed from the standard as of the MSX turbo R.
Kind regards,
Alex Wulms

>Wasn't the MSX2+ pause the same as the MSXturboR pause in Z80 mode, in
>short: hardware?
Yes, but on turboR there is no memory degradation, because memory refresh
is not done by the Z80 anymore.
Greetz,
Patriek

>I'm not sure if there are more types, though the HBI-55
>is a 4KB SRAM containing cartridge accessed by I/O
>ports connected to a 8255 chip:
There are 2 types that I know of. A blue one with 4kB and a red one with
16kB. I do not know the modelnumber of the red one :/
Greetz,
Patriek

Feature Requests item #760760, was opened at 2003-06-25 22:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=421864&aid=760760&group_id=38274
Category: General/misc
Group: None
Status: Open
Priority: 5
Submitted By: Manuel Bilderbeek (manuelbi)
Assigned to: Nobody/Anonymous (nobody)
Summary: More flexible or even avoiding MSXTapePatch for .cas files
Initial Comment:
It would be very useful if the MSXTapePatch for using
.cas files could be applied in an existing
configuration at run time, without changing any XML.
This way a launcher can let the user use the .cas files
very easily.
Even better: avoid the patch, but translate the bytes
to audiopulses again..!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=421864&aid=760760&group_id=38274

'Manuel Bilderbeek' wrote about '[openMSX-devel] Re: openMSX 0.3.2!' - Tu=
e, Jun 24, 2003 at 08:21:44PM CEST
> Hi!
>=20
> Beno=EEt Delvaux wrote:
> >Finally, my boosted configurations for openMSX 0.3.2 are online !
>=20
> Nice! I just wrote a mail to openmsx-devel to inform about having=20
> boosted configs in the openMSX distribution as well.
>=20
> >I've discovered that the Korean MSX 2 configuration can't support=20
> >Moonsound,
> >it seems that the integrated hangul firmware for screen 9 comes in con=
flict
> >with the Moonsound cartridge ...
>=20
> Hmm, interesting! What happens? Do you know if this should work in real=
=20
> life?
>=20
> >Megaram is OK for all configurations, including Turbo-R. If it seems t=
o not
> >work on a GT, you must press "1" in the boot sequence before the beep.
> >Probably Megaram doesn't like DOS 2 ...
>=20
> Could be. I think it should work though... I'm not sure. Ricardo?=20
> Adriano? Maybe they know.
>=20
> >Other thing : you've suggested me to make an English version of my sit=
e.
> >Well, it's all a work !
> >But, in fact, the main reason that my site is in French is a personal=20
> >choice
> >: I think that there are so many MSX sites in English and there must b=
e a
> >great MSX site in French .... So, my ambition is to have the best MSX =
site
> >in French !
>=20
> Hey, it's your site, but I think you would get a lot more visitors if i=
t=20
> were in English. By the way, you have the only openMSX fan site :-)
>=20
> >By the way, did you have already a look at my site in the site ..... M=
SX
> >Valley ?
>=20
> Yeah, nice walkthroughs!
For reference, his site, the openmsx part:
http://www.marsupone.com/msx/openmsx.htm
Joost

Herman Oudejans wrote:
>>It seems that a lot of users want to use not a specific MSX machine, but
>>just some `boosted' normal machine, that has a lot of features, like
>>FMPAC, Music MOdule, Moonsound, SCC(+), Kanji, V9958, 1MB RAM, etc.
>>So, to serve the users, it might be nice to add a few (or one?) of these
>>configurations. We should think what to put in it and how. Of course we
>>want to have a maximum number of software titles run on it as good as
>>possible.
>
> I think we better not. Openmsx tries (as far as I know) to be as close to
> reality as possible. More over, I think any user can pump up his favorit
The boosted stuff can be real. These things can be done to a real MSX
too. It's just not a configuration that was actually ever sold. But the
hobby clubs definately did some of these modifications on real machines.
> configuration. It's those well configured machines that are hard to create
> without the proper info.
True, but normal uses don't want to edit XML. They just want to run as
many programs as possible without a lot of fuss.
> Finally, we also got the extensions to pump up a machine to the max, so why
> bother? With your launcher is starting an msx with a load of extensions a
> piece of cake.
True, but it's still more work: you have to click all these extensions.
And: the laziest users are the Windows users. And they don't have a
launcher yet, and maybe not even soon, since the Qt 3.x stuff is less
portable than I thought, as you found out...
By the way: if anyone wants to beta test my launcher, please ask me.
Also, I need some advice about where to put it in CVS, and what files
exactly. It isn't really a normal auto* project, but it was started with
kdevelop, which generated a template for the auto* files.
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Hi!
Benoît Delvaux wrote:
> Finally, my boosted configurations for openMSX 0.3.2 are online !
Nice! I just wrote a mail to openmsx-devel to inform about having
boosted configs in the openMSX distribution as well.
> I've discovered that the Korean MSX 2 configuration can't support Moonsound,
> it seems that the integrated hangul firmware for screen 9 comes in conflict
> with the Moonsound cartridge ...
Hmm, interesting! What happens? Do you know if this should work in real
life?
> Megaram is OK for all configurations, including Turbo-R. If it seems to not
> work on a GT, you must press "1" in the boot sequence before the beep.
> Probably Megaram doesn't like DOS 2 ...
Could be. I think it should work though... I'm not sure. Ricardo?
Adriano? Maybe they know.
> Other thing : you've suggested me to make an English version of my site.
> Well, it's all a work !
> But, in fact, the main reason that my site is in French is a personal choice
> : I think that there are so many MSX sites in English and there must be a
> great MSX site in French .... So, my ambition is to have the best MSX site
> in French !
Hey, it's your site, but I think you would get a lot more visitors if it
were in English. By the way, you have the only openMSX fan site :-)
> By the way, did you have already a look at my site in the site ..... MSX
> Valley ?
Yeah, nice walkthroughs!
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Hello
It seems that a lot of users want to use not a specific MSX machine, but
just some `boosted' normal machine, that has a lot of features, like
FMPAC, Music MOdule, Moonsound, SCC(+), Kanji, V9958, 1MB RAM, etc.
So, to serve the users, it might be nice to add a few (or one?) of these
configurations. We should think what to put in it and how. Of course we
want to have a maximum number of software titles run on it as good as
possible.
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

On Sunday 08 June 2003 15:09, Joost Yervante Damad wrote:
> Slightly offtopic, but just out of curiousity, do the "modern" MSX
> machines like the Turbo-R still have a tape connection?
The turbo Rs do not. I don't know about the various MSX2+ models.
Bye,
Maarten

'Manuel Bilderbeek' wrote about '[openMSX-devel] Cassetteport' - Sun, Jun 08, 2003 at 02:40:41PM CEST
> Hi
>
> Two things about cassetteport:
> - no single config in share has a cassetteport, while most MSX machines
> have one. Should they be added?
> - WHy is cassetteport a "config" element? This is in the exampleconfigs:
> <config id="CassettePort">
> </config>
> I'd expect it to be a device.
>
> Can someone clear this up? I volunteer to add the cassetteports to the
> configs, if that is what the idea of this 'config' is.
Slightly offtopic, but just out of curiousity, do the "modern" MSX
machines like the Turbo-R still have a tape connection?
Joost

Hi All,
After some discussion yesterday in #openmsx, the idea arose to create a
mailinglist for discussion of msx emulation standards and cooperation. A new
mailinglist has now been created at emu-dev@... To be able to
receive mail from this list, you'll need to send an email to
emu-dev-subscribe@... to subscribe.
This mail goes to the NLMSX and openMSX members, but the list is open to
anyone active in MSX emulation, and wanting to discuss.
The default language will be English ofcourse :)
Well, I you have any question about the mailinglist, just let me know.
A web archive will be available soon on Generation MSX.
Regards,
Sandy
--
Generation MSX
http://www.generation-msx.nl

On Monday 23 June 2003 00:30, Manuel Bilderbeek wrote:
> Several things about the share dir:
> 1) we all agreed (on IRC) that it would be better to have the ROM files
> of a machine or extension in a seperate directory roms. This has already
> been done for some machines and most extensions. But it is not done
> everywhere yet. Please donate some minutes and make the necessary
> changes to the hardwareconfig.xml file of the machines that are not
> 'converted' yet. If we all do a part, it will be ready fast.
I think it is a better idea to script this. There will be more changes to the
XML format, so it's worth investigating how to make changes automatically.
I'll look into it tomorrow.
> 2) What do we do with machines of the same type, but different country
> vresions? Example: Sony HB-F700D and HB-F700P (German and international
> version, respectively). The ROMs differ (keyboard matrix, e.g.)... Do we
> add both versions?
I think so. One user may prefer the German version and another user may prefer
the international version.
> 3) ISn't the share directory getting too large? It would be nice if the
> machine and extension configs could be put in a seperate CVS module; we
> could even release the sets separately from openMSX itself.
> ("Machine-pack"). What do you think?
In the future, this would be a good idea. However, currently there are still
regularly changes in the XML format, so machine packs would be limited to
specific openMSX versions, in which case it makes more sense to distribute
them together (what we are currently doing).
I also think it makes more sense to make a machine pack per machine. The
package would contain the hardwareconfig.xml, other info (pictures of the
real machine) and ROM files. We could put everything except the ROM files in
CVS, so people can easily create their own machine packs.
Bye,
Maarten

Hi
Several things about the share dir:
1) we all agreed (on IRC) that it would be better to have the ROM files
of a machine or extension in a seperate directory roms. This has already
been done for some machines and most extensions. But it is not done
everywhere yet. Please donate some minutes and make the necessary
changes to the hardwareconfig.xml file of the machines that are not
'converted' yet. If we all do a part, it will be ready fast.
Also, please add a roms subdir to the CVS repository. We could put the
MD5SUMS or SHA1SUMS in it (only the sums for the ROMs of that machine,
of course). And the roms subdirs will end up in the package, so that the
users only have to put the ROMs there.
If you're editing it anyway, please also check if the file is in UNIX
format (not DOS) and if it has the right VDP in case of an MSX1 (check
out VDP.hh: TMS9929A for PAL machines (check the bios ROM!) and TMS99X8A
for NTSC).
2) What do we do with machines of the same type, but different country
vresions? Example: Sony HB-F700D and HB-F700P (German and international
version, respectively). The ROMs differ (keyboard matrix, e.g.)... Do we
add both versions?
3) ISn't the share directory getting too large? It would be nice if the
machine and extension configs could be put in a seperate CVS module; we
could even release the sets separately from openMSX itself.
("Machine-pack"). What do you think?
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Feature Requests item #758868, was opened at 2003-06-22 20:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=421864&aid=758868&group_id=38274
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Benoît Delvaux (mars2000you)
Assigned to: Nobody/Anonymous (nobody)
Summary: Insertion of cartridges in console mode
Initial Comment:
On a real MSX, you can try with caution to insert a
cartridge in a slot when the MSX is on. It's not
recommended, but it's really useful if you have for
example a cheat program on a disk : you must first run
the MSX with the disk in drive A, insert the cartridge in
port 1 and run the cheat program, that will launch the
cartridge with some data modified ...
It should be possible to make that in openMSX by adding
this option in the console mode. By the way, some other
emulators (not all emulators) allow to make that .
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=421864&aid=758868&group_id=38274

On Saturday 21 June 2003 11:31, Manuel Bilderbeek wrote:
> Maarten ter Huurne wrote:
> > If the global settings file is made by the system administrator, then why
> > should we overwrite it?
>
> The administrator can be expected to read the documentation before
> upgrading: he can know the file will be overwritten. (If we put that in
> the docs.)
Just because something is documented, doesn't mean it's right. It is very
unconventional to overwrite hand-edited configuration files, so there will be
admins that overlook this point. The admin should read the release notes on
an upgrade, but I don't think you can expect him to read the entire manual
before every upgrade.
Also, I don't see any advantage to overwriting the global settings file, while
there are clearly drawbacks.
> Besides, suppose he uses a package manager: at least in Debian, you are
> prompted what to do when a configuration file in the package differs
> from the one already installed. You can choose to keep the old version,
> overwrite it, check the diff, etc.
If a package manager supports that, the packager is free to modify the
installation procedure to take advantage of that feature. But we also have a
"make install", which should behave in a predictable way.
Bye,
Maarten

Maarten ter Huurne wrote:
> If the global settings file is made by the system administrator, then why
> should we overwrite it?
The administrator can be expected to read the documentation before
upgrading: he can know the file will be overwritten. (If we put that in
the docs.)
Besides, suppose he uses a package manager: at least in Debian, you are
prompted what to do when a configuration file in the package differs
from the one already installed. You can choose to keep the old version,
overwrite it, check the diff, etc.
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

On Friday 20 June 2003 21:21, Manuel Bilderbeek wrote:
> Maarten ter Huurne wrote:
> > Good point. The system-wide settings.xml was introduced to give system
> > admins a way to set reasonable default settings for their users. So we
> > assume that someone will be altering the file. Then it doesn't make sense
> > to overwrite it with every release. Also, it is redundant to keep default
> > both in the code and in the installed settings.xml. So I propose not to
> > install a settings.xml file.
>
> The advantage is that the default settings can be determined by the
> system administrator without recompiling the program. I think we should
> keep the global settings.xml.
I'm not saying we shouldn't keep the feature, I only think it is better not to
install the settings.xml file. In the HOWTO we can explain how an admin can
take the settings.xml file from his home dir and promote that to the system
default.
Actually, system-wide config files should be in /etc instead of /opt, maybe
that's causing part of the confusion. I don't think any program's install
procedure overwrites files in /etc.
> Note that Laurens uses the Windows version
> of openMSX. I don't know how the install procedure is arranged there.
The problem he describes occurs on Linux too. The difference is that on Linux,
the user is more likely to edit ~/.openMSX/share/settings.xml rather than
/opt/openMSX/share/settings.xml.
> Anyway, the global settings file should be overwritten, but not the
> local one in the user's home dir, IMO.
If the global settings file is made by the system administrator, then why
should we overwrite it?
Bye,
Maarten

Manuel Bilderbeek wrote:
> Maarten ter Huurne wrote:
>> Good point. The system-wide settings.xml was introduced to give
>> system admins a way to set reasonable default settings for their
>> users. So we assume that someone will be altering the file. Then it
>> doesn't make sense to overwrite it with every release. Also, it is
>> redundant to keep default both in the code and in the installed
>> settings.xml. So I propose not to install a settings.xml file.
>
> The advantage is that the default settings can be determined by the
> system administrator without recompiling the program. I think we
> should keep the global settings.xml. Note that Laurens uses the
> Windows version of openMSX. I don't know how the install procedure is
> arranged there. Anyway, the global settings file should be
> overwritten, but not the local one in the user's home dir, IMO.
Installation procedure? Just unzip the archive in the openMSX dir ^_^.
~Grauw
---
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!

Maarten ter Huurne wrote:
> Good point. The system-wide settings.xml was introduced to give system admins
> a way to set reasonable default settings for their users. So we assume that
> someone will be altering the file. Then it doesn't make sense to overwrite it
> with every release. Also, it is redundant to keep default both in the code
> and in the installed settings.xml. So I propose not to install a settings.xml
> file.
The advantage is that the default settings can be determined by the
system administrator without recompiling the program. I think we should
keep the global settings.xml. Note that Laurens uses the Windows version
of openMSX. I don't know how the install procedure is arranged there.
Anyway, the global settings file should be overwritten, but not the
local one in the user's home dir, IMO.
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Hi
See attached e-mail.
Also, according to Alex, all MSX2+ machines and up have a memory mapper,
since it is part of the standard since the MSX2+.
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Maarten ter Huurne wrote:
> However, it does not work well with files that are saved by openMSX.
> How do you know whether the user selected line accuracy as an
> explicit choice or because it is the default? A reasonably curious
> user would change every setting at least once just to see what it
> does, so "it was never changed" is not a good criterium.
I understand the problem, and I realized that it would probably turn up :)
hehehe.
Personally, I think it would be a good solution to create a 'default' option
for every setting, so that I could do set renderer default. Whether to list
this as a specific option in the 'tab-help' of the setting (with the
specific value behind it in brackets, for example: default (SDLHi)), I don't
know. I think it should, but you figure that out :).
Anyways, I see this in a lot of software, and it seems to work pretty ok.
For example, in Trillian (my icq/msn/irc client), a sound can be played when
there's an incoming message. Now there are 3 places where I can set such a
setting: globally per messenger service (if default it reverts to the
builtin defaults), in an (optional) container of multiple windows (default
takes the global setting), and in the window itself, hence creating a
specific setting for a specific user (default takes the container's
setting - or, if not in one, the global one). So you see, if for some reason
you would want to nest certain settings in the future, it would be no
problem to implement either if you already know 'default' as a setting.
~Grauw
---
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!

Hi,
A lot of reactions. Good!
I'll make a combined reply to the on-topic comments.
On Thursday 19 June 2003 19:46, Manuel Bilderbeek wrote:
> > - When the user upgrades to a newer openMSX version, it should try to
> > come up with settings as close as possible to the user's settings for the
> > older openMSX version. Question: can the old settings file be
> > overwritten, or should it remain available in case the user wants to run
> > multiple openMSX versions on the same machine?
>
> I think we can ignore the old version of the settings until we reach a
> reasonable stable settings file format (1.0.0?).
It's true that we don't make any version compatibility promises before 1.0,
but we cannot magically introduce backwards compatibility in the 1.0 release
we didn't design, implement and test it well in advance.
> There will be many new
> versions of openMSX. In case there are only additional settings, the old
> ones should be loaded and the new one should be saved together with the
> old ones when exiting.
This is the design I am thinking of:
There are two types of changes:
- compatible: settings are added or removed, but the DTD stays the same
- incompatible: a new DTD
For compatible changes, every old setting that is no longer present, or
changed type, is ignored. Every new setting that was introduced, is
initialised to its default value.
For incompatible changes, we can look at the DTD field at the start of the
file and use the parser for that format. For a while, we ship both the old
and new parser. When we think most users have upgraded, we can remove the old
parser.
If we want to support multiple openMSX versions on the same system, we could
name the files "settings-0.3.1.xml", "settings-0.3.2.xml" etc. If we don't
consider this a useful feature, we can just call the file "settings.xml". I
think multiple versions is overkill, but I want to make this a conscious
design decision.
> > - How are settings grouped? Should everything be managed centrally (like
> > the commands), or should there be settings groups (like the current
> > RendererSettings class)?
>
> What are the pros and cons?
Centrally:
pro: all settings in one place, easy to load and save them all
con: the settings belong to unrelated parts of openMSX
Distributed:
pro: a setting is located close to where it is used
con: it is harder to find all settings that should be loaded or saved
> > - When are the settings objects initialised? Does it happen at startup or
> > on demand?
>
> I think we now initialise with certain built in values in case we can't
> find a settings.xml file or are missing parts of it, all at startup.
> What's the disadvantage of this?
Settings are currently initialised in a two step approach:
- the code that contains the setting initialises it to a value specified in an
associated <config> tag, it that exists, otherwise to a hardcoded default
value
- autocommands can be used to assign new values to technically already
initialised settings, before they are used, so to the user this looks like
initialisation as well
Initialising settings by autocommands is a hack, which will become obsolete
with the new design. The "settings.xml" file will be parsed and at that point
the parsed values must be stored somewhere in memory. The question I asked is
about where they are stored at that point.
Currently, they are stored in an MSXConfig object, which is basically a
DOM-like data structure. Then when the Setting objects are created, they look
in the config for their value.
An alternative would be to have the parser write the value directly in the
Setting objects. However, that would require:
- The Setting objects are either already constructed, or will be constructed
by the settings parser.
- The settings parser should know how to find the Setting objects. That would
be easy for a centralized settings repository, but non-trivial for settings
distributed over a lot of classes.
So settings are in a single "settings.xml", they are centralized at the one
end. And settings are used by lots of classes, so they are decentralized at
the other end. But question is where exactly is the right place to move from
centralized to decentralized.
> > - How is a setting object retrieved by the class using it? Options:
> > * dynamic_cast<IntSetting>(getSetting("blur"))
>
> This is nice, but the cast is ugly. I like getting 'just a setting'
> without bothering about the type. OTOH, you need to know the type
> anyway... What about getting all settings as strings and checking the
> type when the setting is 'set'? In this way, the return values as
> strings can always successfully converted to the native type.
That will be very inconvenient when using the settings. For example, I don't
want to do string to integer conversions in the renderers for getting the
current blur / scanline / glow value.
Besides, often the way to verify the type of a string-encoded value is to
perform the conversion and check whether that returns an error. So if you're
already doing a conversion on set, why not keep the converted value in the
Setting class?
On Thursday 19 June 2003 19:31, Wouter Vermaelen wrote:
> > - A setting may be ignored if the current system / active components /
> > machine do not support it. Example: some special effects are only
> > available in the GL renderer. Example: MSX-MUSIC volume is only relevant
> > for machines that have MSX-MUSIC. If the code that uses a setting
> > considers its current value invalid, it can decide to use a different
> > value. Example: console width will be clipped if it exceeds the number of
> > characters that fit in the available space. In both cases (ignoring and
> > using a different value), the setting's value is left unchanged.
>
> Most settings that have no effect are simply not available. For example
> when there is no MSX-MUSIC inserted the setting to change the volume is
> not available.
By "not available", you mean no Setting object is created?
> I think currentlt onlt the renderer settings are always available. Maybe
> we can also hide these settings? Note that when we switch GL->Hi->GL we
> want to keep the GL specific settings.
So there are two decisions to be made about settings that are not applicable
to the current situation:
1. Should they be visible to the user?
2. Should their values be remembered?
I think the answer to point 2 is clear: we want to remember the value. This
includes the example you gave (switching renderers), but also persistence: if
you run a machine without MSX-MUSIC and then save the settings, the MSX-MUSIC
volume setting should be saved.
I didn't really think about point 1 until now. It makes sense to offer users
the choices that actually matter at that moment, but that also means certain
settings are unreachable for users unless they run certain configurations,
which I am a bit uncertain about.
> > - Settings should have a separate XML format (different DTD) from machine
> > configs, because it is something else. The only reason both use the same
> > DTD right now, is that they evolved from a single file format.
>
> Note that currently settings.xml contains more than just the settings as
> described in this mail. Examples are Mixer settings, UserDirectories and
> AutoCommands.
Aren't mixer settings also settings? They are in the sense that they're user
preferences. However, they cannot be varied at run time. Is that a
requirement for settings? Some programs show "this change requires a restart"
notices, but I really dislike those. Can the mixer implementation be changed
to make frequency and buffer size adjustable at run time?
I think UserDirectories is a setting, but a new type that is not yet supported
by any Setting subclass.
AutoCommands are currently used for:
- Specifying values to settings which have no <config> tag. This is no longer
necessary in the new settings design.
- Non-standard key binding. We should design a replacement for that, so that
key bindings are saved as part of / together with the settings.
- Plugging in input devices, inserting disks etc. This should also be possible
from the command line. For disks / roms / tapes that is possible already, for
joysticks etc it isn't, but IMO it should be, so a launcher could be used to
select that you want to play a certain game with a specific joystick.
We once invented AutoCommands because it was the simplest way to implement a
lot of features of which the design was not yet clear. Now that we better
understand these issues, I think we no longer need AutoCommands as part of
settings.xml. Maybe we can keep the feature by loading a command script from
a user-specified file, if that is considered useful. But it should be
separate from the settings.
> > - Settings can be written back to XML by openMSX. This can be through an
> > autosave or through an explicit save (to be decided, but does not have
> > much impact on the design).
>
> I think we should make this configurable
This leads to the paradoxal question: should the fact that autosave was turned
off be saved automatically or not?
I think the choice depends on the UI. In the current UI, which is focused on
power users, explicit save would be good. But when moving to a GUI, I think
autosave would work better. KDE seems to be moving this way and in practice
it works fine. Seeing your desktop the way you left it is more natural than
seeing it restored to a fixed state. And if that's true for a programmer like
me, who is used to think in procedures, it's probably even more true for the
average user.
> > - Frontswitch is not a setting, it is a persistent state (like SRAM) of a
> > specific machine. Implementing it that way solves the problem that
> > machines without a front switch complain about the setting.
>
> What command should we make then? Just "frontswitch <bool>".
That would work.
Maybe we should assign a key to toggle it (if we have keys left). And skins
could have the option of showing the current state on screen, either
continuously or only when it changes, depending on the skin's look.
> A related
> command is "pausekey" (to control turbor pause key, not yet implemented)
> This one is nether a setting nor persistent.
It's a lot like the reset button really, only it has a state instead of just
sending an event.
Speaking of pause, the current implementation of openMSX pause (the one that
freezes EmuTime at end of frame) uses a setting, but should not be
persistent. How to deal with that? The mechanisms for access from the
console, for toggling and for observing (to be implemented) are the same as
settings, so it would be a shame not to share the code. The only difference
is that it is not persistent.
Actually, I have some doubts about making "fullscreen", which is clearly a
setting, persistent. If I start a program in a windowed environment, I expect
it to start windowed, even if it was last exited in full screen mode. Both
Xine and MPlayer seem to work that way, although I'm not sure they save
settings at all.
For the turbo R pause key it is different: this one influences emulation. In
R800 mode, it is handled by the BIOS, so the only thing openMSX does is flip
a bit in some I/O port. In Z80 mode, it acts like the MSX2+ pause keys and
halts the Z80 (VDP continues, the effect you see is a lot like screen
accuracy). Anyway, I think it is clear the turbo R pause key is a special key
rather than a setting.
> > - How are settings grouped? Should everything be managed centrally (like
> > the commands), or should there be settings groups (like the current
> > RendererSettings class)?
>
> Why should settings be grouped. Currently we do this for renderer settings
> because these are shared between different renderers. All other settings
> are kept by the objects that needs them.
Good point. But I would like to choose between centralized and decentralized
first; if we choose decentralized then we can decide whether it is useful in
general to group settings, or only for specific cases such as the renderers.
If we want to save the settings, then a single method should be able to track
down the value of every setting in openMSX. There are different ways to do
this:
1. Keeping the settings themselves centrally.
2. Registering settings at a central location, but ownership of the settings
objects remains decentralized.
3. Put code in the settings save method that contains a "getValue()" call for
every setting in openMSX.
4. Keep a DOM-like shadow administration of settings values. This is kept
up-to-date every time a setting value changes. When saving, this structure is
converted to XML, without touching the actual Setting objects.
I don't like option 4 because it involves duplication of information: every
setting is kept in two places.
The problem with 3 is that tracking down the objects which contain settings
could be difficult. Also having the save method refer to all users is not
really decentralized.
The problem I see with option 2 is that if a setting does not exist at startup
(Setting object was not created). So it this setting becomes active later
(maybe even in another execution of openMSX), its value is lost. Also there
is an initialisation sequence problem: the settings file cannot be parsed
until all settings are registered and settings cannot be registered before
the classes using them are instantiated, at which point the settings values
are needed already.
The mentioned problems of option 2 can be solved by introducing a centralized
data structure containing the values of settings that are not yet registered.
This data structure is created by the settings parser. Then openMSX starts
creating devices etc, which register settings. For each setting registered,
its member in the unregistered settings data structure is removed. When
saving the settings, both the registered and the unregistered settings are
saved. While this would work, it seems to me like a more complex version of
centralized settings. The main difference with option 1, is that the setting
type and range checks can be done by the using class, instead of centrally.
My current preference is option 1. Option 2 would be acceptable, if there are
good reasons to choose it. I don't think option 3 and 4 are a good idea,
unless I made some mistake in evaluating them.
How we handle settings that are currently irrelevant (hide them or not?) may
have an influence on this decision as well.
On Thursday 19 June 2003 20:04, Laurens Holst wrote:
> And ah, yes, I indeed found it pretty lame that when I upgraded to 0.3.1 I
> had to make all my settings again :).
It's one of the things that can happen with alpha software. However, as I
replied to Manuel earlier, we should start designing in such a way that
events like that become increasingly rare.
> So it'd be nice if there were some
> solution to that (revert to defaults if a setting is not in the config file
> sounds ok). And a template settings.xml file of some kind, explaining all
> the settings and file layout?
We can have a documented DTD. But once the file is written by openMSX, you no
longer have to edit the XML manually. Instead you can change it from the
console, where every setting has a description of what it does. In the
future, settings will be adjustable from a GUI.
On Thursday 19 June 2003 23:02, Manuel Bilderbeek wrote:
> You could have saved and copied your old settings.xml file.
But in reality, users make far too little backups. We should try to not to
give them unpleasant surprises nevertheless. Besides, even if you have a
backup, having to restore the data is still an inconvenience.
On Thursday 19 June 2003 23:47, Laurens Holst wrote:
> > You could have saved and copied your old settings.xml file.
>
> Yah, I could have, had I realized in advance that it would be
> overwritten -_-;;.
Actually, why was it overwritten? I don't see the current "make install"
command write to ~/.openMSX. Was that different for the 0.3.1 release? Or did
you edit the installed version (in /opt/openmsx)? I think that if you edit an
installed file, you can expect it to be overwritten in the next release. For
example, if you edit an installed image file.
> I know that, but seeing your remark that openMSX initializes with builtin
> values, why would there be a need for a settings.xml initially at all?
Good point. The system-wide settings.xml was introduced to give system admins
a way to set reasonable default settings for their users. So we assume that
someone will be altering the file. Then it doesn't make sense to overwrite it
with every release. Also, it is redundant to keep default both in the code
and in the installed settings.xml. So I propose not to install a settings.xml
file.
> There's no need to 'update' your old settings.xml with the new options,
> because when the new options aren't in there, openmsx reverts to its
> builtin defaults, so keeping the old settings.xml doesn't do any harm. It
> seems the best way to be a bit more user-friendly to the upgraders, and
> keep their settings. It'll also make settings.xml a lot more clear, since I
> could also only include the settings different from the defaults. This also
> means that if you guys decide a certain setting is better (for example the
> pixel accuracy's speed has become almost as fast as line accuracy, so you
> set the default to pixel accuracy from now on), if it hasn't been
> specificly specified in my custom settings.xml it'll also change together
> with the upgrade.
This works well for hand-edited files. For example openSSH does this: it puts
all the default settings in comments, the only active settings are those you
manually changed.
However, it does not work well with files that are saved by openMSX. How do
you know whether the user selected line accuracy as an explicit choice or
because it is the default? A reasonably curious user would change every
setting at least once just to see what it does, so "it was never changed" is
not a good criterium.
Bye,
Maarten

Manuel Bilderbeek wrote:
> Laurens Holst wrote:
>> And ah, yes, I indeed found it pretty lame that when I upgraded to
>> 0.3.1 I had to make all my settings again :). So it'd be nice if
>> there were some
>
> You could have saved and copied your old settings.xml file.
Yah, I could have, had I realized in advance that it would be
overwritten -_-;;.
>> solution to that (revert to defaults if a setting is not in the
>> config file sounds ok). And a template settings.xml file of some
>> kind, explaining all the settings and file layout?
>
> There is comment in the file that explains what it is. Also, the
> default file contains all possible settings, so the file layout
> should be clear. ;-)
I know that, but seeing your remark that openMSX initializes with builtin
values, why would there be a need for a settings.xml initially at all? If
you don't include one, it would provide an easy way to keep the old
settings. I won't have to make a backup copy of settings.xml before
installing, and I won't have to adapt the file to include new options
either. And this not only goes for me, but everyone who has somewhat
customized openMSX its settings, which includes everyone who set another
machine than the CBIOS one as default.
There's no need to 'update' your old settings.xml with the new options,
because when the new options aren't in there, openmsx reverts to its builtin
defaults, so keeping the old settings.xml doesn't do any harm. It seems the
best way to be a bit more user-friendly to the upgraders, and keep their
settings. It'll also make settings.xml a lot more clear, since I could also
only include the settings different from the defaults. This also means that
if you guys decide a certain setting is better (for example the pixel
accuracy's speed has become almost as fast as line accuracy, so you set the
default to pixel accuracy from now on), if it hasn't been specificly
specified in my custom settings.xml it'll also change together with the
upgrade.
Now I know this, I will ofcourse make a backup copy of it next time I
upgrade (or maybe I'd have forgotten it again by then). My point is though,
it's a bit nasty if every user has to discover this through 'trial and
error'. And yes, it may be in the (not too small) documentation, but it
isn't something everyone will read through in its entirety before trying
out/upgrading openMSX. So all this could be avoided by making a couple of
quite minimal changes, which will not only make such mistakes less annoying,
but also make the upgrading process easier.
In any case, I'd say it would be nice to rename the file to
settings-template.xml or something, so that it doesn't overwrite any
custom-made settings files. It's an easy change which I -from a
user-point-of-view- would really appreciate. What you could also do is
rename the file to settings-default.xml, which openMSX attempts to load if a
settings.xml isn't found... But then again, people might make their changes
in settings-default.xml instead of creating their own settings.xml, and it
would also be too easy to break openMSX's functioning or giving it
uninitialized memory areas, so I don't know how good that idea is. Ahwell,
just my two (euro)cents.
~Grauw
---
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!

Laurens Holst wrote:
> And ah, yes, I indeed found it pretty lame that when I upgraded to 0.3.1 I
> had to make all my settings again :). So it'd be nice if there were some
You could have saved and copied your old settings.xml file.
> solution to that (revert to defaults if a setting is not in the config file
> sounds ok). And a template settings.xml file of some kind, explaining all
> the settings and file layout?
There is comment in the file that explains what it is. Also, the default
file contains all possible settings, so the file layout should be clear. ;-)
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details