Virtualc64: After update to 1.11 SidWizard bahaved strange.

Created on 21 May 2018  路  15Comments  路  Source: dirkwhoffmann/virtualc64

I tried updating to the latest version; 1.11..

Previously I had been working on SidWizard and saved the tune I was working on. And so today I was going to continue after I updated VirtualC64. - Tho let me start by saying first that I know next to nothing about SID; I'm just starting up learning to even use the music maker, so I can't offer any particularly insightful observations about it; only describe in my own words what happened:

After loading the tune that I'd saved from previously, and tried to play it, it now sounded like the tune had a hickups, and was playing stray notes that weren't in the list (or maybe what it did was occasionally changing the pitch after starting to play the notes, or something). It also didn't load the instrument, by the way. - As it's a beginners learning project for me it's a very simple tune, using only one voice and the most basic triangle waveform for the instrument, with no kind of extra effects on it.

The tune had played just fine before I updated to 1.11, and after I uninstalled 1.11 and went back to 1.10 it played just fine again.

Priority-High help wanted

Most helpful comment

Here is my solution: In V2.0 beta (which can downloaded from the VirtualC64 home page), SAMPLE_FAST can be combined with the 6581 chip model. If the 8580 model is selected, a user alert comes up:

sidalert

All 15 comments

Thanks a lot for reporting!

Could you please send me or upload your sound example? I guess it's a SidWizard file saved to disk(?). I'll look into it.

Yes. I attach a .d64 image containing the melody ("rororo-2.swm") and the instrument ("triangle-2.swi") that I talked about, that didn't play right..
example-d64.zip
-SidWizard

The SidWizard version I used was SidWizard 1.7 downloaded from
https://sourceforge.net/projects/sid-wizard/

I hope this is helpful. And thanks for your attention.

Thanks a lot for the test case, I am able to reproduce what you're saying. There are noticeable cracks at the beginning of every tone.

In version 1.11, I replaced the SID engine (reSID from 2004) by the one used in VICE 3.1/3.2 (reSID from 2010). If I run your example in VICE 3.1, I hear the same cracks, so I guess, it has nothing to do with the integration of the reSID library in VirtualC64. As I do not own a real C64, I cannot tell if the crack noises are a bug or a feature.

Anyway, the reSID library in version 2010 is giving me hard time. There seems to be unpredictable behavior when switching filter emulation on and off on the fly. Sometimes, it works. At other times, the sound output goes mad. At first, I expected some uninitialized variables in the reSID code, but I did not find any. Also, I had the impression that the filter issue only affects emulation of the 8580 model.

Overall, I am thinking of reverting to the old reSID implementation in the next release.

Maybe, someone with reSID experience is reading this and might be able to give us a hint on this issue.

...a lot of problems in Vice about reSID:
https://sourceforge.net/p/vice-emu/bugs/search/?q=resid

I didn't make progress on the cracking noise problem (or feature), but I (most likely) found the cause of the "unpredictable behavior" issue in VirtualC64. A little background: To enable on-the-fly switching between fastSID and reSID, the I/O registers of both chips are kept up to date all the time. The 8580 chip is a little special, because it delays all writes to the I/O registers by one cycle. To cope with this, VirtualC64 runs reSID in the background for one cycle after each I/O register write if fastSID is selected. However, in combination with the SAMPLE_FAST option (and only with this option), reSID performs some clocking speed optimizations that can in some cases delay the writes by more than one cycle, so reSID doesn't recognize all I/O register changes when fastSID was selected before.

My plan is to simply disable the SAMPLE_FAST option in VirtualC64 (offered options will be INTERPOLATE and RESAMPLE). Doing so should solve the on-the-fly switching problem and has the positive side effect that I can remove the one cycle execution stuff (which is ugly anyway). Another possibility would be to patch the reSID code and move the write_pipeline stuff to a different function. My feeling is, however, that I should keep my hands off the reSID code, because there is a lot of magic going on which I do not fully understand.

Good morning Dirk,

I've tried around 50 games long enough to try VirtualC64 version 1.11 with the new Resid you've placed (VICE reSID from 2010).
I am not a programmer but I had the commodore 64 and I have a good hearing and as far as I'm concerned those 50 games I've tried and of which I remember well the music and the sounds I can say that they are of better quality with the new reSID 2010.
This is just my opinion worthless but I would be more pleased if VirtualC64, which I am very fond of, maintain in future versions the settings that are in version 1.11 or even improvements but not return to the 2004 version.
A greeting.

Thanks, Ottavius, for thoroughly testing the reSID quality. During the last couple of weeks I also got the impression that the noise cracking issue with SidWizard is more likely a feature than a bug. Additionally, since I disabled the SAMPLE_FAST method (on the V2.0 branch), I had no more problems switching the SID chip model or the SID engine on the fly. I'll keep the reSID 2010 files then.

I'll keep the issue open for a while. Maybe somebody with a real C64 comes along who is able to confirm the crack noises in SidWizard as a feature.

I have read of a version 2.0

(on the V2.0 branch)

_Could we know when a 2.0 version could be probably released ?_

For version 2.0, I intend to implement the following:

  1. Port remaining Objective-C code to Swift (done)
  2. Complete the debugger by adding a SID panel (done)
  3. Turn the disk inspector into a more useful debugging tool (as a preparation for 4) (in progress)
  4. Try to fix some of the disk related bugs (todo)

I decided to bump up the version number to 2.0 because of point 1 (which was one of my personal milestones).

ReSID still gives me a hard time. I did some performance profiling and recorded the following numbers on my machine (VirtualC64 in warp mode):

8.7 MHz FastSID
6.5 MHz ReSID, SAMPLE_INTERPOLATE
5.6 MHz ReSID, SAMPLE_RESAMPLE

Even with the faster SAMPLE_INTERPOLATE method, ReSID consumes about 25% of total CPU time. It seems that we need to reenable the ReSID SAMPLE_FAST option (which does not play well with on-the-fly switching between engines though).

Here is my solution: In V2.0 beta (which can downloaded from the VirtualC64 home page), SAMPLE_FAST can be combined with the 6581 chip model. If the 8580 model is selected, a user alert comes up:

sidalert

For me this version 2.0 beta is the best. All works fine !!!
Thanks

Great version, it works well!

Ok
All works fine for me too.
Thank you

Thanks for testing the beta. I just removed the "beta" and made the new version show up when checking for updates.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bluecursor picture bluecursor  路  5Comments

ChuckCaplan picture ChuckCaplan  路  7Comments

dirkwhoffmann picture dirkwhoffmann  路  5Comments

bluecursor picture bluecursor  路  7Comments

Alessandro1970 picture Alessandro1970  路  5Comments