stryd_one

That means you just got a box with a big red M on it, right? ;)

Everything seems fine then... If you solder the pots on one-by-one and test them, while leaving all the other inputs grounded, you should find that all is well.

Sweet! Bummer about the soundcard but glad it went well otherwise :)

You should be honoured by your work :) "guru" just means I talk too much hehehehe Edit: Darn I can't even link to the image :( But that new diagram is excellent, thanks!

No, I think I just missed it! Fixed my post so as to avoid confusion, thanks dj3nk!

Fixed, see below

Yeh, but then it does the sizeof() every time :( There must be a way to automate this without creating new overheads...... I'm gonna take it up over at SDCC land and see what I can find....

The 4682 has a smaller code memory. I suspect that TK will use every bit available in the larger 4685 for V2. You might be able to alter this V1 code for that PIC but it's not worth the effort.

Just a few nuggets I thought worth sharing... Some useful, some maybe useful later ;) But I'll spare you visiting the manual in 5 different places to get all the relevant stuff. My comments in italics. Command line switches: --optimize-goto Try to use (conditional) BRA instead of GOTO (already in use by us) --optimize-cmp Try to optimize some compares. (already in use by us) --optimize-df Analyze the dataflow of the generated code and improve it. (some interesting results here. shrunk one of my asm files by 33%. Did nothing to others. Worth a try?) --obanksel=nn Set optimization level for inserting BANKSELs. (already in use by us, 2. 1 fixes some issues with variables >256B) 0 no optimization 1 checks previous used register and if it is the same then does not emit BANKSEL, accounts only for labels. 2 tries to check the location of (even different) symbols and removes BANKSELs if they are in the same bank. Important: There might be problems if the linker script has data sections across bankborders! --opt-code-speed The compiler will optimize code generation towards fast code, possibly at the expense of code size. (sometimes works) --opt-code-size The compiler will optimize code generation towards compact code, possibly at the expense of code speed. (sometimes works) --funsigned-char The default signedness for every type is signed. In some embedded environments the default signedness of char is unsigned. To set the signess for characters to unsigned, use the option –funsigned-char. If this option is set and no signedness keyword (unsigned/signed) is given, a char will be signed. All other types are unaffected. --verbose Shows the various actions the compiler is performing. -V Shows the actual commands the compiler is executing. --no-c-code-in-asm Hides your ugly and inefficient c-code from the asm file, so you can always blame the compiler :) (LOL) --cyclomatic This option will cause the compiler to generate an information message for each function in the source file. The message contains some important information about the function. The number of edges and nodes the compiler detected in the control flow graph of the function, and most importantly the cyclomatic complexity (Try this!) More info for those who haven't heard the term: Cyclomatic complexity of a function is defined as the number of independent paths the program can take during execution of the function. This is an important number since it defines the number test cases you have to generate to validate the function. The accepted industry standard for complexity number is 10, if the cyclomatic complexity reported by SDCC exceeds 10 you should think about simplification of the function logic. Note that the complexity level is not related to the number of lines of code in a function. Large functions can have low complexity, and small functions can have large complexity levels. SDCC uses the following formula to compute the complexity: complexity = (number of edges in control flow graph) - (number of nodes in control flow graph) + 2; Having said that the industry standard is 10, you should be aware that in some cases it be may unavoidable to have a complexity level of less than 10. For example if you have switch statement with more than 10 case labels, each case label adds one to the complexity level. The complexity level is by no means an absolute measure of the algorithmic complexity of the function, it does however provide a good starting point for which functions you might look at for further optimization. Pragmas opt_code_speed - The compiler will optimize code generation towards fast code, possibly at the expense of code size. Currently this has little effect. opt_code_size - The compiler will optimize code generation towards compact code, possibly at the expense of code speed. Currently this has little effect. opt_code_balanced - The compiler will attempt to generate code that is both compact and fast, as long as meeting one goal is not a detriment to the other (this is the default). nogcse - will stop global common subexpression elimination. noinduction - will stop loop induction optimizations. noinvariant - will not do loop invariant optimizations. For more details see Loop Invariants in section 8.1.4. nojtbound - will not generate code for boundary value checking, when switch statements are turned into jump-tables (dangerous). For more details see section 8.1.7. noloopreverse - Will not do loop reversal optimization Keywords __at - Use this to force a variable into a certain memory space. (Handy for using Access RAM eg; unsigned char __at 0x020 MyVar; ... Be CAREFUL! ) __wparam - Passes the first argument of a function in W. (TK uses this but most of the time we don't... For some reason. I have found it very useful, it saves a bank selection for the first 8 bits passed to it, if you only have one char as a function's parameter, it saves about 4 instructions :) ) Hope these are interesting and save you diving through that very informative and confusing manual :D

Yeh that's the kind of thing I mean :) It just seems strange to me that the compiler doesn't do that already? I mean, why do the same unrolled multiply every time the array is accessed when a much simpler way is, as you demonstrated, to have one function which calculates the address, and call that.... I figured that it might be because of the need to pass 4 bytes worth of variables around creating slower code, and maybe I needed to tell it to optimise for code size (--opt-code-size) but that didn't work :( I tried some of the other optimiser flags that are currently not used, but no joy there either... I tried using a pointer to the array but no good, it just used slightly larger pointer math each time ::).... But I didn't try forcing it to use a function of my own to calculate the pointer, I suspect that will do the trick nicely. I will have to do that soon anyway when I move the non-realtime data to SRAM, so it's on the cards... One tricky part is the size of the elements of the array... Obviously, SDCC calculates this on the fly but if I employ this method, then if I change the array, it's all screwy....But again, I'll have to work with that when it's all in SRAM anyway. I guess I'd like to solve these problems before I go ahead with my project, even though it won't benefit me right now, I think it'd be nice to have solutions here for future development.... Like the big arrays thing... I now see why TK breaks his seq data into small chunks of nice even sizes, and I'll be doing the same... but I just had to know! :D

Whomper with a laser designator + TK with smart bombs :) thanks guys!

16 posts and a working MBLC might be a record ;) Hope you send some pics!

This could be sooo many things right now. You mentioned other note-on's.... Are they all G#0 ? Have you tried uploading the ain64_din128_dout128_v2_0.zip app?

Surgeon General's Warning: Toying with rusty blades with bare hands may cause shoulder pain....from tetanus injections :)

Nice work man!

You could probably direct this to Smash himself... No need to talk of him in the third person ;) Just a word of advice - don't expect that you'll have this working in such a short time. You've kinda left it too late :( It's more than possible to do, but yaknow, Murphy's Law... If I had a dollar for every post I've seen that goes "Help! I have a gig/university assignment due this week and my midibox doesn't work, I'm screwed, Please help!".... I would not have to work during the day ;) Not trying to shut you down, but I just don't want you to rely on the midibox being there, cause it probably won't...and not because of smash's shipping times, but because you left it a bit late and Murphy is a bastard. ;)

Wow that place has a cool product, thanks for letting us know about it.... Really expensive though, it's more than a FPE panel, and doesn't include the panel itself! Ouuch!

That is one tidy layout!

More drum schematic links for you :) http://members.fortunecity.com/uzzfay/drumfire/df.html Drumfire DF500 http://www.electronicpeasant.com/projects/ssdrums/ssdrums.html The Electronic Peasant's Solid State Percussion Synthesizer Page http://www.hylander.us/moogschematics.html Schematics and Manuals Handclap Section pt.1 Handclap Section pt.2 TS-204 Synth Section pt.1 TS-204 Synth Section pt.2 TS-204 Synth Section, Detail of the Modulation circuit and a mod How are your projects going guys?

Yes there is :) If you declare with the __at keyword and specify a location within the access bank, sdcc takes care of the rest: main.c: extern unsigned char __at 0x030 myvar; Produces project.map: ustat_main_00 udata 0x000030 data 0x000008 ....And code which accesses the ram without bank selection. Yay. Developer General's warning - if you do this, choose your memory location wisely. :)

Nice case... Although if you think TupperWare is still cheap you probably bought yours in the 80's :D If you turn up the resonance it's RuptureWare ;)

Try this mate. As stolen from mb64 like a cowardly pirate, yargh. ;; -------------------------------------------------------------------------- ;; This function is called by MIOS when a pot has been moved ;; Input: ;; o Pot number in WREG and MIOS_PARAMETER1 ;; o LSB value in MIOS_PARAMETER2 ;; o MSB value in MIOS_PARAMETER3 ;; -------------------------------------------------------------------------- USER_AIN_NotifyChange ;; convert 10-bit value to 7-bit value rrf MIOS_PARAMETER3, F ; value / 2 rrf MIOS_PARAMETER2, F rrf MIOS_PARAMETER3, F ; value / 2 rrf MIOS_PARAMETER2, F rrf MIOS_PARAMETER3, F ; value / 2 rrf MIOS_PARAMETER2, F bcf MIOS_PARAMETER2, 7 ; clear 8th bit ;; now: pot number in MIOS_PARAMETER1 ;; 7-bit value in MIOS_PARAMETER2 ;; CC Ch 0 movlw 0xB0 call MIOS_MIDI_TxBufferPut ;; CC# = Pot# movf MIOS_PARAMETER1, W call MIOS_MIDI_TxBufferPut ;; CC Value = Pot Value movf MIOS_PARAMETER2, W call MIOS_MIDI_TxBufferPut

Hey guys. I've been bugged by this for ages, and I've not been able to find out anything about it... I hope one of you knows what's going on here... It's about the math for calculating addresses for arrays. Here's an example. I have nested arrays of structs that look like track[n].step[m].something. EVERY single time it needs to calculate an address for one of the arrays, it does the same damned pointer math like this: n*0x9e+0*0x07+something ; ;multiply lit val:0x9e by variable r0x00 and store in r0x00 ; ;Unrolled 8 X 8 multiplication ; ;FIXME: the function does not support result==WREG ; .line 100; vxevents.c track[(TRK)].step[(STP)].param1 = P1; MOVF r0x00, W MULLW 0x9e MOVFF PRODL, r0x00 MOVFF PRODH, r0x03 MOVLW LOW(_track) ADDWF r0x00, F MOVLW HIGH(_track) ADDWFC r0x03, F MOVLW 0x12 ADDWF r0x00, F BTFSC STATUS, 0 INCF r0x03, F ; ;multiply lit val:0x07 by variable r0x01 and store in r0x01 ; ;Unrolled 8 X 8 multiplication ; ;FIXME: the function does not support result==WREG MOVF r0x01, W MULLW 0x07 MOVFF PRODL, r0x01 MOVF r0x01, W ADDWF r0x00, F CLRF WREG ADDWFC r0x03, F MOVLW 0x02 ADDWF r0x00, F BTFSC STATUS, 0 INCF r0x03, F MOVFF r0x00, FSR0L MOVFF r0x03, FSR0H MOVFF r0x02, INDF0 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN Is there some way of making the compiler be sane and have a function that can be called to do this, so I don't have the same damned code repeated a thousand times?

I'm glad you like the concept. The app is pretty close to supporting it already, the tricky part is coming up with useful mathematics to determine the length of the clock ticks... Like you might start with 96 ticks to count between ticks, then after it ticks, shift it right and increment a counter, repeat until the counter reaches n, then start over. The code for the subclocks probably could do with some optimisation, but they do work, if you want to borrow for the sensorizer shout out :)

Yeh this one is good to watch for sure :D