Detecting OpenMSX or RealMSX?

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

Por Manuel

Ascended (19326)

imagem de Manuel

28-01-2023, 23:08

Accumulator wrote:

Hi Manual, as requested

speedf.bin

If it is correct, the t-states of every Z80 should be the same, furthermore timing is also done by VDP. VDP timing should be the same as well..

The check whether it is bare MSX or emulator, or not, is done by comparing bits that differ and the first difference I noticed was the bit I checked, but if I look at is much closer and longer, I can find other method of checking

Code can be optimized.

Build at &HC000, xcution at same address ..

CPU = &HC092 -> Result R Only
EMULAT = &HC08E -> Result R only
TURBO = &HC08F -> Variable 0,1,2 R800, 0= Z80, 1&2 = R800, W only
RESULT = &HC090 + 1 -> real result, CPU and EMULAT are based on this result, R only
VDP = &HC07A -> routine to toggle 50/60 hz, X only

I'm sorry, but can you tell me how I can use it to test whether it thinks it's running on openMSX or not? It's not clear to me from this description. Should I do BLOAD"SPEEDF.BIN",R:?PEEK(&HC08E) to know whether it thinks it's on emulator? And 1 is then emulator and 0 is real?

Por Manuel

Ascended (19326)

imagem de Manuel

28-01-2023, 23:08

pizzapower wrote:
aoineko wrote:

Couldn't we just define a I/O port that would let us know if we are "connected" to an emulator or not? A port that could also be used to exchange data between MSX and the emulator in a cleaner way than the hacks used by some emulators and based on unused Z80 instructions.

You can probably modify debugdevice on openMSX to do this.

You can also fully implement such a thing in a script with an I/O watchpoint.

Por aoineko

Paladin (901)

imagem de aoineko

29-01-2023, 02:18

I was talking about making it a "standard" so that all users can use the same I/O and that emulators (those still active.... i.e. openMSX, Emulicious, WebMSX and fMSX) could also support it in the same way.

Again, I don't have any particular need on my side. I just think it's a pity that we don't harmonize such a "universal" need in development as being able to communicate with an emulator and/or a debugger.

Por Accumulator

Master (189)

imagem de Accumulator

29-01-2023, 06:22

Isn't is a better idea, this is a proposal, to use an address (system is &HF3F0 and above, if I can recall correctly)
Above the system bars, one address, which is not used, and always 0 or 255, and write 1 to that address. If someone peeks this address, they are remembered they are running an emulator

Por Accumulator

Master (189)

imagem de Accumulator

29-01-2023, 06:32

Hi Manuel, the manual is as follows:

10 bload "speedf.bin",r
20 ? PEEK(&Hc092): REM CPU * 3.57
30 ? PEEK (&Hc08E): REM RUNNING IN EMULATOR =1 else 0
40 END
41 REM Testing some variables when executing
50 POKE (&HC08F),x: REM x =0, Z80, x=1 R800 ROM , x=2 R800 DRAM
60 DEFUSR=&HC000:A=USR(0)
70 END
80 REM Toggle 50/60Hz
90 DEFUSR=&HC07A: A=USR(0)
100 END
110 ? PEEK(&HC090) : REM Orig result L (from HL)
120 ? PEEK(&HC091) : REM Orig result H (from HL)
130 END

Depending on the execution or variables, goto line X

CPU = &HC092 -> Result R Only
EMULAT = &HC08E -> Result R only
TURBO = &HC08F -> Variable 0,1,2 R800, 0= Z80, 1&2 = R800, W only
RESULT = &HC090 + 1 -> real result, CPU and EMULAT are based on this result, R only
VDP = &HC07A -> routine to toggle 50/60 hz, X only

Por wouter_

Champion (509)

imagem de wouter_

29-01-2023, 10:19

aoineko wrote:

I was talking about making it a "standard" so that all users can use the same I/O and that emulators (those still active.... i.e. openMSX, Emulicious, WebMSX and fMSX) could also support it in the same way.

The goal of openMSX is to behave as much as possible as a real MSX machine (it's difficult to 100% achieve this, but nevertheless that's the goal). In other words: for a MSX program it should be impossible to distinguish whether it's running on a real machine or in openMSX. So from this point of view openMSX will never "voluntary" announce to the MSX program that it's not running on real hardware.

Note that I said "voluntary" in the previous paragraph. I totally support an "opt-in" mechanism that the user can activate. And openMSX already has several of these. Several example were already mentioned in this thread, and they can all be implemented via a small Tcl script. I'm fine with standardizing such an (opt-in) mechanism.

On the other hand. Such an (opt-in) mechanism will only be useful as a development tool (it won't work in a released product). And is it then really needed to come up with a standard mechanism? Won't it be better if each developer can choose what fits best in his current project?

Por Manuel

Ascended (19326)

imagem de Manuel

29-01-2023, 16:17

On a turboR, the program gives me a 'blue screen'.... I cannot peek the results...

Por aoineko

Paladin (901)

imagem de aoineko

30-01-2023, 00:20

wouter_ wrote:
aoineko wrote:

I was talking about making it a "standard" so that all users can use the same I/O and that emulators (those still active.... i.e. openMSX, Emulicious, WebMSX and fMSX) could also support it in the same way.

The goal of openMSX is to behave as much as possible as a real MSX machine (it's difficult to 100% achieve this, but nevertheless that's the goal). In other words: for a MSX program it should be impossible to distinguish whether it's running on a real machine or in openMSX. So from this point of view openMSX will never "voluntary" announce to the MSX program that it's not running on real hardware.

Note that I said "voluntary" in the previous paragraph. I totally support an "opt-in" mechanism that the user can activate. And openMSX already has several of these. Several example were already mentioned in this thread, and they can all be implemented via a small Tcl script. I'm fine with standardizing such an (opt-in) mechanism.

On the other hand. Such an (opt-in) mechanism will only be useful as a development tool (it won't work in a released product). And is it then really needed to come up with a standard mechanism? Won't it be better if each developer can choose what fits best in his current project?

openMSX offers machines that do not exist. It's the same thing for what I propose. It would be a virtual extension (which could very well exist as a cartridge) to connect an MSX to a debugging interface. We could take one of the free ports and describe a protocol to exchange between the MSX and this interface. This way we could standardize and clean up the communication functionalities from an MSX to the debugging interface: Sending logs, sending profiling information (start/end of section), triggering breakpoints, etc.
The protocol could allow to know the identifier of the debugging interface connected to the MSX (the emulator in the case of a virtual extension).

This is the kind of functionality that has existed (physically) for a long time on game console development kits for example.

Por Manuel

Ascended (19326)

imagem de Manuel

30-01-2023, 22:08

OK, I got it to run on my real GT and it also says it's an emulator there Smile

Por ducasp

Paladin (677)

imagem de ducasp

31-01-2023, 12:57

If a standard to detect across the board is needed, I would recommend this:

https://www.msx.org/wiki/Switchable_I/O_ports

Create an ID for OpenMSX and make it disabled by default for sake of originality, have an option to enable it for whoever wants it to be detected, if anyone wants to detect, can use the switched IO ID method to detect the ID. Beauty of this is that you can still keep the original switched IO of machines that already have it, it takes over only when selected.

Any other emulators could follow suit with their own IDs. It is standard, not reinventing the wheel, and will not disrupt with original machines emulation even if enabled B-)

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