#290 TTL too short in resid

[Leandro Nini]

The floating_output_ttl, set to 0x4000 at line 210 in src/resid/wave.cc, seems too short as you can notice in track 2 from MUSICIANS/H/Hatlelid_Kris/Grand_Prix_Circuit.sid
The attached image (not perfectly scaled but you get the idea) shows the difference between the original, taken from http://www.6581-8580.com/, and the emulated wave recorded from vsid using resid.

[Leandro Nini]

Grand_Prix_Circuit song 2 - original vs resid

[Leandro Nini]

By looking at the picture I also spotted a regression in the external filter: the high-pass resistor value should be 1kOhm instead of 10kOhm

[Leandro Nini]

The tune games/s-z/Scruples.sid#2 suffer from the ttl problem too, had to set floating_output_ttl = 0x14000 to avoid clicks.

[Antti S. Lankila]

Both the high-pass filter and the TTL have been changed. Notice that it would be helpful if the analog output of actual 6581 and 8580 would be sampled to determine an approximation of true value for the TTL. It seems that it can't be read from OSC3.

[Leandro Nini]

Another problematic tune: /MUSICIANS/P/PVCF/Thomkat_with_Strange_End.sid
There is a strange spike after the beats at the beginning of the song caused by the waveform ttl.

[Leandro Nini]

Sorry, just realized that the change to the external filter was intentional. From the resid changelog:

* extfilt.cc (ExternalFilter::ExternalFilter): Assumes audio
equipment impedance of 10kOhm, yielding a high-pass 3-dB frequency
of 1.6Hz (changed from 16Hz). Cutoff frequency fixed point accuracy
is traded off for for vastly improved filter signal fixed point
accuracy.

You might want to revert change 27476 to restore intended behavior.

[Antti S. Lankila]

Leandro Nini drfiemost@users.sf.net kirjoitti 13.1.2014 kello 20.29:

Sorry, just realized that the change to the external filter was intentional. From the resid changelog:

• extfilt.cc (ExternalFilter::ExternalFilter): Assumes audio
  equipment impedance of 10kOhm, yielding a high-pass 3-dB frequency
  of 1.6Hz (changed from 16Hz). Cutoff frequency fixed point accuracy
  is traded off for for vastly improved filter signal fixed point
  accuracy.
  You might want to revert change 27476 to restore intended behavior.

Well, that is a point one can consider, but based on the RF modulator schematic, which the audio is also routed to, the impedance is through that path is probably at most equivalent 6.6 kOhm, and this is with no other load connected. An impedance of 10 kOhm in parallel to that would give about 4 kOhm as the load after the capacitor.

I personally think that this is a moot point anyway. A high pass filter closer to 20 Hz seems like a reasonable thing to do because actual audio equipment that all real C64s have been connected will have something like that in the audio path. That being said, this is just one opinion, and we can quibble over whether we tune the filter to 1.6 Hz, 6.4 Hz or 16 Hz if we prefer based on what the emulation target is. I’d prefer to match behavior in actual samplings from the emulator within some degree of accuracy, and more importantly, I do think that 1.6 Hz behavior will settle DC changes slower than a real C64 would, if a high-impedance oscilloscope were connected to the audio output path to observe it.

Any other thoughts?

Antti

[gpz]

mmmh am i mistaken, or can this be closed? the ttl in wave.cc is fixed, and the filter thing is not an issue... right? :)

[Leandro Nini]

Another problematic tune: /MUSICIANS/P/PVCF/Thomkat_with_Strange_End.sid
There is a strange spike after the beats at the beginning of the song caused by the waveform ttl.

This one still have issues. I've settled to a value of 0xF4240 (~1 sec) but it's a totally random number :/

[Leandro Nini]

Well, actually it seems possible to get some info by sampling OSC3, obviously missing the low bits.
I've played a bit with an exSID USB and found out that the total fade out time is actually shorter, ~40msec on a warm 6581, however the individual bits go down at different moments. At power up the times are quite longer, but after some minutes of playing the values settle down around the following figures:

* bit 7 - 11.468ms
* bit 6 - 3.647ms
* bit 5 - 15.369ms
* bit 4 - 26.401ms
* bit 3 - 34.194ms
* bit 2 - 32.645ms
* bit 1 - 34.414ms
* bit 0 - 35.270ms

In the test program I first set up voice 3 with a square wave at freq $ffff, pw $000 and sustain $f, then, after OSC3 reaches $ff, I set the control reg at $01 and measure the time each bit takes to fall down to zero.

The first attempt at emulating this behaviour didn't deliver the expected results, at least at visual waveform inspection, so I need to experiment further.

notes:
* the tests have been performed on a 6581 R4 AR 3586 S
* the exSID clocks the chip at exactly 1MHz

[Antti S. Lankila]

Leandro Nini drfiemost@users.sf.net kirjoitti 25.1.2016 kello 12.42:

Well, actually it seems possible to get some info by sampling OSC3, obviously missing the low bits.
I've played a bit with an exSID USB and found out that the total fade out time is actually shorter, ~40msec on a warm 6581, however the individual bits go down at different moments. At power up the times are quite longer, but after some minutes of playing the values settle down around the following figures:

* bit 7 - 11.468ms
* bit 6 - 3.647ms
* bit 5 - 15.369ms
* bit 4 - 26.401ms
* bit 3 - 34.194ms
* bit 2 - 32.645ms
* bit 1 - 34.414ms
* bit 0 - 35.270ms

In the test program I first set up voice 3 with a square wave at freq $ffff, pw $000 and sustain $f, then, after OSC3 reaches $ff, I set the control reg at $01 and measure the time each bit takes to fall down to zero.

The first attempt at emulating this behaviour didn't deliver the expected results, at least at visual waveform inspection, so I need to experiment further.

It’s probably smarter to examine this visually from a sampled analog output waveform, than rely on the digital side. This is for two reasons.

Firstly, we can get no data for voices 1 and 2 digitally.

Secondly, voice 3 is different from voices 1 and 2 in having OSC3 exist in the first place, which might affect the results for that particular voice.

I would suggest sampling the bit fade for all the voices individually by setting a pulse to 0xfff, and then disconnecting the output from the waveform mixer, and then analyzing the timing for bit 7/6 fade from the analog waveform to estimate how long it takes until couple of the MSB have faded. We should probably not attach much importance to the fade times of the bottom bits because they will probably be relatively quiet in the mix.

I remember that the time for the bit fade from my cold C64 was quite long, at least 100 ms long, and I could hear this kind of garbling sound as the individual bits faded. Based on this data, and since bit 7 is the MSB, having that fade already at 11.468 ms suggests that 0x4000 is already too much, as weird as it seems. Perhaps a few tests using the other voices show a different bit fade duration, and that might explain the inconsistency between analog sampling and the digitally established truth.

Antti

[gpz]

a) there has been a test program for this in the repo for a while now
b) the behaviour varies wildly between different chips (or perhaps also motherboards. the room temperature. etc etc)

frankly, i doubt that measuring anything will solve anything in this case. in any case, you'd have to do it on a dozen C64s (or even more) to get any half meaningful results,

[Leandro Nini]

Thank you for the feedback.
I'll do some more measurment and tests, even if these might be inconclusive I'd like to see if implementing some sort of bitfading could avoid the clicks that the abrupt change to zero causes now.

[gpz]

perhaps also experiment with MUCH longer times.... chances are that just reading from OSC3/ENV3 makes them shorter (because that "sucks charge"). respectively, a different test program should get written that repeatedly does ONE read from these after a certain delay, instead of doing repeated reads like it does now. wouldnt surprise me if all if that would lead to totally different (much longer) numbers.

[gpz]

can we close this?

[Leandro Nini]

The tune /MUSICIANS/P/PVCF/Thomkat_with_Strange_End.sid still clicks so the timeout value is not ok yet.
Sampling the analog output is of no help due to the DC filter, a better solution would be measuring directly from the audio output pin, but I don't have an oscilloscope.
An alternative idea would be to force a click after setting waveform 0 for some time and check if clicking is actually audible, something along the lines:

1) set pulse+testbit pushing the output at $fff
2) set waveform 0
3) wait n cycles until the output falls down to zero
4) set pulse+testbit to force the output at $fff again causing the clik

if the click is low or not audible the waveform output has not fall down completely so the timeout must be incresed.
Unfortunately my attempts so far have been unsuccessful so I might be missing something here.

As for the external filter stage I had a talk with the exSID creator, being more knowledgeable than me in electronic stuff, and if I got it correctly this is actually a DC blocker which, when a load is connected, acts as an highpass filter with a cutoff frequency dependent on the external device impedance. So the choice of the value is arbitrary, it could even be made configurable.

[gpz]

i have an oscilloscope and a logic analyzer here.. if you can provide a test program and tell me what to measure exactly, i can do that probably :)

[Leandro Nini]

Tried to put together a test program. The idea is to set a pulse wave at $000 at max level then, after a keypress, set waveform zero and count the number of frames it takes until the output settles, manually signaled by another keypress.
According to the c64 digi article on a 6581 it should start at around 5.29V and then rise up to ~6.34 volts.
Hope this makes sense...

[gpz]

zero-x did some quick measurement the other day, with surprising results, this was with a 6581R4AR and the audio-out in the socket, measured at the socket:

http://oms.wmhost.com/testWave00.png

ie a drop from ~7 to ~6V in about 3ms

no idea what this tells us shrug

(and just so i dont have to search for it again, here is a backlink to [#1128] ...)

[Leandro Nini]

Seems quite short... Grand_Prix_Circuit.sid required more than 16ms to play without pops and Scruples.sid even more. I'm a bit confused about the voltage levels too...

[Leandro Nini]

Tried to do some measurements but I get weird voltage values and with waveform zero it seems to settle at a DC level inbetween the two pulse wave extremes, which doesn't match with the observed behavior, it's so confusing :/

So I got back to the OSC3 measures (BTW, the register is latched so reading from it should not interfere with the actual value) and got a TTL time of ~95ms for a 6581R3 and ~1s for an 8580R5.
Also measured the shift register reset times and got ~210ms for the 6581R3 and ~2.8s for the 8580R5.
Tried an 6581R4AR too and funnily the timings are more toward the new model than the old one, ~1s for wave zero and ~2.15s for the shift reg.

This is just for the record, I really have no clue about what's gong on at this point...