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...
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 ?!
@wolf_
I have to nag about terminology a bit first. An event is when something has happened and some other party is notified of that. What you are describing is more like ordering another party to do something, so I would call it a command rather than an event.
The example you describe could be useful. However, I would rather see it implemented as a VDP extension rather than as part of an emulator super-device. Similarly, setting PSG detune/vibrato/waveform could be implemented by writing new PSG registers.
By the way, if you only need red/green/blue values from 0 to 7, you can simply support the V9938/58 and it would work on real hardware too. In my opinion a palette extension only makes sense if it offers higher resolution of r/g/b values, for example from 0 to 255.
Having programs use features that are not implemented yet in any emulator is a recipe for disaster, in my opinion. Experience tells us that features that are untested most likely do not work as expected.