emulator ID I/O port

So any kind of probing for emulator extras would have to be feature based: instead of asking "what emulator are you?" the program would ask "what features do you have?". Also, this would not be limited to emulators: new hardware could respond to the same queries.

The software could ask for the emulator's name and version just to display it on the screen. Ok, a little pointless, because the user should know the emulator used. But it would look nice and somewhat ''proper''.

It would ask ''Do you have the required feature?''

If your software requires a certain feature, it would be sufficient to test if it is run on a certain version of a certain emulator. See the LaTeX mechanism for version checking.

I don't know how LaTeX checks versions. However, LaTeX is a single program, so you can make a perfect mapping from a version number to a feature set. There are multiple MSX emulators and new ones might appear in the future. You could make a mapping from (emulator name, emulator version) to a feature set at the time your MSX program is written, but that mapping will be outdated with future emulator releases.

LaTeX is a macro package for TeX. I'm not an expert in LaTeX and know almost nothing about the version checking in LaTeX. But there are lot's of packages to be included and I remember that there is an elaborated mechanism to ensure that you get the required version of a package. I think we could do something similar. The problem behind is much similar to getting the right virtual device implementation for an emulator, as I pointed out in my last post.

This would solve all the problems you mention according to your exemple.

You never know what the future brings. (Did we expect things like the OCM in 1985?) Even if a new Z80 with expanded instruction set is unlikely (really?), we should not mix emulator stuff with hardware opcodes. This seems elegant on the first gaze, but messes things up. Even amateur cores need not be aware of all emulator used opcodes. In the worst case, there must be another amateur cores adapted for every emulator for every HC system. Using opcodes here would cause problems on the hardware design level, which is even worse

What I mean is, why would a company have the right to add to an instruction set and a community would not? Unless the company is Zilog itself, of course.

Because the company can produce the hardware and the community normally can not. There are Z80 clones with additional opcodes, but these are illegal, aren't they? Of course, you can add to the instruction set, creating a variant of the Z80 or R800. Variants are bad here! But that's not my concern. I don't like to have emulator dependent stuff mixed up with hardware stuff if it could be avoided. This will most likely cause problems in the future, because you can never know what future brings. Call it experience or intuition.

There is another problem: how is the information passed by that command? You might pass numbers (maybe randomly assigned to system clock frequencies) or (equidistant scaled) percent values. The former will be more hardware-like, the latter more approbriate to an emulator. A future hardware developer might have reasons to do that different that you expect it now.

I would prefer to use a setting that mimics the way hardware would do it. This makes it possible to later implement it in real hardware. It also avoids the spec favoring a particular emulator: although many parts of MSX emulators are very similar, there are differences in their designs as well.

Yes, I understand! But with that emulator extras I don't aim for later implementing it in real hardware. If you want to do it, that would be another issue. First do it with the emulator in a proper way, gaining experience for further expansions, because realizing it in hardware is far away, I think. (I also consider that whole emulator extras as gaining experience for maybe further MSX hardware, maybe MSX3. Therefore, we should not fix things unless we are pretty sure that they are useful.) If it's just changing emulation speed/changing chock speed, than all emulator implementing groups should agree in doing it in the same way. This could also hold for other emulation related issues. We are a community, aren't we?

What I mean is, why would a company have the right to add to an instruction set and a community would not? Unless the company is Zilog itself, of course.

Because the company can produce the hardware and the community normally can not.

With FPGA, the community can.

There are Z80 clones with additional opcodes, but these are illegal, aren't they? Of course, you can add to the instruction set, creating a variant of the Z80 or R800. Variants are bad here!

Incompatible variants are bad. Variants that add useful features in a compatible way are good.

By the way, I do agree that CPU clock setting should be done with I/O ports instead of opcodes, since this is easier for hardware implementations. I only think that there could be a good reason to introduce new opcodes at some point, even if there is no need for that right now.

But that's not my concern. I don't like to have emulator dependent stuff mixed up with hardware stuff if it could be avoided. This will most likely cause problems in the future, because you can never know what future brings. Call it experience or intuition.

The thing is that for most examples I've heard so far, they are not actually emulator specific. They are things that could be implemented in hardware in theory, but will be implemented in emulators first.

What do you mean with "DLL" exactly?

If it's a 32-bit Windows DLL, then it won't work on other platforms, which is a big deal for openMSX.

As I work with Windows, it's a Windows DLL, but, of course, it would be better if it would be some more generic.

If it's any kind of loadable module containing native code, then it becomes a big effort to make sure it is available for all operating systems and CPUs. Or if it isn't available for all, some users will be missing out. Would the same binaries work in all emulators, or would a different version be needed for every emulator? The former is very difficult to design, the latter means yet more diversity.

It doesn't need to contain native code, but pseudocode where the implementating group of an emulator is responsible to provide the mapping to the respective platforms. But maybe we got to far for now. There may be several ways to go, of course.

If it's not native code but interpreted code, we must get agreement from all participating emulator authors on which interpreter to use and which functions it can call. Not an easy task.

Not an easy task, but feasable. There aren't so much emulators around. And if someone won't participate, ok, his decision!

So I think this approach is not feasible. Instead, every emulator should include its own implementation of every enhancement feature it supports. This is also how it is done for the traditional MSX devices: we share source code sometimes, but no-one would attempt for example an SCC implementation that is binary compatible between openMSX and blueMSX.

I already mentioned that it's an experimental thingy. We are a community and we can talk about what we're going to do. We can try several approaches. Would be very interesting and cool, wouldn't it?