Community: Message List

Re: Simple Multiplication Question

support@line6.com — Tue, 12 Feb 2013 14:05:10 GMT

Dear cheezor,

reviewing your code was not that easy. I can ee the timer checking the accumulator content for zero but not the influence on the audio signal. Anyways there are two other possibilities to mute the signal by flipping a bit:

1.) Flip the sign bit, this is corresponding the guard bits in accumulator a2 correspinding to bit 23 in the operand registers. Be careful not to change bit 47 in the accumulator since this is _not_ the sign bit - this is inherent in the accumulator guard bits.

The result is the same as moving -1.0 to any of those registers. Afterwards the polarity should be inverted in the accumulator by the 'neg a' instruction. Note that writing ~1.0 = 0.9999998 to a register is done by flipping _all_ bits except the sign bit, but maybe the right polarity of the output signal isn't an issue for your application.

2.) Use the flipped bit to control writing 0.9999998 or 0.0000000 corresponding to 1.0 and 0.0 correspondingly. This is really annoying but the DSP can handle control istructions much worse than a microcontroller. Code branches are relatively unusual in DSP algorithms compared to the tight MAC loops this architecture was designed for. It is possible to code conditional code execution but this is more nasty than on ARM or even 8051. We can have conditional code execution but only for BRxx and Jxx (or BRSxx and JSxx for subroutines) where xx is corersponding to the status register flag settings combinations.

In each case have a try with the Symphony Studio simulator for first. Small items like this can be observed conveniently by changing the register numbering formats from fractional, interger and hexadecimal on the fly.

Have fun checking the DSP563xx architecture with the simulator,

Christian

Re: Simple Multiplication Question

support@line6.com — Thu, 07 Feb 2013 20:12:47 GMT

Hi Cheesor,

you're right, the problem lies in the number format of the DSP. Your 'counter' increments the least significant bit in the accumulator. The DSP fractional numbering format uses the MSB (most significant bit) as sign bit with the weighting -2^0 = -1.0 The following bits are weighted by the factors 2^-1 (1/2), 2^-2 (1/4) and so on. Doing a multiplication by the timer 'content' caused the input sample multiplied by 2^-24 if you copy (move) the register content a0 to one of the operand registers in advance. Just moving the incremented accumulator causes to copy the content of the accumulator a1 which is zero unless you incremented the counter 2^24 times.

So the phenomenon is clear to me, the result yields zero (000000) or an even _very_ small negative number FFFFFF (-2^-23, to calculate this is left as an exercise to the reader, just follow the rule given above :-)).

So in your case branching (i.e. muting the signal corresponding to the flag setting) is the only option I can see for the moment.

If you give a concise description of the problem you intend to solve I could probably help more.

Christian

Re: Delay effect

support@line6.com — Sat, 28 Apr 2012 07:50:50 GMT

Hi Mike,

now I've checked my 'homebrewn' modulo and removed some bugs. The following code is to be tested by the simulator:

; Assembler directives

bufstart equ $1000

delay equ $000F

bufend equ bufstart+delay

org p:$0 ; Look for proper code memory base address on real silicon

; This code goes to initialization

move #bufstart,r1 ; Here the pointer to the arbitrary length modulo buffer is placed.

; The restrictive rules for modulo addressing are no longer valid...

move #$FFFFFF,m1 ; ..since we use the linear addressing mode

; This code goes to main loop

loop

; Get input value to x0 in advance - this code isn't listed here!

move x:(r1),x1 ; read sample out of delay buffer

move x0,x:(r1)+ ; write new input sample to delay line

; all the following is buffer management overhead - get your modulo addressing by hand.

; Anyway this isn't too much overhead compared to the strong modulo addressing rules!

; We just check if the pointer r1 has reached the 'modulo' buffer end

; - if so, we just reset it to the original address location

move #bufend,x1 ; get buffer end address

move r1,a ; get the current delay line address for test if modulo buffer end is reached now

cmp x1,a ; see if pointer has reached the buffer end address

; - essentially the comparison (cmp) is a subtraction by x1 of a

jne noreset ; if not, do not reset pointer - check if the result is not equal (ne).

; If not so don't reset the pointer by jumping over the next instruction.

move #bufstart,r1 ; if so, reset pointer to #bufstart

noreset

jmp loop

; more code goes here

Re: Delay effect

support@line6.com — Tue, 24 Apr 2012 20:00:50 GMT

Hi Mike,

the short answer is: yes, its possible. The long answer: its not that easy. You can't take benefit of the AGU directly since you cant't use the modifier registers for modulo adressing as you said since they are limited to 15-bit word length. I thought about that for a minute and got this simple idea:

1.) Use linear adressing - set the modifier to $xxFFFF

2.) You have to create your own modulo buffer. To do so you have to manage the pointer administration overhead by yourself - the classic approach.

3.) You can use a single pointer (any Rx corresponding to the Mx modifier) and read an old sample before overwriting it by the actual one.

4.) After each read/write procedure, increment the pointer and check if it has reached the end position (delay offset) for your delay buffer depth.

5.) If so reset the pointer to the original address

Here an idea for a code snippet (not tested)

bufstart equ $1000

delay equ $FFFF

bufend equ (bufstart + delay)

org x;

test ds 1

org p:

...

; initialization

move #bufstart,r1

move #$FFFFFF,m1

...

; this goes to loop

...

; get input value to x0

move x:(r1),x1 ; read sample out of delay buffer

move x0,x(r1)+ ; write input sample to delay line

; all the following is buffer management overhead - get your modulo addressing by hand.

move #bufend,x1 ; get buffer end address

move r1,a ; get the current delay line address for test

cmp x1,a ; see if pointer has reached the buffer end address - essentially the comparison (cmp) is a subtraction by x1 of a

brpl noreset ; if not, do not reset pointer - check if the result is positiv (pl). If so don't reset the pointer.

; You may also try brnz (branch is not zero) to match the buffer end point more exactly

move #bufstart,r1 ; if yes, set pointer to #bufstart

noreset

... ; more code goes here

Please give feedback if you could solve the problem. A good idea might be to check the code using the simulator. I will do so soon...

Best regards

Christian

Re: How do I get my ToneCore Development Kit working on Windows 7?

support@line6.com — Thu, 16 Feb 2012 18:05:05 GMT

I had a trial on my side using Windows 7 32-bit. This works like XP even without a virtual machine. The issue is just running 64-bit.

If I run it in the compatibility mode "Windows XP Service Pack 2" (as administrator) I get an error message "You need Windows XP with Service Pack 2 or Windows Vista to run this installation", without compatibility mode I get the message "62-bit version of Windwos are not supported for the moment. Please use a 32-bit version of Windows". Nice help. Sorry to say, I couldn't solve this issue. Recompiling for 64-bit and adding 64-bit drivers on the Line6 side will definitively help.

Re: How do I get my ToneCore Development Kit working on Windows 7?

support@line6.com — Sat, 11 Feb 2012 05:45:02 GMT

Hi Swidmark,

TCDK isn't supported on 64-bit Windows systems - neither Windows 7 nor Vista. I had a try on my side with both Windows 7 versions - sorry, it cant be installed using 64-bit. Probably they had to rewrite the drivers. Downgrade to 32-bit to run TCDK please without any issues.

Best regards

Christian

Re: Tonecore DSP P:ROM library functions?

support@line6.com — Mon, 01 Nov 2010 17:31:15 GMT

Hi Mike,

as far as I could read the documents Freescale only provides the API, not the sources - at least I don't have any.

If you like to do sample processing you better write your own code with the help of the application notes that are available. I do not remember the block size, anyway the code didn't fit the purpose of professional audio application much - this is more on surround processing and subwoofer management.

If you read the PPP documentation you can obtain your own opinion on this...

Best regards

Christian

Re: Tonecore DSP P:ROM library functions?

support@line6.com — Sun, 31 Oct 2010 06:59:30 GMT

Hi,

addresses p:$ff1000 to p:$ff3000 indeed contain an internal ROM that is user accessable, see the memory maps on page 3-6 in the DSP56364 user manual. There's also a special bootstrap mode (Mode A) to jump to address p:$ff1000 end execte the code from here.

The program ROM contains the Motorola post processing phase (PPP) DSP algorithms. The basic software contains delay managers, volume managers, sound field processing (stereo processing), graphic equalization, tone control and auxiliary channel mixdown. For Dolby and/or DTS licensees also decoder variants are available.

Anyway the PPP arcitecture is useless if you want to design audio effects or use the DSP563xx for professional audio applications. I too this into consideration and read all the PPP documentation I was provided with by my local Freescale FAE. The reasons for this is that the PPP arcitecture is designed for DVD decoder and automitive audio applications. PPP uses bock signal processing by 'round robin' scheduling slots to the individual PPP processes. This causes signal latencies that are not acceptable for a guitar effect or any other audio application where the musician can monitor his own signal. For the two said applications the DSP56364 was designed for this is of no concern.

The PPP architecture can be used to design consumer equipment for these target markets without DSP programming - you can just use the DSP like an ASIC (application specific integrated circuit). Fortunately all DSP56xxx can be used as programmable DSPs as we do for the ToneCore. Sidenote: in the old days with the DSP56002 there were a sine wave and A-law/µ-law logarithmic quantizer (this is for speech coding) tables available. I made use of the sine wave table then.

Best regards

Christian

Re: 8031/shi_receive in Filter Example?

support@line6.com — Fri, 11 Jun 2010 17:44:28 GMT

Hi,

on the other end of the SPI interface is not an 8031 but a freescale HC08. Anyway the Bcc instruction is the conditional branch where 'cs' is indeed 'carry bit set'. The code is not for an 8031 but for the Freescale DSP563xx.

Have a look here http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=DSP56364&nodeId=0127955654&fpsp=1&tab=Documentation_Tab to p. 13-18 for the Bcc instruction and to p. 12-23 for the condition flags.

There is indeed a track that the original SPI communication had and 8031 on the other end. I write some comments in between the assembler lines to give some addl. information even if I didn't write the code.

shi_receive
        movep   x:M_HRX,x:HostCommand     ; Get word from 8031.
; The M_HRX register has received a word from the 8031. This has triggered the SPI interrupt that called the ISR.
; The received word is written to the HostCommand variable.

        movep   #000000,x:M_HTX          ; Assert HREQ* pin for 8031.
; Writing to the M_HTX register asserts the HREQ pin. 

        btst    #0,x:HostCommand        ; $000001 = Write 1 DSP word to X:mem.
; Bit 0 in the HostCommand variable is tested. The protocol is defined for $000001 to write one DSP word to the X memory.

        bcs     DoWriteCommand          ;
; If the C flag is set then the write command to SPI is executed.

        btst    #3,x:HostCommand        ; $000008 = Send word to the 8031.
; Bit 0 in the HostCommand variable is tested. 
; The protocol is defined for $000008 to read one DSP word to the X memory.

        bcs     DoReadCommand   
; If the C flag is set then the read command from SPI is executed. 

Please have a look to the uC (HC08) code to understand the entire communication.

in publicVariables.h you find:

/* These are the commands for the DSP communication */
#define   CMD_READ_FROM_DSP            0x08
#define   CMD_WRITE_TO_DSP             0x01

These constants are used in the functions in DSP.c:

static void vfnDSP_StateTx(void)
...
        if (DSP_HREQ_READY)
            {                                                
                vfnSPI_SendWord(CMD_WRITE_TO_DSP);
                u8TxState = TX_STATE_ADDR;
            }            
...
}

and 

static void vfnDSP_StateRx(void)
{
...
       if (DSP_HREQ_READY)
            {
                vfnSPI_SendWord(CMD_READ_FROM_DSP);
                u8RxState = RX_STATE_ADDR;
            }            
...
}

regards

Christian

Re: Using Symphony Studio to debug on-target?

support@line6.com — Sat, 06 Mar 2010 06:51:53 GMT

There's no code on the pedal from anyone else than me. I'm just following Angelo's recommendation to locate a bug in my own program. All other codes I can load into the ToneCore pedal are available as source code. So why worry?

Best regards

Christian