You may want to check which renderer is being used (in the video options). On my laptop (i5), cpu usage lowers from 30% to around 15% when I select sdlgl instead of sdl.
This Mac build does not have the option for SDLgl or SDL.
Did you see my post? You can check these settings in the OSD menu or using the console (e.g. set renderer)
I am not sure who this reply was for: the OSD I have, does not offer the choice for renderer. I have to use the console for that. Using the console with set renderer SDLgl-pp gives a blink (screen refresh) and the energy usage drops another 2% so running at 2x its still 11% energy usage.
and link because picture not visible
my OSD
This is a hard one: the energy usage of openMSX is really high. It burns laptop batteries dry in an hour, which is no fun if you're like me, using MSX while sitting in a lazy chair enjoying the fact that MSX can do games without the need for a mouse.
It easily peaks at 30% (of an i9 at 2.4 ghz) while just waiting for user input in a OpenMSX boosted TurboR with IDE. This scales nicely with the machine, because my previous MBP had an i7 and that also burned at 30%.
I understand this is not a bug, nor that its really high on a priority list ( I guess), but perhaps you could put some breaks in the code that burns the energy. I understand I have no clue about the architecture of openMSX so it might even not be possible. I only have some tips from my job. In VB.Net I sometimes write code that loops in some kind of wait-state (because not everything is an event) and the code become a CPU-hog, burning energy. Some sleeps x ms/doevents, etc at that point performs miracles. Perhaps, this is a possibility?
Thanks
Your topic starts on a wrong assumption... There is no such thing as an idle MSX, those computers are from an era that power savings and idle states were not something considered.
As such, no matter if you are sitting at the dos prompt or basic prompt or if running a loop of calculations, there are lots of processes running and vdp still is calculating lines and pixels and doing interruptions, z80 is crunching data all the time, and so on.
So, OPENMSX is cpu intensive for a reason, it will calculate states and transitions as much as possible, thus resulting in high cpu usage, as all processes are host cpu dependent.
The only way I see to lower your cpu usage is to use a simpler emulator that doesn't strive for perfection as much, like fmsx build in libreto, it doesn't try to be as perfect, thus, doesn't check so much things at pixel or line level, and cpu resources used are less. Probably emulating a lower specced MSX on OpenMSX will help as well, do you need a Turbo-R wit v9990 and moonsound to play knightmare? But just the fact you are using a machine with those include two cpu intensive emulations, wasting battery.
Let's say OpenMSX would try to determine when those chips are idle and when they are not, this would cause a problem of latency and introduce bugs, which might be fixed and worked around, but again, that would work again the strive for perfection motto...
Obviously I'm not part of OpenMSX team, but that is my 2 cents and understanding. 
This is a hard one: the energy usage of openMSX is really high. It burns laptop batteries dry in an hour, which is no fun if you're like me, using MSX while sitting in a lazy chair enjoying the fact that MSX can do games without the need for a mouse.
It easily peaks at 30% (of an i9 at 2.4 ghz) while just waiting for user input in a OpenMSX boosted TurboR with IDE. This scales nicely with the machine, because my previous MBP had an i7 and that also burned at 30%.
I understand this is not a bug, nor that its really high on a priority list ( I guess), but perhaps you could put some breaks in the code that burns the energy. I understand I have no clue about the architecture of openMSX so it might even not be possible. I only have some tips from my job. In VB.Net I sometimes write code that loops in some kind of wait-state (because not everything is an event) and the code become a CPU-hog, burning energy. Some sleeps x ms/doevents, etc at that point performs miracles. Perhaps, this is a possibility?
Thanks
Your topic starts on a wrong assumption... There is no such thing as an idle MSX, those computers are from an era that power savings and idle states were not something considered.
As such, no matter if you are sitting at the dos prompt or basic prompt or if running a loop of calculations, there are lots of processes running and vdp still is calculating lines and pixels and doing interruptions, z80 is crunching data all the time, and so on.
So, OPENMSX is cpu intensive for a reason, it will calculate states and transitions as much as possible, thus resulting in high cpu usage, as all processes are host cpu dependent.
The only way I see to lower your cpu usage is to use a simpler emulator that doesn't strive for perfection as much, like fmsx build in libreto, it doesn't try to be as perfect, thus, doesn't check so much things at pixel or line level, and cpu resources used are less. Probably emulating a lower specced MSX on OpenMSX will help as well, do you need a Turbo-R wit v9990 and moonsound to play knightmare? But just the fact you are using a machine with those include two cpu intensive emulations, wasting battery.
Let's say OpenMSX would try to determine when those chips are idle and when they are not, this would cause a problem of latency and introduce bugs, which might be fixed and worked around, but again, that would work again the strive for perfection motto...
Obviously I'm not part of OpenMSX team, but that is my 2 cents and understanding.
Funny how people always know what people assume, regardless of whether that's true. Second, I never assumed that idle means doing nothing: even current machines, where low energy is relevant, crunch numbers all the time. It was about: some routines (seem to) use a lot of energy and perhaps, some smart redesign can reduce the energy usage, just a suggestion for an improvement. As it turned out: cpu usage was not related to the energy because Mac OS prefers the dGPU over the intel integrated card.
And yes, this beast of a machine is overpowered for continuously running the turbo pascal compiler (not knightmare!), but it compiles fast.
And yes, this beast of a machine is overpowered for continuously running...
That's good. The faster your computer works, the faster you can turn it off. This also saves energy.
And yes, this beast of a machine is overpowered for continuously running...
That's good. The faster your computer works, the faster you can turn it off. This also saves energy.
It's day and the sun is bright, I am currently selling power, not buying 
This is a hard one: the energy usage of openMSX is really high. It burns laptop batteries dry in an hour, which is no fun if you're like me, using MSX while sitting in a lazy chair enjoying the fact that MSX can do games without the need for a mouse.
It easily peaks at 30% (of an i9 at 2.4 ghz) while just waiting for user input in a OpenMSX boosted TurboR with IDE. This scales nicely with the machine, because my previous MBP had an i7 and that also burned at 30%.
I understand this is not a bug, nor that its really high on a priority list ( I guess), but perhaps you could put some breaks in the code that burns the energy. I understand I have no clue about the architecture of openMSX so it might even not be possible. I only have some tips from my job. In VB.Net I sometimes write code that loops in some kind of wait-state (because not everything is an event) and the code become a CPU-hog, burning energy. Some sleeps x ms/doevents, etc at that point performs miracles. Perhaps, this is a possibility?
Thanks
Your topic starts on a wrong assumption... There is no such thing as an idle MSX, those computers are from an era that power savings and idle states were not something considered.
As such, no matter if you are sitting at the dos prompt or basic prompt or if running a loop of calculations, there are lots of processes running and vdp still is calculating lines and pixels and doing interruptions, z80 is crunching data all the time, and so on.
So, OPENMSX is cpu intensive for a reason, it will calculate states and transitions as much as possible, thus resulting in high cpu usage, as all processes are host cpu dependent.
The only way I see to lower your cpu usage is to use a simpler emulator that doesn't strive for perfection as much, like fmsx build in libreto, it doesn't try to be as perfect, thus, doesn't check so much things at pixel or line level, and cpu resources used are less. Probably emulating a lower specced MSX on OpenMSX will help as well, do you need a Turbo-R wit v9990 and moonsound to play knightmare? But just the fact you are using a machine with those include two cpu intensive emulations, wasting battery.
Let's say OpenMSX would try to determine when those chips are idle and when they are not, this would cause a problem of latency and introduce bugs, which might be fixed and worked around, but again, that would work again the strive for perfection motto...
Obviously I'm not part of OpenMSX team, but that is my 2 cents and understanding.
Funny how people always know what people assume, regardless of whether that's true. Second, I never assumed that idle means doing nothing: even current machines, where low energy is relevant, crunch numbers all the time. It was about: some routines (seem to) use a lot of energy and perhaps, some smart redesign can reduce the energy usage, just a suggestion for an improvement. As it turned out: cpu usage was not related to the energy because Mac OS prefers the dGPU over the intel integrated card.
And yes, this beast of a machine is overpowered for continuously running the turbo pascal compiler (not knightmare!), but it compiles fast.
You can use a regular Turbo-R or just create a new one based on it without OPL4 and v9990, this alone could help a lot. 
BTW, sorry if you took wrong assumption so badly, I do wrong assumptions all the time, that's life, in my opinion if you think of an emulator that strives to perfection and it starts to include workarounds to change the behavior of chips because at that moment they are not needed, this is just what emulators that don't strive to be as accurate as possible do and why they are not as accurate but probably accurate enough to run 90% of software and most won't notice any discrepancy.
I can assure you they pay much more attention to this than your average software developer.
I have no doubts about that.
It's an excellent emulator, and its team is very dedicated. I'm pretty sure that, if there's a problem, it happens due to some unexpected situation/combination and not because of lack of effort.