stryd_one

What about that assertion error you posted? I don't see why this code should generate that error. I think maybe there's something else here.... I tried as you said and got no errors.... main.c: ///////////////////////////////////////////////////////////////////////////// // Include files ///////////////////////////////////////////////////////////////////////////// #include <cmios.h> #include <pic18fregs.h> const unsigned int dummya = 20000000; const unsigned int dummyb = 30000000; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after startup to initialize the // application ///////////////////////////////////////////////////////////////////////////// void Init(void) __wparam { } ..................etc etc etc............ Compiles fine: C:\Temp\sdcc_skeleton>make rm -rf _output/* rm -rf _output rm -rf *.cod *.map *.lst rm -rf *.hex mkdir -p _output sh C:\MIOS\_SVNMIOS\trunk\bin/mios-gpasm -c -p p18f452 -I./src -I C:\MIOS\_SVNMIOS\trunk/include/asm -I C:\MIOS\_SVNMIOS\trunk/include/share -I C:\MIOS\_SVNMIOS\trunk/modules/app_lcd/dummy -DDEBUG_MODE=0 -DSTACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f -I C:\MIOS\_SVNMIOS\trunk/modules/mios_wrapper C:\MIOS\_SVNMIOS\trunk/modules/mios_wrapper/mios_wrapper.asm -o _output/mios_wrapper.o sh C:\MIOS\_SVNMIOS\trunk\bin/mios-gpasm -c -p p18f452 -I./src -I C:\MIOS\_SVNMIOS\trunk/include/asm -I C:\MIOS\_SVNMIOS\trunk/include/share -I C:\MIOS\_SVNMIOS\trunk/modules/app_lcd/dummy -DDEBUG_MODE=0 C:\MIOS\_SVNMIOS\trunk/modules/app_lcd/dummy/app_lcd.asm -o _output/app_lcd.o sh C:\MIOS\_SVNMIOS\trunk\bin/mios-sdcc -c -mpic16 -p18f452 --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -I./src -I C:\MIOS\_SVNMIOS\trunk/include/c -I C:\MIOS\_SVNMIOS\trunk/include/share -DDEBUG_MODE=0 main.c -o _output/main.o C:\MIOS\_SVNMIOS\trunk\bin/mios-gpasm modifies _output/main.asm, result in _output/main__mios-gpasm-tmp.asm gplink -s C:\MIOS\_SVNMIOS\trunk/etc/lkr/p18f452.lkr -m -o project.hex C:\MIOS\_SVNMIOS\trunk/lib/libsdcc.lib C:\MIOS\_SVNMIOS\trunk/lib/pic18f452.lib _output/mios_wrapper.o _output/app_lcd.o _output/main.o C:\Temp\sdcc_skeleton> output ASM... I checked this to ensure the unused variable was not optimised away. ..................etc etc etc............ global _dummya global _dummyb ..................etc etc etc............ ; ; Starting pCode block for Ival code _dummya: DB 0x00, 0x2d ; ; Starting pCode block for Ival _dummyb: DB 0x80, 0xc3 ; ; Starting pCode block Note that it handled the overflow by simply discarding the upper bytes. Interesting, and related to the other thread you helped me on :) project.map (shows memory locations where the data is stored): _dummya 0x0035b6 program extern _output/main__mios-gpasm-tmp.asm _dummyb 0x0035b8 program extern _output/main__mios-gpasm-tmp.asm __str_0 0x0035ba program static _output/main__mios-gpasm-tmp.asm I included the string (That's the "hello world" string) to demonstrate that each variable has reserved sufficient space for both of the two bytes. It all looks ok? To test it, I also tried to add some code which would use these variables, just to ensure the optimiser was not toying with us. It generated some warnings, but the code looks ok. As well as the above, I added: unsigned int dummyc; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after startup to initialize the // application ///////////////////////////////////////////////////////////////////////////// void Init(void) __wparam { dummyc = dummya+dummyb; } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS in the mainloop when nothing else is to do ///////////////////////////////////////////////////////////////////////////// void Tick(void) __wparam { dummyc++; } Does generate the same notification you posted in the topic: C:\Temp\sdcc_skeleton>make rm -rf _output/* rm -rf _output rm -rf *.cod *.map *.lst rm -rf *.hex mkdir -p _output sh C:\MIOS\_SVNMIOS\trunk\bin/mios-gpasm -c -p p18f452 -I./src -I C:\MIOS\_SVNMIOS\trunk/include/asm -I C:\MIOS\_SVNMIOS\trunk/include/share -I C:\MIOS\_SVNMIOS\trunk/modules/app_lcd/dummy -DDEBUG_MODE=0 -DSTACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f -I C:\MIOS\_SVNMIOS\trunk/modules/mios_wrapper C:\MIOS\_SVNMIOS\trunk/modules/mios_wrapper/mios_wrapper.asm -o _output/mios_wrapper.o sh C:\MIOS\_SVNMIOS\trunk\bin/mios-gpasm -c -p p18f452 -I./src -I C:\MIOS\_SVNMIOS\trunk/include/asm -I C:\MIOS\_SVNMIOS\trunk/include/share -I C:\MIOS\_SVNMIOS\trunk/modules/app_lcd/dummy -DDEBUG_MODE=0 C:\MIOS\_SVNMIOS\trunk/modules/app_lcd/dummy/app_lcd.asm -o _output/app_lcd.o sh C:\MIOS\_SVNMIOS\trunk\bin/mios-sdcc -c -mpic16 -p18f452 --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -I./src -I C:\MIOS\_SVNMIOS\trunk/include/c -I C:\MIOS\_SVNMIOS\trunk/include/share -DDEBUG_MODE=0 main.c -o _output/main.o /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/gen.c:9229 symbol iTemp0 = [ dummyb ] is in code space /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/gen.c:9229 symbol iTemp1 = [ dummya ] is in code space C:\MIOS\_SVNMIOS\trunk\bin/mios-gpasm modifies _output/main.asm, result in _output/main__mios-gpasm-tmp.asm gplink -s C:\MIOS\_SVNMIOS\trunk/etc/lkr/p18f452.lkr -m -o project.hex C:\MIOS\_SVNMIOS\trunk/lib/libsdcc.lib C:\MIOS\_SVNMIOS\trunk/lib/pic18f452.lib _output/mios_wrapper.o _output/app_lcd.o _output/main.o C:\Temp\sdcc_skeleton> This is just a notification though, nothing to worry about. It gives you messages like this when you do a few things with the variables. It doesn't give any linker errors, and it does build the hex file and the output ASM looks OK: ; ; Starting pCode block S_main__Tick code _Tick: BANKSEL _dummyc ; .line 42; main.c dummyc++; INCF _dummyc, F, B BNC _10157_DS_ ; removed redundant BANKSEL INCF (_dummyc + 1), F, B _10157_DS_: RETURN ; ; Starting pCode block S_main__Init code _Init: ; .line 32; main.c void Init(void) __wparam MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 ; .line 34; main.c dummyc = dummya+dummyb; MOVLW LOW(_dummyb) MOVWF TBLPTRL MOVLW HIGH(_dummyb) MOVWF TBLPTRH MOVLW UPPER(_dummyb) MOVWF TBLPTRU TBLRD*+ MOVFF TABLAT, r0x00 TBLRD*+ MOVFF TABLAT, r0x01 MOVLW LOW(_dummya) MOVWF TBLPTRL MOVLW HIGH(_dummya) MOVWF TBLPTRH MOVLW UPPER(_dummya) MOVWF TBLPTRU TBLRD*+ MOVFF TABLAT, r0x02 TBLRD*+ MOVFF TABLAT, r0x03 MOVF r0x00, W ADDWF r0x02, W BANKSEL _dummyc MOVWF _dummyc, B MOVF r0x01, W ADDWFC r0x03, W ; removed redundant BANKSEL MOVWF (_dummyc + 1), B MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 RETURN ; ; Starting pCode block for Ival code _dummya: DB 0x00, 0x2d ; ; Starting pCode block for Ival _dummyb: DB 0x80, 0xc3 ; ; Starting pCode block __str_0: DB 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f, 0x72, 0x6c, 0x64, 0x21 DB 0x00 You mentioned c++ a few times... but we should be using a C compiler... Are you sure you have the correct toolchain? perhaps you can check the versions, by doing : sh --version make --version sed --version sdcc --version gpasm --version and post the results here. Here are mine: C:\Temp\sdcc_skeleton>sh --version GNU bash, version 2.04.0(1)-release (i686-pc-msys) Copyright 1999 Free Software Foundation, Inc. C:\Temp\sdcc_skeleton>make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 C:\Temp\sdcc_skeleton>sed --version GNU sed version 3.02 Copyright (C) 1998 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, to the extent permitted by law. C:\Temp\sdcc_skeleton>sdcc --version SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.8.0 #5117 (Mar 23 2008) (MINGW32) C:\Temp\sdcc_skeleton>gpasm --version gpasm-0.13.5 beta C:\Temp\sdcc_skeleton> But if it's not that... I think there is more to the code than you think ;) (aaaand now you know why I'm such a nazi about posting your code)

That's a good point. It's one of the things I have grown to like about C, is that it stays quite low-level, without needing me to do *all* of the thinking ;) Magic, of course ;D Hehehe... well of course there are ways to handle it, but in the end, the way it is done makes sense. Yeh, thanks dude. I don't know squat about C++!

Sure: Linux/m68k (debian will do that), and a pd patch that converts midi to OSC and back ;)

I'd like to see tracks outputting to loopback ports, processed before other tracks....

OK now that it has been mentioned elsewhere, I can suggest that the new core module, not yet released and a long time away, may be well suited to this job...

One thing I would suggest is loading more than 4 tracks into ram for editing, which would enable people to use the bigger BLMs that have been so heavily requested. Echo: you can already do the many-modulators thing with extra tracks ;) Needless to say I'm a big fan of individual tempo control per track, but as we already know, doing so with unusual meters (time signature/divider/etc) introduces some interesting challenges when you want to have independent track tempos but still keep them in phase (and even more so when you take things like realtime retriggering of tracks and loopback ports and such). It's easy enough to solve, but does cause a performance hit, so I'm not sure it's for everyone... That said, the chips we are playing with at present do have a hardware divider that will significantly reduce the overheads of such a system, so maybe it won't be so bad...

:D Text adventure! Bon Voyage G!

The CV/gate code reads a byte from memory and sends it to the appropriate pins... If you find the code that handles that byte, then you can use a comf instruction to flip the bits before they are sent to the appropriate output. I'd start with seq_ext.inc ;)

Search. http://www.midibox.org/dokuwiki/lcd?s=hd44780#character_lcd_controller_chips_supported_by_midibox

Is this a guessing game? Or did you just forget to post the error? ;)

Careful, you'll get so many hits with that search that your browser might crash. Not because of the extra load, but just because your CPU is not designed to handle so much useless info ;D I managed to get firefox's search engines to recognise SMF on midibox.org, and found the search2 action, but didn't have your skill to finish the job. Thanks dude! Slightly OT, there's a tool for linux called gnome-do that is a ripoff of quicksilver:

There are like 50 squillion downloadable ISOs which you can boot to and simply overwrite the administrator password. Very quick and easy, you'll be done within 5 minutes. The one I use is proprietary so I can't make a recommendation, but one linux based security boot CD is as good as another. ntpasswd / chntpw are a tool that'll do it, and the name has bootdisks at http://home.eunet.no/~pnordahl/ntpasswd/ If you want to, you can also use the install CD, but it's more messing around than I usually can be bothered with.

Hot in summer I can deal with - I'm from Perth ;) Plan looks pretty good. I'll give you a tip though - try to get everything from smash that he has available. For example, get ribbon cables from him rather than jaycar. We can move this when it becomes clearer where it should go :)

I didn't say there was anything wrong with a shift. That's correct. All that work demonstrates that you've kinda missed my point - I expected the language to take care of this, without my interaction, without writing extra code, without messing around, etc. It doesn't. No problem! I just kinda assumed that it would be 'smarter' than it is.

Then you're wrong. It's much faster for me to test it if you post your code. Faster means I spend less time on it, which is helpful to me, because I'm too busy to mess around. If you want help, please post your code. Edit: Of course, we don't need the *whole* app... but enough code to replicate the fault is helpful.

You didn't answer the question. I think you're missing the point here dude. It's pretty simple really. You pay. He ships. You don't get stuff, you PM him. You still don't get stuff, you PM him. If you feel that you need to warn others about the seller, then you can post here, politely. Otherwise, I fail to see any benefit in pursuing this further in the public forum.

OMG OMG OMG!! WHERE did you find that!? I've been trying to figure out the URL syntax for a search link for EVER! Thanks AC!!

A list never hurt anyone... what's the plan once you have it?

You bitch about people flooding the thread with OT, then say it doesn't matter... then say you want to post here, but you say you've already PM'd neb and got no response and there's nothing more you can do... Make up your mind man. I understand your frustration, I'd be pretty f***in annoyed myself to be honest... But just take a while to chill and decide what you want, then act accordingly. Right now, you're acting in anger and frustration and you're not making any sense - or progress.

Woof. Let that be a lesson to you all.

Seeing as they're separate lines the resistance should be infinite so you have a short.

Ah Brisvegas. Been thinking of moving there lately - but I do that every time I have to put up with a Melbourne winter. I think you'll be quite relieved once you try this out and discover how easy it is. The only tricky part for you will be the electronic interconnection, as (of course) the DD6 is not designed with this in mind. Fortunately the midibox is ;) And remember - there are no stupid questions, just stupid ways to ask them ;)

"These aren't the PCB's you're looking for" *waves hand*

Oh that whole thing! d'oh I missed all the fun! I'll sing the song instead... Bad mods bad mods...what you gonna dooo?....

Welcome aboard Martin. I see you've already had the obligatory introduction about read read read heheheh Where are you mate? There's a few aussies around these parts.