emulator ID I/O port

Page 5/7
1 | 2 | 3 | 4 | | 6 | 7

By dvik

Prophet (2200)

dvik's picture

05-06-2009, 20:42

Farting on the moon is like peeing in the ocean?

By PingPong

Prophet (3754)

PingPong's picture

06-06-2009, 10:12

why not an unused opcode?, because ld b,b can be use just for wasting time like NOP.

Because there may be versions of the Z80 in the future which use them.
When you find a similar version let's us know--- Tongue

By mth

Champion (496)

mth's picture

06-06-2009, 14:05

Increasing the emulation speed is only one exemple. Of course, it could be done in various ways. As flyguille pointed out, using the ld b,b or similar methode also can have undesirable side effects. Using still unused opcodes can conflict with (alas very unlikely) future development of new hardware. You would spend one of the limited unused opcodes for something which is better done another way.

I agree that using documented NOP-equivalents is not a good idea, but using opcodes that have no documented or undocumented-but-standardized (IXL/IXH etc) function is safe enough in my opinion. It is very unlikely that a commercial new Z80 will be made with an expanded instruction set. There could be a new Z80 core from the amateur scene, but in that case it can adopt the extensions we originally designed for emulators. In other words, a new Z80 core could switch CPU speed using the same new instruction.

Suppose you have a program which is able to change its emulated speed by communicating with the emulator via a dedicated port. What would happen if it would do so on the real MSX hardware? As the port is not connected to anything, it will happen nothing! The programm will just continue running on its normal speed.

The same is true for claiming an unused opcode, since afaik the unused opcodes have no effect.

In general, I prefer to implement virtual extensions in the same way as it would be implemented in real hardware. In the case of clock speed control, that would depend on where the clock divider is. For MSX 7MHz, that divider is external to the CPU, so it might be better to use an I/O port.

Why do you need every software to run on the real thing?

Because if you drop that requirement, an emulator becomes a very awkward API for making PC games. Why limit yourself to 8-bit registers, small monochrome sprites, simple sound chips etc if you don't care about compatibility with the real hardware?

So while I think it is useful to add some enhancements for emulators to new MSX software, it should be optional features in my opinion.

But if you want to write new software for MSX which needs to access up to day's technology (USB etc.), why sticking to the limitations of the technology form about 20 years ago? To provide access to up to date technology brings MSX up to date, at least virtually.

But why write MSX software at all then?

By mth

Champion (496)

mth's picture

06-06-2009, 14:34

3: This could be useful, but I'm not sure a single emulator detection / control port would be the best way to do it.

We should reserve 8 or 16 ports for emulator access.

My original wording was not accurate, please replace "port" by "device".

It doesn't really matter how many ports that device uses, what matters is whether emulator extensions are implemented as extensions of existing devices where possible and new separate devices otherwise, or implemented in a single emulator specific device.

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.

Example:

The AMSX emulator 1.0 supports feature 1 and 2.
The BMSX emulator 2.0 supports feature 2 and 3.

An MSX program wants to use feature 3. So it runs the code that uses feature 3 if BMSX 2.0 or higher is detected.

Now some time passes and new emulator releases appear.
The AMSX emulator 1.1 supports feature 1, 2 and 3.
The BMSX emulator 2.1 supports feature 2, 3 and 4.
The CMSX emulator 0.1 supports feature 1 and 3.

In theory, the MSX program could use feature 3 on all of the mentioned emulators. However, because it was written some time ago, it will only use feature 3 on BMSX, because at that time BMSX was the only emulator that supported feature 3.

If instead of a version check the MSX program queried support for feature 3 directly, it would automatically start using that feature on new emulator releases.

Additionally, keeping the feature mapping inside the emulators instead of inside the MSX programs makes the feature check code in the MSX program a lot simpler.

By mth

Champion (496)

mth's picture

06-06-2009, 14:41

If we want to retrofit existing games for which no source code is available with emulator extensions, it is a big advantage if the amount of code required to activate an extension is small. After all, this new code has to be inserted somewhere in for example a ROM image and the amount of free space inside ROMs is usually quite limited.

Therefore I think selecting extensions using ASCII strings is not the way to do it. Using register numbers instead would lead to much smaller code.

This does not answer the "single device vs separate devices" question however.

By Tanni

Hero (556)

Tanni's picture

06-06-2009, 16:48

Increasing the emulation speed is only one exemple. Of course, it could be done in various ways. As flyguille pointed out, using the ld b,b or similar methode also can have undesirable side effects. Using still unused opcodes can conflict with (alas very unlikely) future development of new hardware. You would spend one of the limited unused opcodes for something which is better done another way.

I agree that using documented NOP-equivalents is not a good idea, but using opcodes that have no documented or undocumented-but-standardized (IXL/IXH etc) function is safe enough in my opinion. It is very unlikely that a commercial new Z80 will be made with an expanded instruction set. There could be a new Z80 core from the amateur scene, but in that case it can adopt the extensions we originally designed for emulators. In other words, a new Z80 core could switch CPU speed using the same new instruction.

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.

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.

By Tanni

Hero (556)

Tanni's picture

06-06-2009, 17:01

Suppose you have a program which is able to change its emulated speed by communicating with the emulator via a dedicated port. What would happen if it would do so on the real MSX hardware? As the port is not connected to anything, it will happen nothing! The programm will just continue running on its normal speed.

The same is true for claiming an unused opcode, since afaik the unused opcodes have no effect.

Yes, but see my last post.

In general, I prefer to implement virtual extensions in the same way as it would be implemented in real hardware. In the case of clock speed control, that would depend on where the clock divider is. For MSX 7MHz, that divider is external to the CPU, so it might be better to use an I/O port.

Admittedly, that seems elegant, but I think that we should not mess up emulator stuff with real thingy stuff. You might want to just increase emulation speed for development, but keeping the speed of the emulated program original.

By Tanni

Hero (556)

Tanni's picture

06-06-2009, 17:16

Why do you need every software to run on the real thing?

Because if you drop that requirement, an emulator becomes a very awkward API for making PC games. Why limit yourself to 8-bit registers, small monochrome sprites, simple sound chips etc if you don't care about compatibility with the real hardware?

So while I think it is useful to add some enhancements for emulators to new MSX software, it should be optional features in my opinion.

Seems to be a very weird point of view. I gave an exemple why I e.g. like to have external filesystem access. I don't see it form a gamer's or game developer's point of view.

Surely, I care about compatibility with the real hardware.

Posting in a thread like that, I presuppose that everything we discuss must be enabled. If it isn't, the emulator would not do all of that extra stuff. So compatibility is maintained. I also see these emulator extras as experimental. They are not supposed to be used by software which is meant to closely conform to the standard. They are supposed to be used for users convenience or experiments or for applications which are not supposed to run on the real hardware.

But if you want to write new software for MSX which needs to access up to day's technology (USB etc.), why sticking to the limitations of the technology form about 20 years ago? To provide access to up to date technology brings MSX up to date, at least virtually.

But why write MSX software at all then?

Why are all the people here still engaged in MSX?

Maybe nostalgia, or maybe because I like to use Turbo Pascal for my personal projects. Or maybe to see if things are possible and, if so, how far we can go?

By Tanni

Hero (556)

Tanni's picture

06-06-2009, 17:28

3: This could be useful, but I'm not sure a single emulator detection / control port would be the best way to do it.

We should reserve 8 or 16 ports for emulator access.

My original wording was not accurate, please replace "port" by "device".

It doesn't really matter how many ports that device uses, what matters is whether emulator extensions are implemented as extensions of existing devices where possible and new separate devices otherwise, or implemented in a single emulator specific device.

But I still think we should reserve 8 or 16 port adresses for emulator access.

The emulator might pass the feature/device request done via that ports to DLLs implementing the virtual device. This might also solve the problem with the feature to device mapping. This would be like the plug in of real devices in a real MSX. So one and the same emulator could be configured with different virtual devices at different times. Also updated virtual devices would be possible. The user would be responsible to provide that DLLs or the emulator itself could contact an online repository for devices and see if it can get something suitable. But then, you need to provide an unique name -- and version number -- for the virtual device. The software need to issue a device request to the emulator, and gets an errorcode or a device number for virtual device accessing purposes in return.

By mth

Champion (496)

mth's picture

06-06-2009, 17:34

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.

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.

Admittedly, that seems elegant, but I think that we should not mess up emulator stuff with real thingy stuff. You might want to just increase emulation speed for development, but keeping the speed of the emulated program original.

There are two different ways of speeding up in an emulator: increasing the CPU clock and changing the ratio between emulated time and real time. I think the former is more useful for games, since sound and interrupt timing would remain unchanged. The latter can be used for example to speed up an assembler, but in that case increasing the CPU clock would also be an option and would be more efficient as well (no need to emulate the VDP at a higher frequency).

The only reasons I see for speeding up by changing the emulated/real time ratio are:

  • the MSX software might not behave correctly at a different Z80 clock
  • the MSX software is slowed down by something other than the Z80

The former should not be the case for programs written to specifically support speedup. The latter is typically slow unskipable animations and it makes no sense for a program to work around its own bad design Wink In some cases it might be VDP command engine slowness, but then a better solution would be to make a VDP extension to speed up the command engine.

So I think that for speed control by the MSX program itself, it only makes sense to manipulate the CPU clock. For speed control by the user, changing emu/real time ratio is very useful though.

Page 5/7
1 | 2 | 3 | 4 | | 6 | 7