emulator ID I/O port

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

By wolf_

Ambassador_ (9884)

wolf_'s picture

30-05-2009, 19:02

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

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.

By Manuel

Ascended (18082)

Manuel's picture

31-05-2009, 00:26

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

By NYYRIKKI

Enlighted (5838)

NYYRIKKI's picture

31-05-2009, 01:22

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.

By RyJuZo

Master (236)

RyJuZo's picture

31-05-2009, 01:44


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

..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 ?!Smile

By hap

Paragon (2036)

hap's picture

01-06-2009, 20:18

On second thought, and after hearing your opinions, I agree it's not a good idea to enable this virtual device by default.

By NYYRIKKI

Enlighted (5838)

NYYRIKKI's picture

01-06-2009, 22:58

Making it possible to disable this device makes no sense...

I think that the primary function for this possible "device" would be to disable functionality if the software is run in an emulator. If this can be disabled, then there is no reason for this functionality to exist in a first place.

By mth

Champion (496)

mth's picture

02-06-2009, 00:11

Several uses were mentioned for an emulation detection port:
1. avoid cheating
2. work around emulator bugs
3. access to features not available on real hardware

1: Such a port doesn't really offer much protection. Most MSX emulators are open source, so anyone can download the source, remove the detection port, compile it and cheat without being detected.

At the MSX club (GG West Brabant) we had a high score competition and if someone announced really good scores at a game, that person was invited to show his/her skills at the next meeting. It helped to keep submitters honest and it was fun to see really good players in action. It might be difficult to arrange this on a global scale though.

2: I agree with Manuel: fix the emulator instead.

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

In any case I think it is a bad idea to query emulator name and version, because in the future new emulators might appear and existing emulators will get more features and it would be a shame if already released MSX programs could not take advantage of that.

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.

However, one super-device might not be the best implementation of this, because it breaks modularity. Instead, virtual hardware could use separate port numbers / slots. That way, it can be implemented in real hardware more easily. And in the case of openMSX, it fits nicely into the existing extensions mechanism.

By wolf_

Ambassador_ (9884)

wolf_'s picture

02-06-2009, 00:40

instead of asking "what emulator are you?" the program would ask "what features do you have?"
How about events?

An MSX program sends out an 'event' via some OUT or something, the event contains an ID and DATA. And whoever is listening can do something with this event. An ID could be an integer, meaning 'msx1palette'. The DATA could be: '000000070373007337...' etc. resembling a new palette. And if an emulator has support for this then it can parse it. If not, bad luck, but no harm done.

The advantage is that utils and games can *today* already have support for things that have yet to be supported by emulators.

By mth

Champion (496)

mth's picture

02-06-2009, 10:56

@wolf_
I have to nag about terminology a bit first. Tongue 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.

By wolf_

Ambassador_ (9884)

wolf_'s picture

02-06-2009, 11:43

The rgb colors are of course meant to be 24 bit, they 3-bit range was a mere example, because they resembled values that people recognize.

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.

Hmm not sure about that. If MSX software sends out a command to change an MSX1 palette, or to change PSG waveforms (meisei), then the MSX software doesn't really do something that could hurt itself. The emulator however could be buggy for some reason, but that can be fixed. The bonus features of an emulator are often not an MSX emulation but something else. An MSX1 palette is just changing 48 bytes somewhere in the emulator data itself, emulation accuracy wouldn't be degraded because of that. For the moment I don't quite see the sort of bugs that could emerge from that.

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