But perhaps the problem lies in operating systems that are not meant for this purpose and steal huge resources.
What do you think?
It's exactly that, given that they're not real-time operating systems.
The problem with emulators is not the speed of current CPUs but that they were developed on machines that have evolved. Relevant methods before are not relevant now. For example, OpenMSX is based on fMSX and it still has remnants of its predecessor (eg. slot management). Emulators also use libraries, some of which change a lot over time and sometimes become obsolete. It sometimes requires big changes or even the complete reprogramming of whole sections in the program. They scripts which are slower but more and more used because simpler. This greatly spoils the performance of the machines.
Responding to gdx:
Sorry, but openMSX is *not* based on fMSX. At all.
What remnants (that aren't actually there) of slot management do you see, I wonder?
The scripts in openMSX do not influence the emulation performance. The performance critical parts are all written in highly optimized C++.
Mine is just a note on the fact that I would expect a very close to perfect emulation without having to resort to the FPGA. If a modern processor is 100/1000/10000 times faster than the machines of the 80s, there is enough computational capacity to overcome any problem. I am referring to pure performance, not so much to the fact that something is not emulated because the details are not yet known.
Can you elaborate on that performance? At least in openMSX, which I know best, the host CPU cycles are not the problem at all. The Z80 is 100% accurate as far as we know. The remaining inaccuraies really does lie in unknown behaviours of complex chips like the VDP. So not at all related to the host CPU power.
Graphical glitches, sound issues. dithering and so on should be completely overcome.
As I said, they are not at all limited by the host CPU. Faster CPU doesn't help.
But perhaps the problem lies in operating systems that are not meant for this purpose and steal huge resources.
There may be some lag/delay due to the host OS, so input delay and perhaps also some delay or hiccups in sound (more delay means less hiccups). This has to do with a multitasking OS and tight buffers. But in practice, even on my old 2008 PC, I don't notice this and all runs just fine. (On Linux at least, which is what I use.)
Sorry, but openMSX is *not* based on fMSX.
I read several times that all MSX emulators were more or less based on fMSX.
What remnants (that aren't actually there) of slot management do you see, I wonder?
We had talked about it before. Slots management is not flexible enough to adapt to all configurations. For example, when you start an MSX there are always two slots offered even if the emulated MSX has 1 or 3 slots. The interface does not adapt. Moreover, it is not possible to insert any type of cartridge in any slot.
PS: BlueMSX and msxDS are dead due libraries that have become obsolete and evolving development tools.
Sorry, but openMSX is *not* based on fMSX.
I read several times that all MSX emulators were more or less based on fMSX.
Sorry, gdx, but your answer is pure "trolling".
Manuel is sufficiently implicated in OpenMSX to know what he's talking about.
So what's the use of questionning *again* his answer ? If not to flame the whole thing ?
Sorry, but openMSX is *not* based on fMSX.
I read several times that all MSX emulators were more or less based on fMSX.
Not true for openMSX. But fMSX was the reason that openMSX got started, as Marat wouldn't accept patches from turbor and/or mth. But as openMSX has been fully licensed under GPL2 from the start, it's impossible to be based on fMSX, which has an incompatible license.
What remnants (that aren't actually there) of slot management do you see, I wonder?
We had talked about it before. Slots management is not flexible enough to adapt to all configurations. For example, when you start an MSX there are always two slots offered even if the emulated MSX has 1 or 3 slots. The interface does not adapt.
That's not an issue in openMSX, but an issue in openMSX Catapult. Please use the OSD menu and you see exactly which slots are available. The interface fully adapts, also when you add a slotexpander for instance.
Moreover, it is not possible to insert any type of cartridge in any slot.
It is possible with openMSX and the OSD menu will help you there. But maybe you should give an example, as I don't know exactly what you mean.
PS: BlueMSX and msxDS are dead due libraries that have become obsolete and evolving development tools.
Software requires maintenance to keep up with the world's developments.
That's not an issue in openMSX, but an issue in openMSX Catapult.
No, because we can insert a cartridge classified as extension in an slot expander.
Software requires maintenance to keep up with the world's developments.
That's exactly what I meant. There are also structures to modify to improve emulation. It takes time to adapt the emulation according to the evolutions.
That's not an issue in openMSX, but an issue in openMSX Catapult.
No, because we can insert a cartridge classified as extension in an slot expander.
I don't understand the problem you're trying to tell me about. Please explain.
A slot expander gives 4 extra slots. You can insert any kind of extension or ROM cartridge in the slot expander slot. (It's just a subslot.)
gdx wrote:
The problem with emulators is not the speed of current CPUs but that they were developed on machines that have evolved. Relevant methods before are not relevant now. For example, OpenMSX is based on fMSX and it still has remnants of its predecessor (eg. slot management). Emulators also use libraries, some of which change a lot over time and sometimes become obsolete. It sometimes requires big changes or even the complete reprogramming of whole sections in the program. They scripts which are slower but more and more used because simpler. This greatly spoils the performance of the machines.
It is more than that. In emulation a CPU that does operations serially has to reproduce the behavior of a large number (thousands, millions, billions...) of elements that operate in parallel and create the illusion that the results happen in the same way in the original.
There is always a trade-off between accuracy and simplifications in order to make the emulation real-time. Emulation can be good enough, but it can't be perfect.
We can imagine an absurd emulation scenario where every transistor of the original system is modeled so we can have an almost perfect emulation. We can run a circuit simulation of the entire system, solve the differential equations, circuit matrices, etc. Let's say a typical MSX may have a 8500 transistors in the CPU, maybe 20000 transistors in the VDP, and another 10000 transistors to do the rest, except memory. 64K of sram may be another 300000 transistors. Then the ROMs... let's say 600.000 thousands transistors for an MSX 1. Now we need about 1000 clocks cycles to calculate each transistor equation. Then after evaluating each transistor we need to run iterations of the circuit matrices that are sparse but may grow with the square of the number of transistors. Then we can take a time step and every clock transitions may cause a few tens of those. It is easy to see that perfect real-time simulation is not possible even on large servers.
The obvious initial simplifications is to replace the memories with matrices and emulate them at a higher abstraction level. And you keep taking those decisions in order to simplify the system enough to make it real-time. And in the end your system knowledge and compute performance limit the quality of your simulation. And if you have more performance available you can always refine.
In practice emulators work either at instruction or bus operation level emulation with some operating at clock cycle. With behaviors described at high level between those events. Results are very good, but are quantized at that level and may result in loss of finer behavior.
So performance is never enough for perfect behavior. You may emulate a Z80 close to perfection but many other things could happen in parallel and aligning those gets very tricky.
The final part of the problem is, once the system is emulated, now you have to show video/audio and capture input events with small enough delay. Setup may have a lot of influence. So low latency USB peripherals, gaming monitors, etc, may have a significant impact on user perception. And then the operating system may throw some unexpected stutter/lag/lockups.
It is a very difficult problem if the goal is perfection. FPGA avoids the need for emulation altogether. You can implement everything that needs parallelization as independent components. And if you have a detailed enough understanding of the system you want to reproduce, you can represent it gate-by-gate as in the original system. So it may solve the performance and latency issues of emulation, but you are still left to figure out how the original system is implemented. You may need to reverse engineer the chips to really reproduce some finer behavior. Z80 is already well known to transistor level, emulation is also close to perfection. VDPs and audio components are not and more subtle behavior may be missed.