DSP Robotics Support

tulamide wrote:Hmm, why am I experiencing something completely different? I started the schematic, it all went ok, then I switched the selector to the oversampling module and Flowstone crashed immediately.

Maybe it is not compatible back to the stoneage? Using v3.0.6 of Flowstone, that's why I ask.

Oh... I think I know what the issue is. The first assembler block uses "jmp" instruction, which was added in 3.0.8
The fix was easy - change jmp to jnz (jump if not zero - it just happens to be that result of previous operation always non-zero) and change "add eax,16" two lines above to "add eax,17" (this is because jnz instruction is 1 byte longer, thus the pointer to next line of code must be adjusted one more).

Hey KG, some serious hacking going on here!
I can see at least two areas of CPU syvings:
1. use SSE (all four lanes instead of only one)
2. Use polyphase filters, i.e. Don't waste time on samples that you throw away later.

well, I'm trying to figure out what this system really use,
there is a bit of voodoo in it?
if you try to connect the input of the oscillator directly to the downsampler module (the 10 pole filter),
then not using the output of the your code module in the first section,
it works the same way.
where is the voodoo?

FlowStoner wrote:

voodoo.png

well, I'm trying to figure out what this system really use,
there is a bit of voodoo in it?
if you try to connect the input of the oscillator directly to the downsampler module (the 10 pole filter),
then not using the output of the your code module in the first section,
it works the same way.
where is the voodoo?

All stream inputs to the code you wish to oversample should pass through the first assembler block to ensure correct order of execution:
1. code before inputs gets executed
2. first ASM block gets executed
3. the oversampled block gets executed
4. second ASM block gets executed (which loops back to 2nd step N times, before continuing to 5.)
5. code after the output gets executed.

If you don't pass your inputs through the first ASM block and outputs through the second ASM block, you run risk of faulty order of execution. for example:
2, 1, 3, 4, 5 => your code of your inputs end up being oversampled too
1, 3, 2, 4, 5 => your code will not get oversampled, because the first ASM block gets executed after it.
1, 2, 3, 5 => last asm block will not get executed, so nothing gets oversampled (there is nothing to loop the code back)
etc.

wanted to check this out ... but as soon as I switch the BOOLEAN, v3.04 crashes

RJHollins wrote:wanted to check this out ... but as soon as I switch the BOOLEAN, v3.04 crashes

I honestly have no idea why that should be the case. Here are possible culprints:

1. check if the "call of cuthulu" module outputs non-zero value

2. connect text prim to the assembler components' (green C) output and check if they match following:

fist one

Code: Select all

----- inputs -----
type=39 name=CallOfCuthulu
type=39 name=oversampling
type=39 name=in0
type=39 name=in1
----- outputs -----
type=39 name=codepoint
type=39 name=out0
type=39 name=out1
----- vars -----
F1=1.000000
  1.56,
c=0.000000
  1.45,1.83,
CallOfCuthulu=0.000000
  1.2,
codepoint=0.000000
  1.26,1.90,1.97,
oversampling=0.000000
  1.66,
in0=0.000000
  1.104,
out0=0.000000
  1.111,
in1=0.000000
  1.118,
out1=0.000000
  1.125,
----- stageInit -----
size=0
----- stage1 -----
size=0
----- stage2 -----
size=129
000--8B 85 70 1C 00 00 3D 00 00 00
010--00 0F 84 70 00 00 00 FF D0 05
020--11 00 00 00 89 85 40 1C 00 00
030--0F 85 01 00 00 00 58 66 0F 72
040--F3 20 0F 28 85 A0 1C 00 00 0F
050--C2 D8 00 0F 58 85 90 1C 00 00
060--0F 28 C8 0F 28 95 80 1C 00 00
070--0F C2 CA 00 0F 54 D1 0F 5C C2
080--0F 29 85 A0 1C 00 00 0F 55 8D
090--40 1C 00 00 0F 29 8D 40 1C 00
100--00 0F 28 85 B0 10 00 00 0F 29
110--85 50 1C 00 00 0F 28 85 00 00
120--00 00 0F 29 85 60 1C 00 00
----- stage3 -----
size=0

second one:

Code: Select all

----- inputs -----
type=39 name=codepoint
type=39 name=in0
type=39 name=in1
----- outputs -----
type=39 name=out0
type=39 name=out1
----- vars -----
F1=1.000000
c=0.000000
temp=0
in0=0.000000
  1.3,
out0=0.000000
  1.10,
in1=0.000000
  1.17,
out1=0.000000
  1.24,
codepoint=0.000000
  1.30,
----- stageInit -----
size=0
----- stage1 -----
size=0
----- stage2 -----
size=47
000--0F 28 85 B0 1C 00 00 0F 29 85
010--20 1C 00 00 0F 28 85 00 00 00
020--00 0F 29 85 30 1C 00 00 8B 85
030--40 1C 00 00 3D 00 00 00 00 0F
040--84 02 00 00 00 FF D0
----- stage3 -----
size=0

Particularly, the hexadecimal strings (the "000--8B 85 70 1C 00 00 3D..." parts) need to match. If they don't please PM them to me...

Hi KG.

I only checked the first 'cuthulu' module. I think I found a mis-match in the HEX section.

Here is my readout:

Code: Select all

----- inputs -----
type=39 name=CallOfCuthulu
type=39 name=oversampling
type=39 name=in0
type=39 name=in1
----- outputs -----
type=39 name=codepoint
type=39 name=out0
type=39 name=out1
----- vars -----
F1=1.000000
  1.56,
c=0.000000
  1.45,1.83,
CallOfCuthulu=0.000000
  1.2,
codepoint=0.000000
  1.26,1.90,1.97,
oversampling=0.000000
  1.66,
in0=0.000000
  1.104,
out0=0.000000
  1.111,
in1=0.000000
  1.118,
out1=0.000000
  1.125,
----- stageInit -----
size=0
----- stage1 -----
size=0
----- stage2 -----
size=129
000--8B 85 F0 17 00 00 3D 00 00 00
010--00 0F 84 70 00 00 00 FF D0 05
020--11 00 00 00 89 85 C0 17 00 00
030--0F 85 01 00 00 00 58 66 0F 72
040--F3 20 0F 28 85 20 18 00 00 0F
050--C2 D8 00 0F 58 85 10 18 00 00
060--0F 28 C8 0F 28 95 00 18 00 00
070--0F C2 CA 00 0F 54 D1 0F 5C C2
080--0F 29 85 20 18 00 00 0F 55 8D
090--C0 17 00 00 0F 29 8D C0 17 00
100--00 0F 28 85 90 10 00 00 0F 29
110--85 D0 17 00 00 0F 28 85 00 00
120--00 00 0F 29 85 E0 17 00 00
----- stage3 -----
size=0


I check the others later today ...

I've run the code through disassembler and they appear to be identical. Only difference being positions of variables in memory, which is expected and normal. I really don't know why it crashes... I'm unaware of any changes in flowstone from 3.04 that could be responsible for this...

I'm so sorry, KG, but the changes didn't help. v3.0.6 still crashes when switching the selector to the oversampling module.

But at least it works in 3.0.8+, so that's more important (Given that we will see a new version in the future, that may spread out quickly because of 64-bit).

I would love to help you getting to the root of this crash, but Assembler is a foreign language I'll never learn. And how the heck do you keep track of supported/unsopported opcodes in various versions of Flowstone?

tulamide wrote:And how the heck do you keep track of supported/unsopported opcodes in various versions of Flowstone?

http://www.dsprobotics.com/versions.html

assembler was really updated only twice. First in 2.0.8 and then 2.0.9 beta... So everything except stuff mentioned there should be compatible back down to synthmaker.

....
Now I remembered... I also used andnps which has weirdly semi-supported in older versions... Try if this one works: