Can you explain in detail how it works?
Hmmm.... Good question!
Ok! I am checking the VDP status register 0, the F flag, generated every 1/50 or 1/60 second an interrupt,
Checking the flag when starting, and timing with NOP ((4 t-states) defb 0, and INC DE (6 t-states), which will decrease when speed goes up.
I guess it will not work when using eZ80 nor Z380 processor, timing should be increased.
In normal cases OpenMSX is perfect!, No person will use this in normal condition. The timing between bare MSX and OpenMSX is almost nano. But measurable minuscule, and has no effect on emulation.
The code is open source, you can analyze.
I came to the idea to implement this when I encounter a difference in timing of status register 2, &h40.
Also I wanted to run it on MSX 1 and up... and I succeeded!
The speed is related to the VDP. (Best solution)
The difficulty was finding a way to find the difference, and the bit I am checking was the only factor to check the difference..
Oeps, just noticed the other post... But FYI
There is always a way to find, measure and show you are in an emulator. If it is timing, undocumented mnemonics, undocumented vdp functions, or undocumented configurations..
VDP status reg: Is this about reading the status flag at the same time one of the bits is set? Then yes, that can be problematic. I remember wolf_ mentioning a problem they had when developing Universe Unknown, a bug that didn't happen on emulators. The cause was: they were polling the VDP status register vblank flag manually.
What can happen is, when it's read around the same time the VDP sets one of the bits, the read returns 0 and the status register is reset.
My MSX does not produce this noise on its monitor. Except very slightly by increasing the sound volume to the maximum. With a good scart cable, you shouldn't hear it.
It was more noticeable on MSX1, connected with RF to a tv. For example, do color 15,1,1 and 'list' a long basic listing and you can literally hear it scroll.
To detect OpenMSX in a controlled/development enviroment one could always install a TCL Script which responds in a certain way to a certain IO port, isn't it so? This wouldn't rely on flaws of emulation that could be fixed in a future version.
Am I missing any points here?
Sometimes It is a reminder you are in an emulator and you have to run it on bare MSX. Coding on PC and running the code sometimes needs a 'You are in emulator, stupid fool'.., Oh jah, so saving code on disk and running on bare. Everyone can make this mistake.
It is always good to know you are in an emulator. Running undocumented configurations need some reminders from time to time
For example: the noize of using VDP R#26 and R#27 I do not encounter on my bare MSX, like WebMSX, but OpenMSX does. So I cannot trust any machine and routines for V9958. Some have this issue, some dont.. Which one is a base machine, you can count on?
Maybe I use unnecessary timing routines, and spending time with T-states, which the time I could also use to watch some movie or NSFW content.. hhaha
For some code it is crucial to have as much as possible time after vertical border at bottom to border at the top to do the things you want to do, if it is calculations, sprites, or other modifications.
Accumulator: can you make a binary available of your program so I can easily test it?
Note that there are many different MSX configurations in the world. We try to emulate the variants also in openMSX.
If you see something that happens to work on your particular real MSX and not in openMSX, emulating the same machine, it is a defect in openMSX. But you'd better be aware that it may also not work on real MSX machines that are not exactly the same as yours. E.g. some real MSX machines have a different clock crystal for the VDP and the CPU. This can be detected if you are aware of it. But it's not mandated in any standard (and also not emulated in openMSX), as far as I know. So if you do very tight low level stuff, your mileage may vary...
Hi Manual, as requested
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
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.
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 probably modify debugdevice on openMSX to do this.
It would be better if the community agreed on an I/O port (there are still quite a few left, if only one of the extended ports).