You could always implement a switch to revert back?
(Not sure if IO will be automagically fixed for openMSX when you fix this?)
EDIT: per the hint above, and following that link, it appears to assume that the point of interference is within the modulated television signal. If so then it's presumably not applicable to any MSX that doesn't use a modulated television signal — SCART and S-Video users need not apply. And, no, there's no software way to detect that.
You can on the turboR, just turn on the microphone and listen for your frequency.
Sure, straight after turning the volume up high enough for the microphone to be able to detect the noise, just like 0% of machines are probably currently configured. And even then trying to deal with false positives given the processing budget.
A much easier way to detect an emulator if you intend to do audio processing would likely be to look for better filtering. Or, in the case of many users, no audio input at all.
IMO one should avoid making workaround for emulators.
Usually the emulator writers wants to fix any inaccuracies and the workaround will just become junk code.
There are also multiple emulators out there with many different issues, making workarounds for all of them could be problematic.
Just make it compatible with real hardware and let the emulator writers do their thing.
IO-demo source is available since years. Check Pouet links.
Test relies on bit t5s testing: it occurs 1 scanline earlier on real vdp1.
What happens if we fix that?
Just have a look by yourself.
Did you read the nfo?
Copy "IO.COM" on your floppy or partition, MSX-DOS1 or MSX-DOS2.
Type "IO y" for silent mode (...)
Type "IO", do not type "IO y"
To question
sync by 5S looks bad
BlueMSX not supported
Patch for openMSX?(Y/N)
anwser N and demo will run without any patch for emu.
Again: source code IS available.
---
IMO one should avoid making workaround for emulators.
Well...
I did code IO demo in 5 months without prior knowledge on MSX+VDP.
When I first posted some high-end question, I felt people laughed at me, possibly thinking:
"Look at that guy? coming from nowhere and asking about precise T-cycle timing differences. Foooool!"
So I decided to make the impossible, alone:
coding the possibly most high-end tech demo on VDP1,
self-patching code for MSX1 MSX2 Turbo-R... and emu.
Working with you guys before the demo is out? no way!
to hack around different VDP is not the same topic as hack around emulator
Overflow: I'm sorry you had such negative experiences. I think IO is one of the most impressive MSX1 demos around... it's really impressive for 5 months without experience with this VDP.
When I first posted some high-end question, I felt people laughed at me, possibly thinking:
"Look at that guy? coming from nowhere and asking about precise T-cycle timing differences. Foooool!"
It's really sad to read that this happened. I hope it was just some misunderstanding, or some language/cultural barrier.
But I can remember that question of yours, since it was very intriguing. Luckily, I could quickly find that thread, and it seems that people didn't even know a sure answer for your question yet, so it resulted in a lot of brainstorming.
Please keep in mind that the MSX is a standard, and not a single machine with little variance like i.e. the C64. The MSX ecosystem is vast and there are a plethora of different machines that have their own peculiarities. Not everything could be investigated in full detail yet, and we keep discovering more and more details all the time. Some aspect are still controversial, with some people affirming that it behaves in a certain way, and other that it behaves on another certain way.
A full "technical archeology" would take ages even for full time/well funded researchers, and we're just a bunch of middle-aged men with a lot of other RealLife obligations to do. One time or another, someone finds some time to scratch some very specific quirk, then documents it. Then the emulator developers have to find some time to implement that.
One such example was the way the Turbo-R changes between CPUs. There was a lot of misconceptions util NYYRIKKI took the time to investigate and document it in detail.
Even at this slow pace, a lot of things have been implemented this way since your question was asked 5 years ago. Others have been discovered, but not yet implemented.
But I will not wear the pink glasses: yes, we do have some trolls here. And even some nasty puppeteers. And yes, they're a pain in the arse and can break the motivation of even the most inspired creators. But what forums don't have absolute any of those? :)
OTOH, I also have seen one specific very common misunderstanding happen between programmers that come from other platforms and the experienced MSX programmers: It's when MSX programmers try to explain some well known caveats/gotchas of the platform, but it ends up being interpreted as biased/purist. After the newcomer falls in the caveat/gotcha problems, people will tell him "see, we told you that this would happen", and this is interpreted as rude.
Well, I think all of this proves that we're all only human, doesn't it? ;)
Yes!!! It is possible. By coincidence I found a(nother) way to detect OpenMSX (Not the one which will crash OpenMSX, which I reported, so this one will be not working in the future). When running some timings there is a difference of 4. (4 is the magic number, it will show up over and over again.)
The technical manuals are not complete I have noticed.
For example: If you read carefully the manual of V9938, some info is missing. (Konamiman can read between the lines as well)
One of the features of V9938 is VRAM Select, this is mentioned sporadically in documentations. (But mentioned in data sheets)
Selectable configurations are:
- 16K x 1b DRAM
- 16K x 4b DRAM
- 64K x 1b DRAM
- 64K x 4b DRAM
When I have overcome the challenge to have the same results running routine with VDP 10 (R#9) and configurations of Bit 7 and 1 I will publish the routine. This is not an error issue, but timing..
Normally you would not encounter this or would effect any normal condition running a MSX.
Routine finished and working
Tested on Sony HB-F700D with 7Mhz and OpenMSX (17.0)
Tested on 50 and 60Hz (VDP R#9 (VDP(10))
Should work on MSX1 and up!
Value of CPU * 3.57 Mhz is speed
EMULAT=1 is OpenMSX
PS: Of course maybe temporary, depending on timing upgrade of OpenMSX
There are some things you can do on a real machine that not one current msx emulator emulates correctly...
https://www.youtube.com/watch?v=rGA_fVegAb4
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.