stryd_one

The idea I was thinking of would be to make the driver transparent to the system, so the application would not have any difference in addressing a 4x40 or 2x 2x20. Basically it would take a 2x40's addressing, which would be out of range, and shift the addressing to be within range of a 2x20, and switch the enable lines, before sending the data. This shouldn't be a problem unless the seq is directly driving the display pins in it's code, although TK is obviously not planning on building support for optional displays into the firmware, so it may take some modifications for eg to seq_lcd.inc. Of course this is all an assumption and may be wrong, because v3 is still Top Secret :)

Wrapper header says: extern unsigned char MIOS_HLP_Dec2BCD(unsigned int value) __wparam; According to SDCCMan it should behave like this: void func_wparam(int a) wparam { /* WREG hold the lower part of a */ /* the high part of a is stored in FSR2+2 (or +3 for large stack model) */ ... } But it seems from TK's wrapper it puts the high byte in FSR0L.. I'm not clear on that, maybe TK can clear it up for us? Wrapper ASM says: global _MIOS_HLP_Dec2BCD movwf MIOS_PARAMETER1 //Moves W (the low byte of the 16-bit integer) into MIOS_PARAMETER1 - That ain't right. See below from the MIOS Function Reference movff FSR0L, FSR2L //These guys movf PREINC2, W //Put the high byte in W. D'oh! goto MIOS_HLP_Dec2BCD As the Function Reference show's, htat's bcakrawds...;D MIOS_HLP_Dec2BCD FUNCTION MIOS_HLP_Dec2BCD DESCRIPTION converts a 16-bit decimal value to BCD IN low-byte in WREG high-byte in MIOS_PARAMETER1 May I recommend changing the wrapper code to: global _MIOS_HLP_Dec2BCD //The low byte is already in W movff FSR0L, FSR2L //These guys movf PREINC2, MIOS_PARAMETER1 //Put the high byte in MIOS_PARAMETER1. Yay! goto MIOS_HLP_Dec2BCD Oh yeh and I was misinformed, SDCC does treat int's as 16-bit :)

I was gonna do an app from the skeleton too... I haven't looked at the wrapper asm yet, I'll do that now before bed. I forgot that you were away from home, don't worry about that test, let me take a look at the code...

Heh I didn't know about that thing. Neat idea. Lame that he patented it. I'm getting so tired of people patenting new ways of implementing old ideas, and effectively attempting to block the growth of those concepts beyond their own implementation. Grr... This dude loves to throw around the words 'patented' and 'unique'. Good thing that this forum proves I had the idea before him... Shame about all the others that had the idea before I did and got no credit either. This is one of the concepts which the vX was designed to handle (sequencing by intervals). There are actually several ways you could do it, check out the wiki page and have a ponder about it :) While the vX can be a manually triggered relative sequencer, a relative controller (which is similar but different) would be a great tool and they'd go together sooo well. I'd certainly be interested in making one. The tricky part is the scale engine, everything else is a snap. You just need an algorithm to process the last midi note output by an interval and scale to find the next midi note. You could use math or tables or a combination... Have you given this much thought? Share your ideas, let's do this thing..... PS Has anyone patented the fart yet?

lmao ;D You should see how long the reply to that post has grown!

Oh - I should make it clear that I've currently not got a core to test this on, which is why I keep asking you to do stuff for me ;) I hope your SDCC version is OK, or I will have to downgrade from 2.5.6 heheheh

Thought I should mention these words from TK: Can you try it with 2.5.0 so we can be sure it isn't your version causing the problems?

I'm on that BCD thing for you before tomorrow night buddy. Sorry I started on it and kinda got distracted with large arrays and 4620's RAM heheh. I've had your post open in IE ever since you posted it though ::) I'm nuts... Useless trivia: When your post count is 1337, it says "Posts: leet" on the sidebar of the forum hehehehe

Hey AC, you are using SDCC 2.5.0 right?

Oh I realise that you're not making any profit... It's just that when a SB card costs $1 and new would cost $40.... Too big a difference to warrant the advantages I think :(

Bunsen ya sniper! ;)

Hey OG I didn't know you were an Aussie! I would be interested but those prices are a bit steep :(

The latest. I think it's R4C?

I'm glad it's not just me then :) Honestly I wonder why this hasn't been suggested earlier... As you say, 4x20's are expensive or junk but rarely cheap and nice looking... I thought I would make this post and heaps of people would come back and say "great idea!!"......Guess not ;) Well, it might be some time before I have the hardware built up to a stage where I can test this, but if you want to do it, then I will write the driver for you, if you are willing to do the testing for me...

I think there's a good argument for and against adding the file to the skeleton... Using that library can increase your code size - although it should only add in the parts that are needed by your code, so if you include the library, but don't use it, it should make no difference to the final code size. Personally I would almost always use the lib so I think it would be best included in the skeleton. Of course that means making alterations to the linker. I have some other suggestions for improvement to the linker script specifically for C projects, so I will suggest both of these when I discuss that.

How about MIDIBox with an AOUT? You could generates some craaazzzy envelopes.....

So it's decimal for addressing, and hex for data. It is strange!

Why isn't Cakewalk Sonar on the list? It's the biggest selling sequencer in the USA... Edit: Probably because this is the German forum! D'oh! Sorry guys ;D

Thanks again TK :) For everyone else, I will present full documentation on using the 4620 in your projects shortly. This will relate to both C and ASM projects (but mostly C) and I will also document the procedure for allocating blocks of RAM larger than 256bits.

Thanks TK, I think I might do this when the hardware is all ready :)

Thanks TK :) I suspected this. Will we need to make new pic18f4620.h and pic18f4620.c files or will the existing 452 files also be OK? In the linker, am I correct in assuming that locations 0x600 to 0xF7F are available? I can document this procedure and how to allocate RAM for large arrays once I know these things, thanks!

Hi all, I noticed in the SDCC manual, that there is no mention of the 4620 as a supported device :( 18F242 18F248 18F252 18F258 18F442 18F448 18F452 18F458 18F1220 18F2220 18F2550 18F4331 18F4455 18F6520 18F6620 18F6680 18F6720 18F8520 18F8620 18F8680 18F8720 Does anyone know if we can get around this?

The maximum resolution will be limted to what the controller can handle, but I'm not sure of the resolution limitations for each chipset... It should be in the datasheets of course :)

HD61202 and T6963C can be used, as well as matrix orbital via IIC, or you can write a custom driver. Hope this helps.

Hi guys... I'm not sure about where you guys live, but I'm finding that 2x40 LCD's are not nearly as widely available and that 2x20's are cheaper, more popular, and so there are more different types available (like the PLED displays wilba posted). eBay is a good example - 2x16, 2x20 and 4x20 LCDs are cheap and widespread and varied... But 2x40's are slim pickings. It should be possible to alter the driver and use the core J5 pins on the LCD WE lines, so that we could use 4 2x20 LCD's in place of 2 2x40's. Does anyone have any thoughts on this? Maybe for SEQv3?