| |
Dano
Registered: Jul 2004
Posts: 231 |
WinVice 3.1 speed/performance on Ultrabooks?
Currently i am coding on an Asus UX32VD Ultrabook (which should have some like an Intel Core i7-3517U 1.9 GHz in it). As of WinVice3.1 using x64 with FastSid does not work correctly anymore. Visuals yes, but Sound sometimes totally goes south (no filters and such).
From the Vice people i was told to use ReSid as FastSid is not supported anymore.
Now my problems start: With using ReSid WinVice drops to like 24fps on my system. Using x64sc with Resid gives me like 8fps.
Looking at procmon it seems like one core is maxed out as CPU load never goes over 24% (the graphs show a different picture as none seems to be properly used).
My workhorse laptop at the office can run x64+resid nicely and properly, but okay it got way more power than my ultrabook will have.
Somehow i got the feeling that my system (Win10 Creators) is not really working properly anymore.
That's why i am asking here.. Any of you guys got a laptop compareable to mine and how's WinVice working on your system? Or what are the general performance reports for WinVice3.1?
Before i go into the ordeal of doing a complete re-install i would like to hear what other experience with WinVice currently. If it's problem on my side, or if it's just how well WinVice works on lower spec (sort of) laptops.. |
|
... 51 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:Turn off sound for real or tune back resampling to "fast". Then likely you'll get much better performance for testing stuff in warp.
...and it also _does_ effect acuracy of the emulation. no not just in terms of output - actual test programs will then fail. and thats why the default was changed.
dano: of course when more things happen, more CPU is used. thats why comparing warp speeds in the basic startup screen is a silly exercise :) |
| |
Raf
Registered: Nov 2003
Posts: 343 |
Quote: In my C64 Debugger which I plan to release soon I added option to switch off SID emulation completely when in warp mode. This *seems* to not destroy emulation, as the ReSID cycle is synced back to CPU just a while after returning from warp. Anyway - the warp got huge speed improvement. This is a crude hack, but it seems it is acceptable in most cases. By the way I think it's high time for me to post some patches to the Vice too :-) I'll post my outcomes within next few weeks.
Your patches will be then skipped like Polish cartridges emulation developed within www.c64power.com xD |
| |
Dano
Registered: Jul 2004
Posts: 231 |
@groepaz: does cpu action have such an impact on emulation? would have thought that VIC & SID display stuff takes about 80% of the emulation power.
when talking of warp-speeds on startup:
quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation. can't pinpoint to when things happen like this as i 99% of my dev work just do the F7 in sublime which does compile and start vice after that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:Your patches will be then skipped like Polish cartridges emulation developed within www.c64power.com
when the patches make test programs fail that work without the patch, then they will be rejected. obviously, i hope.
Quote:quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation.
didnt see that behaviour for a long time - is that with the original kernal? any cartridges active? |
| |
Dano
Registered: Jul 2004
Posts: 231 |
Quote: Quote:Your patches will be then skipped like Polish cartridges emulation developed within www.c64power.com
when the patches make test programs fail that work without the patch, then they will be rejected. obviously, i hope.
Quote:quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation.
didnt see that behaviour for a long time - is that with the original kernal? any cartridges active?
Quote:
Quote:quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation.
didnt see that behaviour for a long time - is that with the original kernal? any cartridges active?
orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
or nothing happens in some cases. just a normal blinking cursor then. |
| |
soci
Registered: Sep 2003
Posts: 479 |
Quoting danoComing back to my problem i usually notice that the Vice Display FPS slow down the more is happening on screen. Frankly speaking screen action should not have effect on Vice Perfomance?! Having stuff like flashing/debug Bordercolors makes Vice drop in FPS like hell.
Be careful with what you wish for. I'm sure there's more than one way to achieve exactly that... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
so, basically PEBCAK then :) to make that work reliable, use -keybuf to put a F7 keypress into keyboard buffer after reset (and after a suitable timeout). the autostart mechanism doesnt know about cartridges, nor anything that isnt the original kernal. |
| |
Dano
Registered: Jul 2004
Posts: 231 |
Quote: Quote:orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
so, basically PEBCAK then :) to make that work reliable, use -keybuf to put a F7 keypress into keyboard buffer after reset (and after a suitable timeout). the autostart mechanism doesnt know about cartridges, nor anything that isnt the original kernal.
Quote:orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
so, basically PEBCAK then :) to make that work reliable, use -keybuf to put a F7 keypress into keyboard buffer after reset (and after a suitable timeout). the autostart mechanism doesnt know about cartridges, nor anything that isnt the original kernal.
that pretty much NOT explains why it's working at times.
srsly, it happens, then it not happens, .... not happens, happens.. and be sure i tried various things like waiting less, waiting more. yet still if i do it 10 times the same way it can work a random number 0..10.
ofcourse it's easy to blame the user for doing <<RANDOM>> thing wrong instead of finding a solution. guess my collegues can be happy that i am not such a type of coder..
apart from the fact that i don't want to check the compile script or have "compile with f7" and "compile without f7". blabla. welcome to the world of working around quirks because the reason is not to be found or wanted to be found.. ^^ |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
the reason is that autostart uses specific timing constraints. it works sometimes and sometimes not because the timing you press F7 with is not always the same.
and if you dont want to use the solution that actually works... ok. dont blame the emulator for it though, thats just silly =P |
| |
Dano
Registered: Jul 2004
Posts: 231 |
ah yes, then it makes totally sense why the problem occurs at times with instant f7 pressing or waiting with pressing f7 for a longer time (>10 seconds that is).
and i must admit lame me doesn't know how vice detects when to switch off warp-mode after loading a file.
but honestly this too is offtopic as it was not about "non-existant" vice bugs but rather vice performance (tipps).
thanks again at soci and compyx for comprehensive informations. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
