stryd_one

That is good :) Glad I could make sense. Sorry jsflint, if I were you, all that would probably make me go "WTF" right now! Just ignore us ;D

No worries mate. This seems to come up quite a lot (I've never used a mac but I'd heard of it) maybe that text should be in bold and the word "may" removed ;)

Awesome :D

:D Yay! Musta been the for loops in sneak's seq... Lesson learned, thanks for checking it out for us jsflint, now we are well informed for the future.

Detailed it is then... This kinda goes round in a circle before it gets to the answer.... :-\ Sorry... The r0x*** registers are used by SDCC as temporary variables within a function, the compiler decides where they are needed, and locates them in the Access Bank of ram on the PIC. The advantage of that, is that the access bank can be read or written, without the need for any additional instructions, whereas the remaining ram must be accessed either in banked or indirect mode. Banked operations require you to select the current memory bank prior to accessing the variable, you'll see those as BANKSEL in your ASM files (or SETBSR in TK's). Banksel is a macro which is substituted for the necessary command depending on PIC model - in our case I think BANKSEL MyBank becomes MOVLB MyBank. Note that it is a 2 word instruction (in order to carry enough data for the memory pointer). After that, you can read and write the variables only within that bank. If you go to a different bank, you need a new banksel. SDCC actually puts a banksel in every time, and the optimiser removes the unecessary ones. Indirect operations require you to load a memory pointer called the File Select Register or FSR. There are 3 of them, FSR0 FSR1 and FSR2, and they're a 14-bit pointer, so there is a low byte, and high byte of which only 6 bits are used. So you calculate the address to your variable, load it into FSRxH(5:0) and FSRxL, and the contents of that location are then available by reading or writing registers like INDFx and POSTDECx (which reads from the location and then decrements the address of the pointer). In order to access these variables like INDFx without needing a bank selection (which would obviously not work with other banked memory) they are also stored in the access bank. They are known as Special Function Registers or SFRs (not to be confused with FSR like I did hehehe). SFRs are registers used by the CPU and peripheral modules for controlling the PIC. Stuff like the timer registers, status bits, I/O ports (TRISx, PORTx etc) are all SFRs as well. The acces bank is actually split in two. All of these SFRs are stored in Access Bank High, which is located right at the top of the RAM. You can see it in the linker: ACCESSBANK NAME=accesssfr START=0xF80 END=0xFFF PROTECTED Table 5-2 in thee 4620 datasheet lists all the SFRs with a brief description. You probably know most of them already. Access Ram Low, which is at 0x000, is available for our applications. MIOS variables take up the first 16 bytes, and then 0x010 to 0x07F is free. You can see that memory described in the lkr as so: DATABANK NAME=miosvars START=0x000 END=0x00f ACCESSBANK NAME=accessram START=0x010 END=0x07F The MIOSVars are reserved by the wrapper am file : MIOS_VARIABLES udata 0x0000 _MIOS_BOX_CFG0 res 1 _MIOS_BOX_CFG1 res 1 _MIOS_BOX_STAT res 1 _MIOS_PARAMETER1 res 1 _MIOS_PARAMETER2 res 1 _MIOS_PARAMETER3 res 1 _TMP1 res 1 _TMP2 res 1 _TMP3 res 1 _TMP4 res 1 _TMP5 res 1 _IRQ_TMP1 res 1 _IRQ_TMP2 res 1 _IRQ_TMP3 res 1 _IRQ_TMP4 res 1 _IRQ_TMP5 res 1 And you can see them in the .map file: MIOS_VARIABLES udata 00000000 data 0x000010 Chances are, the very next line in your .map file will be this: .registers udata 0x000010 data 0x000038 And that's our friend, the r0x*** registers from SDCC. These registers were the result of this ASM file from sneakthief's seq: ; Internal registers .registers udata_ovr 0x010 r0x00 res 1 r0x01 res 1 r0x02 res 1 r0x03 res 1 r0x04 res 1 r0x05 res 1 r0x06 res 1 r0x07 res 1 r0x08 res 1 r0x09 res 1 r0x0A res 1 r0x0B res 1 r0x0C res 1 r0x0D res 1 r0x0E res 1 r0x0F res 1 r0x10 res 1 r0x11 res 1 r0x12 res 1 r0x13 res 1 r0x14 res 1 r0x15 res 1 r0x16 res 1 r0x17 res 1 r0x18 res 1 r0x19 res 1 r0x1A res 1 r0x1B res 1 r0x1C res 1 r0x1D res 1 r0x1E res 1 r0x1F res 1 r0x20 res 1 r0x21 res 1 r0x22 res 1 r0x23 res 1 r0x24 res 1 r0x25 res 1 r0x26 res 1 r0x27 res 1 r0x28 res 1 r0x29 res 1 r0x2A res 1 r0x2B res 1 r0x2C res 1 r0x2D res 1 r0x2E res 1 r0x2F res 1 r0x30 res 1 r0x31 res 1 r0x32 res 1 r0x33 res 1 r0x34 res 1 r0x35 res 1 r0x36 res 1 r0x37 res 1 You can see from the linker above that they can go up to END=0x07F, so in theory, we could have 0x6F (111) of them. Putting that theory into practice however, was not so successful in the case of sneakthief's seq. Because the variables are used as 'scratch space', they are often reused within a function. That app was using them as counters in for loops among ather things, and when that app got to r0x037 (it's last register) and tried to re-use r0x000 again, the thing went berserk and crashed the PIC. I suspect that this was actually a bug in SDCCs code, so maybe we can get away with it, maybe not... but it's the kind of thing that's often better off cleaned up anyway... Did that make any sense at all? :-\ Edit: Trivia - the PICs with CAN and USB peripherals have too many SFRs, and some of them are located in the upper regions of banked RAM, not in access ram. I don't know why I mention that ;D

Yeh that's a slightly longer story, still typing :)

Hahahah I would use the term expert very lightly in my case ;D You should be proud, that's very good work for a newbie!! :) Nah just leave em empty audiocommander has written a tutorial for xcode on the wiki, I would definitely check that out... When you run the makefile, it will generate an 'output' directory, and there will be .asm files in there... at least that's it on a PC... :-\

Well, there is that too... but I was more concerned with the number of temp registers it'll generate. Don't forget the Too many switch cases crashes MIOS? thread :) The problem here was not in fact the number of cases... it was all the for loops inside them. Simple way to find out though: Compile it, and count how many r0x*** registers you can see in the output file.

Have you got that plumstone thing installed? I think you need it on a mac?

Hey mate :) 1) No 2) Its fine there. 3) Yes 4) That's for Midibox Link. You won't need those but they won't hurt. 5) Yes 6) Adding dec and hex is fine 7) Yes I didn't go over your code too heavily, most of it looks OK, I would suggest loading it up and going from there :) Don't be afraid :) One bit of advice with the switch statements, instead of case m blah blah blah case n blah blah blah do case m dosomething() case n dosomethingelse() oh and instead of case 1 and case 0, you can just use an if statement... It should make for cleaner code but I really don't think it will make much difference in this simple controller as it should have ample cycles available :)

Sorry... fixed my post because you already answered that. Basically, all of MRE's advice still applies. One thing that I would try, is swapping around two of the ABC lines between the PIC and AIN boards... That will give us a hint.

The problem may very well not be caused by your PIC... I'll take it back to the other post for now :)

I think that in the days of so many varying latencies on instruments, a negative track offset should be an included feature on any midi sequencer. I know that cubase logic and sonar all support it, and also, most sequencers allow direct editing of the midi data, so that you could put the CC message before the first note manually if necessary.... So I think that CC's would be be the best implementation. Just my 2 cents :)

heheh yeh I am a sucka for a new kind of seq :) Sounds cool man, keep it up.

There was a bug in the wrapper but it's fixed now... Are you using tho latest version of the wrapper?

I wonder if your midi routing is creating feedback?

Err maybe not....Putting the if statement on every case is going to kill sdcc's optimiser, it won't generate a jumptable that way :(

Give it a shot, but when I tested pointers last week, I found that it recalculated the pointer every time it used it :( Weird, I know....

Doh! It's still great work :) Especially that you did it without TK's app hehehe

Gday :) The octopus is a sequencer not a controller, and I doubt that you will get any closer to the octopus than the vX on this platform... So far I'm not aware of any feature that it has, that was not in the vX design beforehand, and the vX has the subclockng engine on top of that. I was actually very glad for all my documentation here when the octopus was announced last year, otherwise I would be worried that they'd sue me hehehe :) The PIC just doesn't have the power of the octopus. That said, I am designing the firmware with the possibility of a future version that will be a multi core design using MBLink... But that's a little while off :) The intended design is really 16x12 steps, and similar again to the octopus, has different views, for eg: 16 steps across x 12 tracks, or 16 steps across x 12 notes (an octave, with up/down buttons). There's a (only slightly) better description on the wiki User Interface notes :) That version is only 8 steps wide, as there is not sufficient processing power to drive the matrix with a single core while keeping decent timing. Another reason for the design being modular so I can shift different jobs to different cores... But the question remains... Which way do the buttons go? 16x12 or 12x16?

Good luck dude. I'd take a set of decks and some records with me just in case ;)

That image looks fine to me, but youtube was not so good. Noone else has complained, it's probably this old screen. That's really small! It must be a custom PCB I guess? Anyway congratulations on these, it's a subject that is often discussed but I think you might be first to get it to work :)

Hey dudes, I'm currently designing a grid editor for the vX, and I just can't decide if it should have a horizontal pitch grid like so: Or vertical like so: (there may be more or less steps or pitches, this is just to illustrate) So what do you prefer, and if you don't mind letting me know, why? Don't just say which you are accustomed to, tell me which you think is best :) Thanks!! :D

I had a feeling that was it, but I didn't have the confidence to say it heheheh Hey jeb what are you putting in this array? There might be a quick way, depending on what is going in there...

Holy crapamoly! Great stuff. That controller on your site is pretty mean too!