philetaylor

Ah. It looks like the C header may be incorrect. Unless I am being stupid (entirely possible) then I think that the following lines in j5_io.h: extern void J5_IO_Get(void) __wparam; extern void J5_IO_PinGet(unsigned char pin) __wparam; Should be: extern unsigned char J5_IO_Get(void) __wparam; extern unsigned char J5_IO_PinGet(unsigned char pin) __wparam; Looking at the assembler source for those two function, the W register contains the result so 'I think' this would fix it. Try this and if it works I will commit it to svn. Cheers Phil

Sorry S1, I thought you were nILS ;) ;)

The unfortunate thing from looking at his website is he could probably have been an asset to the MB community but my god what an attitude...... Every time I saw a post with those big blue boxes I guessed that another scrap was about to start! Phil

I would use the Tick() function, it should get called regularly enough to make sure that button presses aren't missed. Cheers Phil

Sorry I missed that bit :) Somebody will correct me if i'm wrong but I 'think' that you will need to call J5_IO_PinGet() (or J5_IO_Get()) and then compare the result with the result of the previous call to see if anything has changed. I would think that it will need polling fairly frequently..... Cheers Phil

Yes that is what it is doing, it is tied high by default through the resistor. Cheers Phil

Hi. I have been doing a lot of research recently into getting a small tabletop 'hobby' CNC milling machine. The prices seem to be very variable (from about £1000 to 'id better sell the car and re-mortgage the house :) '). I guess that the quality is similarly variable?? One thing that peaked my interest though was the use of CNC milling machines for PCB protytyping. I like the thought of no more messy chemicals and light boxes. Obviously though, with something like this the accuracy of the unit becomes critical so I thought that I would ask if anyone has any experience of this if so what machine they used? It does seem that every machine that I find on the Internet for around £1000 mark have some really terrible reviews mainly with accuracy and build quality so I would be really interested to hear anyones experiences. Many of the 'good' units seem to be in the £5000 bracket which I really can't afford but I would happilly purchase a kit (as long as it has all parts as I have no machine to do any fabrication!) Cheers Phil

Julien. Having read most of your posts, you seem to ask lots of questions that are answered in many forum posts, in the wiki http://wiki.midibox.org/ and on ucapps.de http://www.ucapps.de People here are very happy to help people that at least attempt to help themselves and responding with comments like "I'll find my way alone don't worry " and "I'm disappointed " when people try to give you constructive answers to your questions will only alienate you from everybody else on this forum and people will just ignore you (or stryd_one who you have already had a run-in with will ban you). I accept that there may be cultural or language differences but don't forget we all do this as a hobby, NONE of us makes any money out of making midiboxen so we don't HAVE to help you. If you try to help yourself and DO SOME RESEARCH before asking questions and are polite if you don't get the answer that you wanted then people will be much more inclined to help you further. Cheers Phil

I didn't realise he also puts MIOS on them so ignore my comment :) If you are sure the wiring is correct, it is worth hooking-up MIDI connections to MIOS Studio to check that you are getting an upload request from the core as this proves that the core is booting... Phil

MIOS_Delay is what you are looking for (delay is in mS) Cheers Phil

Hi Achra. Welcome aboard! Well there are no indications from your message that you have done anything wrong :) IIRC, SmashTV programs the MIOS bootloader onto the PIC but not MIOS itself so there is no software to initialize the LCD (a row of blocks means it is powered but hasn't been initialized). This is the point where you will need to hook-up MIDI to it, fire up MIOSStudio and download MIOS to the core. Once MIOS is on the core and booted, you should see "READY" on the LCD, you can then download any of the available apps to it. Cheers Phil

They are not really de-bounced themselves, generally the better quality the contact (and often more expensive), the less bounce they cause. Relays (and some switches) can have mercury whetted contacts which make the contacts more 'sticky' and stop contact bounce almost completely. Either way it doesn't really matter as the MIOS function MIOS_SRIO_DebounceSet allows you to configure how much de-bounce to apply in software. Cheers Phil

Sorry that's what I meant, you are quite correct it is in setup_midibox64.asm!!! I was just checking that you had compiled your own app and were not just using the downloaded version unchanged :) Sorry but I have never used unmuxed analogue inputs on my midibox projects so I can't really offer any suggestions other than the things you have already tried, i'm sure somebody else will chime in though :) Phil

Until somebody better informed replies, it occurs to me that the default MB64 config uses muxed analogue in's (via AIN modules). Have you compiled your own version of MB64 and replaced: #define DEFAULT_MUX_ENABLED 1 with #define DEFAULT_MUX_ENABLED 0 in main.inc?

I know they're not that bad, I was just being picky :) I still use my temp controlled Weller soldering station that I got when I was at college a looong time ago :) still works perfectly and has outlasted many many cheaper irons... Phil

Thats great, isn't it a wonderful feeling when it finally works ? 8) The only problem with these things is I tend to get more satisfaction out of getting individual bits of a project working than I do actually finishing the project as a whole, this probably explains why I have so many bits of unfinished projects lying around :) Phil

Right, I will try to describe what this section of the USER_LCD_Clear function does. First it clears the GCURSOR_Y this is the beginning of the Outer loop then it clears the GCURSOR_X register and it sends a command to the display (0x24) to set the set the display address pointer to X=0 and Y=0. Then you have the InnerLoop where it sends 0x0 to to the display followed by a command 0xc0 which tells the display to write the data at the current cursor position. It then increments the graphic cursor X. the first BRA_IFCLR then checks the X cursor and if bit 5 is not set (X is less than 32) then it loops. Once X=32, it increments Y and checks that it is less than 64, if so it goes back to Outer loop and starts again. If not it sets the cursor back to 0/0 and returns. As the second parameter of BRA_IFCLR is a bit then it cannot be larger than 7 which could explain why the box was getting smaller if you increased it too much. I would try changing the second one from 6 to 7 as this checks that it is lower than 128.... Cheers Phil

Hi. All of your versions look OK. I am using a newer version of SDCC but that shouldn't matter as you are not even getting to that bit :) The only thing I did notice is that I believe that quotes are not necessary within path statements as semicolons are used as seperators so the quotes could be causing something strange? Try removing them and see what happens.... Cheers Phil

Looking good.... Still a few solder blobs that I would be tempted to reapply heat to though :) I always use a craft (stanley) knife for cutting both SIL and DIL headers, I find that normal wire cutters tend to snap them (as you found out). I just place them on a hard surface and cut down. You can also then use the knife to tidy up the cut if you really want it to look neat! Phil

Wow I just did check ebay, $149.94 for an 8-bit ISA soundcard ??? http://cgi.ebay.co.uk/IBM-PC-XT-8-bit-ISA-Sound-Card-SoundBlaster-SuperSound_W0QQitemZ130218671771QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item130218671771 Phil

No problem, if you can describe the problem you are having with the toolchain, i'm sure we can help you with it :) Phil

Hi Jack. That would give you a pretty big display, about 150x6 with the standard font :-) The 'actual' window size is about 34mm, 48.26 is the external dimension but still pretty big! Not sure if it would fit though and as TK said you would have to redo all of the UI... Phil

Yes I thought about this as well. If you put 3 x DOG CLCD's together, the viewable would be approx 165x15mm. For this you will get a 48x3 display. The viewable area is fairly close to a 40x2 size CLCD viewable area (152.5x16.5) I don't know how big the slots on Wilba's panel are but it could possibly be made to work. I'm not sure how workable it would be and whether 48x3 is a usable size. The current SPI based DOG CLCD driver (that I have just committed) would support up to 8 of them so 6 could replace the 2 off 40x2 displays.... Cheers Phil

After looking again at your picture, I think that it should work 'as is'. The only thing that isn't happening is that the whole screen isn't being cleared. What makes me think that is the word "Klose" at the top of the second half of the display. This means that the driver will print to the other half as it is the last bit of the 'splash screen! Therefore you need to concentrate on the USER_LCD_Clear function, take a copy of app_lcd.inc and have a play. You could try increasing the number of times that it loops (there are two loops, inner and outer which are controlled by the lines BRA_IFCLR) Cheers Phil

That's great news! I guessed that it would be something like that! Not sure if v1.2 is too old for these glcd's as it pre-dates my involvement with Midibox but I would definately try upgrading it to 1.9f. I will take another look at the driver tonight, basically what you need to do is to increase the graphic box size. When you initialize the display, you set a graphic box and a text box. As MIOS doesn't support the text mode, the whole display needs initializing as graphic. Cheers Phil