Page 2 of 7
Posted: Thu Jul 15, 2010 12:07 pm
by Zagon
I think I've found a bug in the VIA-emulation regarding the behavior of the second timer. This has probably not anything to do with the bugs you have fixed, but anyhow..
When timer2 counts down to zero it continues into the negative so that it is possible to determine how many cycles ago it reached zero.
However, if an internal clock overflow occurs while the timer2 is in the negative then it is not updated correctly and will contain the wrong cycle count. I think the problem is in the internal function viacore_clk_overflow_callback in viacore.c that is supposed to fix the overflow condition. It seems to handle timer2 as if it behaves like timer1 which I think is wrong.
Here's a link to a test program that uses the negative count to adjust the value used to program the next timer2 value to keep it in sync with the raster. It also waits half a frame in the handler before reading and reprogramming the timer in order to trigger the bug more reliably. When run for about 2^32 cycles (use warp-speed) the stable bckground/border color change will jump visibly due to the bad overflow fixup and stabilize at a different position.
Here's a patch to viacore.c that fixes the problem for me. (I have not run any other tests with it so it might break other things)
Code: Select all
Index: src/core/viacore.c
===================================================================
--- src/core/viacore.c (revision 22723)
+++ src/core/viacore.c (arbetskopia)
@@ -843,9 +843,7 @@
((*(via_context->clk_ptr) + sub - via_context->tau)
% (via_context->tal + 2));
- via_context->tbu = via_context->tbl + 2 -
- ((*(via_context->clk_ptr) + sub - via_context->tbu)
- % (via_context->tbl + 2));
+ via_context->tbu -= sub;
if (via_context->tai) {
via_context->tai -= sub;
Posted: Thu Jul 15, 2010 12:39 pm
by nbla000
I've noticed that sometimes, if I put Vice in background for a while to use another program, when I switch to his window, it does not respond.
I should kill it from the Task Manager.
I use Windows XP sp3 professional full updated.
Posted: Thu Jul 15, 2010 12:55 pm
by tlr
Zagon wrote:I think I've found a bug in the VIA-emulation regarding the behavior of the second timer. This has probably not anything to do with the bugs you have fixed, but anyhow..
When timer2 counts down to zero it continues into the negative so that it is possible to determine how many cycles ago it reached zero.
However, if an internal clock overflow occurs while the timer2 is in the negative then it is not updated correctly and will contain the wrong cycle count. I think the problem is in the internal function viacore_clk_overflow_callback in viacore.c that is supposed to fix the overflow condition. It seems to handle timer2 as if it behaves like timer1 which I think is wrong.
Good find and excellent bug report!
Timer 1 overflow handling was rather broken earlier which was fixed in vice-2.2.
Apparently we should have checked Timer 2 as well.
We'll analyze the impact of your patch and/or fix the problem.
Posted: Thu Jul 15, 2010 12:56 pm
by tlr
nbla000 wrote:I've noticed that sometimes, if I put Vice in background for a while to use another program, when I switch to his window, it does not respond.
I should kill it from the Task Manager.
I use Windows XP sp3 professional full updated.
I run the same setup and haven't seen this. (XP sp3 pro 32-bit)
It could be related to vice.ini settings. Video card/Audio card perhaps?
I'll keep an eye open for it.
Posted: Fri Jul 16, 2010 3:53 am
by nbla000
tlr wrote:I run the same setup and haven't seen this. (XP sp3 pro 32-bit)
Same for me, just Italian
BTW it seems something related with the drives in true drive emulation, maybe the 1581, during the reset phase.
I've noticed that with Vic full expanded, true drive emulution, if I use the 1541 on drive 8 and the 1581 on drive 9 , load something on drive 9 then reset, the reset is very loooong and the vice freeze with the drive 8 led fixed, the task manager reports that xvic.exe does not respond but if you wait for 15/20 seconds, it will restart.
The problem is that this issues doesn't happen on all my tests, it should be something that produce a problem in this phase.
So this is the issues found, it doesn't metter with another program window as I said before.
I've noticed also that I always got this error by changing the drive model (any address #8-#11) in Drive Settings from 1541 or 1541-II or 1570 or 1571 -> to 1581
I've tested the same operation with the version 2.2 stable, same vice.ini and the problems does not occur.
It could be related to vice.ini settings. Video card/Audio card perhaps?
I use the same Vice.ini and Video/Audio card of the latest stable 2.2 version and I never noticed this problem with previous versions.
Posted: Sat Jul 17, 2010 2:44 pm
by Zagon
Thanks for looking into the timer2 bug!
Another thing, this is not a bug but more of a feature request regarding the "keep aspect ratio" option.
This option is great but it only makes it possible to set the correct aspect ratio for one video mode, not all. I would like it if each video mode had a separate aspect ratio setting so that switching video mode also switched to the aspect ratio of that mode. (This goes for the other vice-emus too). Fixing this would make it easier to set up vice for gamebase where games are flagged as PAL or NTSC and can be launched as such.
Finally, a very minor detail, the value in the "keep aspect ratio" field in xvic is not consistent with the x64 and x128 emulators. In those emulators the value is the pixel aspect ratio, in xvic its the pixel aspect ratio divided by two.
Posted: Sun Jul 18, 2010 6:56 am
by rhurst
each video mode had a separate aspect ratio setting
Isn't that already available with the command-line option, -aspect
I use VICE compiled with the SDL configuration mainly, because it runs so well on Linux and GP2X Wiz. These options are available to customize a game from a launcher:
Code: Select all
-sdlbitdepth <bpp>
Set bitdepth (0 = current, 8, 15, 16, 24, 32)
-sdllimitmode <mode>
Set resolution limiting mode (0 = off, 1 = max, 2 = fixed)
-sdlcustomw <width>
Set custom resolution width
-sdlcustomh <height>
Set custom resolution height
-sdlaspectmode <mode>
Set aspect ratio mode (0 = any, 1 = fixed)
-aspect <aspect ratio>
Set aspect ratio (0.5 - 2.0)
And there is an option (-config <filename>) to point to another config file, too, so you can have one setup ideally for NTSC and the other for PAL.
Posted: Sun Jul 18, 2010 9:54 am
by Zagon
As far as I know the -aspect option is only available for the SDL-ui. The -config option combined with multiple config files is an option but is not as easy to manage as a single config file. As aspect ratio really is a property of the video mode I think that they should be associated.
However, I have been working on my own feature request.
Here's a patch for Vice (svn-current as of yesterday) that implements mode specific aspect ratios for all emulators in vice in the most unobtrusive way I could think of.
The patch changes no UI-elements and should work for all target platforms and UIs that allows aspect ratio changes today.
The UI aspect ratio setting reflects the aspect ratio associated with the current mode. Modes that don't yet have a specific aspect ratio will default to the current aspect ratio. this makes migration transparent.
To change the aspect ratio for a specific video mode do like this:
1) start the emulator
2) change to the video mode you want to change aspect ratio for
3) change aspect ratio by the UI-controls
4) change back to the video mode you want as the default
5) save the settings
6) done
The patch works like this: The active video mode uses the aspect ratio that are editable by the UI like before. All other video video modes have one associated aspect ratio each that are also stored in the vice.ini file. When the video mode is changed, the editable aspect ratio is copied to the aspect ratio of the mode we switch from and then the aspect ratio of the mode we switch to is copied to the editable aspect ratio.
(edit: I've updated the patch, the first version didn't compile)
Posted: Sun Jul 18, 2010 10:43 am
by tlr
New build:
xvic-r22731-win32.zip
xvic changes:
- Excessive drive cpu load during reset fixed.
- Drive rotation improvements.
- Weak bit emulations on 64-bit systems fixed.
- VIA wrap handling rewritten. Hopefully fixes timer 2 problems. Please test.
Posted: Sun Jul 18, 2010 11:54 am
by Zagon
tlr wrote:New build:
xvic-r22731-win32.zip
xvic changes:
- Excessive drive cpu load during reset fixed.
- Drive rotation improvements.
- Weak bit emulations on 64-bit systems fixed.
- VIA wrap handling rewritten. Hopefully fixes timer 2 problems. Please test.
The timer2 problem seems to be solved. I can't trigger it anymore. Thank you for fixing this!
Posted: Mon Jul 19, 2010 10:33 am
by nbla000
Fixed also the drive change / reset issues, thank you.
Posted: Thu Jul 22, 2010 3:21 pm
by tlr
Boray wrote:Is there a Windows build of the whole VICE (and not just xvic) somewhere so that I can try it with PRG Starter?
Here:
http://www.trikaliotis.net/Download/vic ... .6-x86.zip
Posted: Thu Jul 22, 2010 5:32 pm
by Boray
Thanks! Use of the -basicload option is now implemented in PRGStarter, but I will wait with the release until VICE is released.
Posted: Fri Aug 06, 2010 5:12 am
by Boray
I think I have found a problem with the c64 emulator. When autostarting files with VICE with the executables in the VICE 2.2.6 folder it came with, they are loaded ,8,1 .... So far so good, but I also copied the executables to my old VICE 2.2 folder (as I wanted to keep the settings), and when I autostart files with the c64 emulator there, they are loaded ,8 by default!
(The vic-20 emulator loads ,8,1 as it should)
Here is the settings file:
Download link:
http://user.tninet.se/~jad615g/vice.ini
Anders
Posted: Fri Aug 06, 2010 8:03 am
by nbla000
nbla000 wrote:I've noticed that sometimes, if I put Vice in background for a while to use another program, when I switch to his window, it does not respond.
I should kill it from the Task Manager.
I use Windows XP sp3 professional full updated.
Unfortunately I should report that this problem occasionally still remain, I think something still mess with drives.
I've noticed this problem with all 4 drives emulated in true drive emulation and "Warp mode" enabled after a while (4/5 minutes) that I use another program but not always
edit: just occurred now after sent this post, after a while I click to the vice icon on the program bar (20/30 seconds) the vice screen comes up with 0% speed 0 fps (warp)
This is the screenshot during TGA testing
