Following the discussion in the meisei 1.3 newspost it's clear that it can be useful to MSX software developers to have an emulator detector. As emulators get more accurate with every release, it will eventually be near-impossible to detect one. So I'm proposing a dedicated I/O port for this. If openMSX and/or dvik follows, I'll add it to meisei too.

I/O port: dunno yet which.
After writing "h", write "i" to it, consecutive reads will return ":", "D", then a couple of values indicating the emulator (eg. 1 for blueMSX, 2 for openMSX, 3 for ESE3, etc), emulator version, and other parameters we may find useful.
On reset, invalid writes, and after the reads are done, this port will behave as unmapped.

If openMSX agrees to add this, mayhaps dvik can reveal his openMSX-detection secret.

But, what's the use of emulator detection? IMHO, this shouldn't exist. Instead, emulators should be improved to support the software that runs on real machines properly... There shouldn't be a need to detect emulators at all.

dvik's reason to add it to Lotus F3 was fair, to prevent people submitting highscores when cheating, eg. disabling collision in an emu, or savestating their way through a race.

It could be useful to have detection, to use an emulator's bonus features to enhance your game. Think of the custom palette in meisei, just to name something.

Such a bonus enhancement would be specific to a single emulator, eg. being able to control meisei psg toy or custom palette, would you really use it?

It seems to be a very good idea, hap! A program should be able to detect if it's run by an emulator -- and especially by which one. In addition to get the emulator code, it should also provide the emulator's name and version, so the software need not hold these names in an extra array, which would save valuable memory space.

Manuel, there may be programs besides games which would become more convenient if they would be able to deal with several features of an emulator. Imagine, if a software would be able to detect that it is emulated and knows the actual emulator and version, there could be communication with it's emulator. Consider the possibilities! The software might tell the emulator to change emulation speed (by sending the particular control sequences), gets access to external devices (disk drives, USB, etc.) via the emulator. It would go beyond just emulating a legacy system and encourage people to write new software for MSX (which of course is then not to be executed at the real hardware).

See here for further possibilities:

www.bluemsx.com/blueforum/viewtopic.php?t=1620

External file system access via an emulator

I would like to do some text analysis with blueMSX and Turbo Pascal on texts I've written under Windows. Of course, it would be possible to put these texts into .dsk-files using the diskmanager, but it would be more convenient to have direct access to the external filesystem of the computer.

I also want to code some/have some Pascal programs on blueMSX which do text output. It would be very convenient to have direct access to them, because the Turbo Pascal editor I use in MSX only supports 40 characters per line; so using the Windows notepad editor is more convenient for writing and modifying the texts.

Besides emulator identification, to implement external file system access, some I/O ports could be dedicated for communication between MSX-software and the emulator. It would be necessary to devise an interface for that.

Maybe it also could be done via the AUX device of MSXDOS?

Was AUX ever used for something in MSX?

It's in the same category as wolf_'s suggestion, not my initial plan.
Actually, isn't that already possible with "dir as disk"?

Maybe, but it would be nice to have this. And if we start assigning I/O-ports for emulation purposes, we should go straightforward and do it well and proper and ..., you know what I mean.

I still use blueMSX 2.4, once installed a higher version, but reinstalled 2.4 for whatever reason, so I don't know about ''dir as disk'', shame on me!

I think an I/O port could be useful. I think its also nice to get the version of the emulator, to do for example patches like what I did in Utopia for blueMSX.

If you're going to do something like that, I agree with Tanni. Make a generic Emulator Interface Port to communicate with the emulator. Define a set of generic functions and the rest is up to the emulator programmers. I'm personally thinking of setting breakpoints from code. That way you can have a breakpoint at a certain location even though it changes while modifying code.

An interface like that could be useful for the 1chipMSX as well. Any maybe you could even make it in hardware. Then it would be more a Machine Interface.

I'd go for 2 bytes with that, one for emu ID, one for version, or would you rather have multiple bytes (2,8,1), and/or a string ("blueMSX\0", "meisei\0"?

What do other MSX Software developers think about the "hi are you an emulator?" "oh yes sir I am!", useful? useless? Chance it'd be abused? (if (is_emu) { give mean message and lock up(); }

*edit* Edwin: ok, what functions? ld b,b is common as software breakpoint btw.

Yes, I'd use it (palette, psg toy etc.).. (that is, Edwin would have to support it )

And it'd only work in meisei, until other emulators start supporting it in an identical way, which is not always possible. It may be possible when emulator makers agree on some sorta 'standard' regarding enhancements. An MSX1 palette would be the easiest cross-compatible effect among emulators.

Tanni, indeed, what you are suggesting can be fully done with dir-as-disk.

I still haven't heard convincing arguments to do this, really. MSX software shouldn't know about emulators at all. It will be hell if some software doesn't run on real machines or other emulators (or newer versions of the same emulator), because of some MSX code assuming emulator presence...

For debugging, there already exist tricks (like the mentioned ld b,b). We even have a debug device defined in openMSX. Code making use of it works fine on any other machine or emulator, so, the actual running of it isn't influenced by the fact that the debug device could be attached.

Patches like dvik mentioned shouldn't be there... emulators should be fixed instead, not the MSX software...

What's the use of the proposed MSX-controlled enhancements (palette, psg toy) if they only work on an (certain version of an) emulator? It's like creating artificial hardware extensions that don't exist in reality but only in an emulator... Completely pointless, IMHO. (Emulators should emulate, not create virtual reality.)

By the way, I remember that Vampier wrote a Tcl script a few years ago, that polled on a certain memory location for a byte. Different byte meant different action. He also wrote a basic program that controlled openMSX by writing the proper value to that byte...

I agree, that sometimes it would be nice to have Full speed on / off I/O port, but as this is anyway emulator only feature and therefore usable only for developing, it does not need to be standard.

Quote:

By the way, I remember that Vampier wrote a Tcl script a few years ago, that polled on a certain memory location for a byte. Different byte meant different action. He also wrote a basic program that controlled openMSX by writing the proper value to that byte...

..I'm using this same technic in my latest software the msx-multi-tracker(uses PSG SCC and OPL)...using the pc-freedom to create the tunes and then send the data thru openmsx-debugger-api to my replayer and play it...
I'm controlling the replayer entirely from the PC with memory-read-write commands...works perfectly !!
When I finally get my hands on a NOWIND-device(stats anyone?) I can (problably) do the same thing on a real MSX !!

And I do agree with manuel on this...you should not write software which can not be used on the REAL thing ! If we DO go down this road then pretty soon the hardware will become a bit "dissapointing" to use because you cannot for example create the same stunning effects on it as you can on the emulator(+)

Communicating with your software using special *emulator tricks* during development to speed up development YES but releasing finalized software which can only run on a particular emulator? Not such a great idea...
We all still wanna keep the MSX alive !! dont we ?!