[TK.]

Hi Kokoon,

thank you for the patches - there are really nice ones! :)

But to a more important topic:

Quote

one thing i noticed - the osc envelope gets retriggered randomly when using WT. is that a known error?

ARGH!!!

I also noticed this with your patches, and to say it short: it's not a software, but a design bug!

Fortunately it can be easily fixed.

To make it short: the SID is clocked asynchronously to the PIC. Depending on the clock phase between the SID and the PIC, a setup or hold violation can happen at the chip select line if the bus access is done at the "wrong moment" (rising edge on both clocks at the same time). It seems that this effect can only be noticed with the voice control register, which sets the waveform, sync, ringmod and the gate.

Statistically it happens very seldom, but if the voice control register is written with a very high frequency (e.g. 1.2kHz), it happens each 2..5 seconds (so after each 2500...6000th access) - and then it's really "noticable"

But fortunately there is cure: clocking the SID synchronous to the PIC. And this can be easily done by removing the oscillator, and by connecting the CLK pin of the SID (pin #6), with the 1MHz clock output of the CORE module (RC2, Pin #17, available at J7:SO - the middle pin)

Could you please try this? If you notice the same like me (no random gate triggers anymore), then you've uncovered one of the biggest bugs this year (even bigger than missing bypass caps ;-)

Here also an explanation why I haven't noticed this yet - I'm sure that I made some tests with asynchronous bus accesses years ago with the PIC16F877 based MIDIbox SID. A very easy check is just to write to the SID registers permanently - it worked. Now I did the same test with the PIC18F452, and it fails very often! (Test can be done by removing the "rgoto SID_SR_Next" instruction in sid_sr.inc). The main difference between both chips which could lead to such effects is 1) that the PIC18F452 is clocked 2 times faster, and that 2) the PIC18F452 works with an internal PLL, which delivers a more unstable frequency. Therefore the propability that the violation happens is much higher.

So, I hope that the proposed solution works in all cases. If not, the PIC clock could be delayed by a R-C pair. If this also doesn't help, then I'm in trouble ;-)

Best Regards, Thorsten.

[kokoon]

okay - i guess i'll have to read your post a few more times to understand what's going on :)
but i can probably find time to remove the crystals from SIDs and wire them to the core. i'll report ASAP.

[TK.]

fingers crossed!

Best Regards, Thorsten.

[illogik]

regardless of the outcome, i'm curious;

what is the advantage of using a different oscillator on the sid module; maybe we should just always use the core as clock, or no?

cheerss

[kokoon]

yay it's fixed now. i wired the clock from the core instead of the crystal. like you said.

problem solved  :D

[TK.]

Kokoon: these are great news! :)

Illogik: the intention behind the on-board oscillator was to have a backup solution for the case that pin RC2 of the PIC has to be used for something else. Another advantage is (or better was...), that the SID module could be accessed by other micros (or PCs) without the need for a clock generator (which is not easy to realize, especially with a PC)
So, the oscillator was never really required...

Today I made some experiments with SID bus transfer synchronization - since I'm not sure if the proposed solution works properly in all cases (e.g. independent from cable impedance and ambient temperatur), I've modified the SID bus driver in sid_sr.inc, so that it takes care for the falling clock edge, at which the data will be taken. Here a diagram (for people who are still interested...)



This old code in sid_sr.inc:

        ;; initiate a write and wait for 1.4 us (> one clock cycle)
        bcf     SID_SR_LAT_WR, SID_SR_PIN_WR
        movlw   0x03
        clrf    MIOS_PARAMETER3
SID_SR_WriteLoop3
        incf    MIOS_PARAMETER3, F
        IFNEQ   MIOS_PARAMETER3, ACCESS, rgoto SID_SR_WriteLoop3
        bsf     SID_SR_LAT_WR, SID_SR_PIN_WR

has been replaced by:

        ;; synchronize with rising edge of SID clock to avoid setup or hold violation
        ;; note: due to pipeline effects, the "bcf" will be executed 3 instruction cycles after
        ;; the polling loop. Therefore we are waiting for the falling edge
        IFCLR   PORTC, 2, bra $-2               ; wait for falling clock edge
        IFSET   PORTC, 2, bra $-2
        bcf     SID_SR_LAT_WR, SID_SR_PIN_WR    ; enable write (MBHP_SID: chip select)
        bra     $+2                             ; to ensure compatibility with on-board oscillator,
        bra     $+2                             ; wait for 1.2 uS (> one SID clock cycle)
        bra     $+2
        bra     $+2
        bra     $+2
        bra     $+2
        bsf     SID_SR_LAT_WR, SID_SR_PIN_WR    ; disable write (MBHP_SID: chip select)

Now it looks perfectly at the scope! Now the practice test starts - if I don't notice failures anymore, I will publish the required changes (and the updated firmwares) at my website

Best Regards, Thorsten.

[mattias]

Is it best to clock the sid from core then? Or what???

[moebius]

Quote

Is it best to clock the sid from core then? Or what???

Yup,

in the current setup it's the only way to ensure PIC -> SID data transfers are in sync.

Bye, Moebius

[TK.]

Btw.: I will update the MBHP_SID page soon - references to the onboard-oscillator will be removed (especially in the schematic), interconnection diagrams will be changed, SmashTV will create a new PCB

But to say it clearly: there is no reason for throwing away an old PCB, if you already own one (or more) - just don't stuff the oscillator, and clock the SID from the core module instead like already described at the MBHP_SID page.

Best Regards, Thorsten.