I think it would be best to keep an emulator undetectable. There are fine ways to debug without the MSX program having to know it is running on an emulator, right?
I think it would be best to keep an emulator undetectable. There are fine ways to debug without the MSX program having to know it is running on an emulator, right?
I agree with you in general lines, I don't like the idea of a program adapting to emulation quirks, it should be reported and fixed, but, on the other hand we know that the fix might take a while and sometimes even years, but still I would not release a version that detects emulator and turn that off, as this is bad in the fact when the emulator evolves, software won't know and still block that feature. I think the preferred way to do this would be to have defines in the code and generate two versions, one for systems that work fine with it and other for systems that don't, as generally speaking those kind of corner case scenarios might affect not only emulators but different versions of CPU or VDP, give user the choice to try and if it crashes and burn, user can turn it off or use an alternate version, that would be my approach to this.
Ok, Manuel,
I fully understand! The problem is I checked GT in the emulator. So if that is the reason of my other result, I have tested another routine checking VR (status register 2, and &h40) on a emulated Sony, and gave different result. I will check in same machine in emulator.
Is there a way to enable 7hmz in emulator? or V9958? with a non original 2+ and up machine.
On my bare MSX i do not encounter so much noise using R26 and R27 as OpenMSX does, WEbMSX is providing to little noise/no noise, you get my point.
It is viable to know if you are in an emulator.
I had some other issues, which are noticeable, visually, but not measurable.
I agree, to have the emulation undetectable, but if some routines give a difference, THEY SHOULD BE PUBLISHED. Not to annoy the programmer, but to improve the emulation. I prefer to have 100% emulation, but I think this is a dream. If you can crash the emulator, inform! If it is a timing issue, inform!, configuration issue, inform. But resolution of the incident should be handled as a normal MSX would handle the issue, and not just workaround to not crash, that is a bad solution.
If there is a address/io someone can read the are in an emulator, he/she knows it is not a bare machine. like reading io E6,E7 for checking Turbo R.
You can modify a machine to contain a V9958, or use the Boosted MSX2 EN (which is a 8250 with V9958). 7MHz is not really emulated, but you can tweak the CPU frequency with the settings for it.
Accumulator: check this short thread fyi.
Manuel, I have used the F flag, because this is also used on TMS9918/xx.
I will split the routine for speed and emulation, however same code is used .....
If you remove the timing , (the defb 0,0 and inc de), and asssemble it, and run and peek the variable RESULT,
on my Sony 700, I get 3/4 different values (212,213,170,x) and on emulator 1 stable(213) value (Also Sony 700).
Run it 200 times and count the specific values, is it 3 or more different values it is a real machine.
I can loop it for some times automatically, but want to know other bare results as well..
Grauw, I think your point was indeed.... sometimes misses the interrupt on real machine..
Therefore I get more values...
I cannot test on other real hardware...
Can you test this?
help from basic like:
10 defusr=&hc000:a=usr(0)
20 ?peek (&hc083) :' must check if this address is correct after assembling.
30 goto 10
Build of speedf2.asm
Build at &HC000, xcution at same address ..
NTSC= &hC082: 0/2/128/130, W only
TURBO = &HC084 -> Variable 0,1,2 R800, 0= Z80, 1&2 = R800, W only, used when xcution
RESULT = &HC085 + 1 -> real result, CPU and EMULAT are based on this result, R only
VDP = &HC06F -> routine to toggle 50/60 hz, X only
On emulator it is stable, on bare not a bit! This is a way of detecting...
Be careful when making high-precision measurement that are a mix of VDP (V99x8) and CPU (Z80) timings.
The Z80 is clocked at 3.579545MHz, the V99x8 is clocked 6x faster at 21.477270MHz. In many MSX machines both clocks are derived from the same crystal oscillator: the VDP clock is divided by 6 to obtain the Z80 clock. And then both clocks are always perfectly in sync.
But some MSX machines have separate oscillators for the VDP and for the Z80. In the ideal case this difference doesn't matter. However in the real world, crystal oscillators always deviate slightly from their nominal frequency. Different components will have a different deviation. And this deviation may vary over time (e.g. with temperature, with age, ...). Because all of this, the VDP and the Z80 clock may not have the same relative deviation.
This means that a fixed number of cycles in one clock-domain (e.g. the time between 2 VDP vblank-interrupts) measured in the other clock-domain (e.g. count the number of iterations of a Z80 loop) may not always give the same result.
And important:
* The result may vary between different instances of the same model MSX machine (different crystal oscillator components).
* Long term: the results may vary when the MSX machine ages.
* Short term: there can be difference from day to day (e.g. different temperature depending on how long the machine has been powered on).
On the other hand, on MSX machines with a single shared oscillator the result may be much more repeatable.
OpenMSX only emulates ideal oscillators without deviations. Hence the more stable results.
So if you want to make sure your detection routine works on all real MSX machine, then make sure to test on a very wide range of machines. And preferably also on different instances of the same MSX model.
Thanks Wouter_,
No but the number of different result is a way to check real MSX or not. The values may vary, but the number of values, compared to emulated will show always in my opinion
I do like to add to wouters comment that the perfected emulation of thw component timings has many times led to untracable bugs. While these bugs are caused by my own bad programming practices it caused them not to show up in emulation no matter how hard I tried. Now i understand why.
From a coders point of view it would make perfect sense if the emulator would emulate the slight timing differences to some degree. Perhaps as a option?
Hi Daemos,
I like your suggestion. But I'd quickly want to sketch why it's not easy to implement in the current openMSX design.
Internally all timing in openMSX are measured in (64-bit) ticks of a clock running at 960 x 3579545Hz (=3.436GHz). So for example every VDP clock tick (@21.477MHz) a hypothetical variable that tracks VDP time would increase by a step of 160. But this also means that the next closest representable clocks must increase by steps of either 159 or 161, this corresponds to respectively 21.612MHz and 21.344MHz. But that's a way too big deviation from the nominal VDP frequency.
We could increase the time-resolution by increasing the speed of the internal master-clock. Though that has some performance implications(*1). In certain performance critical parts of openMSX we execute time-calculations with only 32-bit (instead of 64-bit). This is fine in situations where we can guarantee that the duration will be less than one second. But when we increase the master-clock resolution this optimization may no longer be valid. And depending on by how much we increase the resolution we might also need to increase our current 64-bit calculations to something wider.
(*1) This performance tradeoff was made +20 years ago. Nowadays it's probably less important. Nevertheless changing it now is still a non-trivial amount of work.