emulator ID I/O port

Página 7/7
1 | 2 | 3 | 4 | 5 | 6 |

Por Tanni

Hero (556)

Imagen del Tanni

06-06-2009, 18:51

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..

Yes, but there are still other issues. (Who owns the standard, are we allowed to extend it, etc.)

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.

Yes, but therfore, you need time to figure it out. Doing it proper is better than mixing it.

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.

Yes, of course!

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.

Yes. And as time goes by, there will be new ideas!

Por konamiman

Paragon (1159)

Imagen del konamiman

08-06-2009, 12:07

dvik's reason to add it to Lotus F3 was fair, to prevent people submitting highscores when cheating
When Konami released Nemesis 2 in Japan, they organized a hi-score contest for that game (the contest ended 21 years ago, so don't hurry to grab your joystick) Tongue In order to prevent cheating, they included a hash value to each high score (it is the four-digit number that you can see in the game over screen), so when submitting the score, you had to submit the hash as well. Maybe this system can be useful for nowadays' amateur games as well.

Emulators should emulate, not create virtual reality
I completely agree here. What's the point of adding features to an emulator, that are not present in a real MSX? If you think MSX computers are too limited, go ahead and develop your software directly for PC. But don't say it is MSX software if it will not run (or will run with limitations) on a real MSX.

I must say that it is not that I hate emulators. Quite the opposite, I find them very useful for developing new software (I love the debugger that comes with blueMSX, for example). But adding "new game features for emulators only" seems pointless to me.

Por Tanni

Hero (556)

Imagen del Tanni

08-06-2009, 13:48

Emulators themselfes provide some kind of ''virtual reality'' to the MSX software!

The extentions I primarily have in mind aren't gameing related. I want to get rid of some restrictions which would have been already overcome if the real system were not abandoned for ten years.

Por Tanni

Hero (556)

Imagen del Tanni

08-06-2009, 16:29

Proposal concerning a software to emulator interface (very sketchy)

One or two ports for emulator access interface:

  • Port for emulator-specific functions: sending emulator-specific CTRL sequences

    This port is for development, testing and for reaching emulator-specific functions not available in the standardizised interface port

  • Port for standardizised virtual device communication: The emulator itself is a virtual device for the software.

    This interface provides functionality in an generic form, i.e. functionality that doesn't depend on a specific emulator.

    It may provide a function which allows to send emulator-specific CTRL sequences.

For each function, there must be subfunctions for getting the amount and identification of it's subfunctions:

  • name of the function/subfunction
  • directions: read, write, read and write?
  • types: specification of the types of parameters and returned values
  • modus of passing the parameters and values: adressed via pointer, stack, passing via port
  • short explanation


  • emulator identification

    1. name
    2. code (assigned according to the order of the release dates of the emulators)
    3. version
    4. date of release

  • send message to be displayed on the emulator
  • send emulator-specific CTRL sequences
  • identify emulator functions (get amount and name of general (standardizised) emulator functions)
  • change emulator-specific settings (emulation speed, size of emulator window, rendering algorithms, machine, theme, ...)
  • change emulation-specific settings (change MSX1 palette, change palette, ...)
  • get amount of virtual devices installed
  • virtual device available (searches the DLL database for a certain device)
  • virtual device identification

    Get name, version, provider, release date, DLL-type, amount of provided functions, names of that functions, short explanation and handle of a virtual device DLL.

    DLL-type: emulator-specific, platform-specific, pseudocode, ...

  • virtual device access (provides open, read, write, close operation on selected device)
  • internet access

    1. connected?/allowed?
    2. set URLs for registry request/download/upload?

    Wouldn't it be better if that would be a DLL?

  • MSX related media handling (insert and eject cartridges, cassettes, dsk-files, ...)
Página 7/7
1 | 2 | 3 | 4 | 5 | 6 |