i45one

Man you aren't kidding. From the pic, it appears as if the holes are as wide as the encoder shell..... Oh my. Not good. But I don't think I am willing to wait for another re-work. Was the first run like that? Surely we would have caught that the 1st time...

;D actually, it was approximately 30 million ;D I think it's still in the book of world records!

Just be careful. 8550's dont work in breadbox C64's. Only a later version 64C or 128. Otherwise you'll cook the thing.

If you are using pre-made PCB's, then solder flowing through the top surface is normal. As for that 40 watt iron, that is a bit hefty for board work. If you are very careful, it will work. But you have to be super careful not to overheat the joint, as doing so will lift PCB pads and possibly damage the component. Good luck :-)

Thanks again wilba! I am looking forward to making this thing scream.

I was wondering where everyone is getting their encoders for this project. I see on Wilba's link to the data sheet that the shaft length is 25mm. The only encoders I can find that are even close have a shaft length of 20mm. The encoders I am referring to can be found here: http://www.mouser.com/search/ProductDetail.aspx?R=318-ENC160F-24Pvirtualkey14860000virtualkey318-ENC160F-24P Any thoughts or suggestions? I have ordered the Waldorf knobs and want to make sure everything fits properly. Thanks

Problem solved :) What I did to fix the problem was to add a call to MIOS_LCD_Init after the 4 bit code and recompile. The copyright now uses both lines, where before it was only on the top... Heres the segment of code: ;; use a CLCD, E input of first CLCD at D.7, E of second CLCD @C.4 ;; using the 4-bit interface: ;; -> connect MBHP_CORE:J15:D7-D4 of the core module to D7-D4 of the LCD ;; -> left MBHP_CORE:J15:D3-D0 of the core module open! ;; -> tie D3-D0 of the LCD to ground movlw 0x37 | 0x80 ; E1: D.7, 4bit interface movwf MIOS_PARAMETER1 movlw 0x24 | 0x80 ; E2: C.4, 4bit interface movwf MIOS_PARAMETER2 movlw MIOS_LCD_TYPE_CLCD ; LCD type 0 call MIOS_LCD_TypeSet call MIOS_LCD_Init

Here is some y position data... Not sure if it matters though. With the display working, MIOS_LCD_YAddressGet replies with: WREG: 54 MIOS_PARAM1: 00 MIOS_PARAM2: 40 MIOS_PARAM3: 14 Done With the display jumbled it replies: WREG: 54 MIOS_PARAM1: 00 MIOS_PARAM2: 04 MIOS_PARAM3: 14 Done

I don't have the datasheet for this exact module, I do have the pinout though. I also know that it contains a few OKI M5839B's and a Sanyo LC7985NA which is HD44780 compatible. I'm not the only person who has seen this issue with this BG Micro display. Unfortunatly the board is wired strictly for 4 bit, the traces to the other 4 bits on the processor are non existant. If there were actual traces to these pins I would try hardwiring them. And yes, all is well until either a power down or a MIOS_Reset command. I'm begining to wonder if this display takes an odd command set or something. This is my first go at anything like this, so I'm kinda shooting in the wind. As far as the WIKI goes, all I can find is info on how to recompile an app to work in 4 bit mode, which I have already done. Also, the pinout shows R/W tied directly to ground. When I tie R/W to ground I get the normal black bars. I can tell it is doing something because it turns on the 2nd line of black bars after a few seconda. With R/W tied to the core, I get the strange 1 line problem.

Update #2: In tinkering around with this thing, I found that if I send a MIOS_LCD_Init then send a LCD message at the current cursor position, the display magically displays properly... This whole LCD thing is new to me and im kinda clueless as to what is going on.... But in guessing, I would say that the lines arent addressing properly. Everything is getting dumped on the 1st line... Keep in mind I don't actually have a control surface setup on this thing yet. I'm not sure if something is floating that needs to be tied to ground... One step closer to the madness...

Unfortunatly, no... It is configured for a 20x2, and the display is a 20x2 I even tried to set it as a 16x2 to see what happened... pretty much the same thing #define CS_MENU_DISPLAYED_ITEMS 5 is set in main.asm... That was my first thought as well. It's somewhat odd, when the unit is powered on, the copyright comes up on the top line. then something else shows really quickly, temp something, then the messed up patch kinda comes in on top of it It seems as if the display isn't clearing itself properly Update: I installed the benchmark app... It gives the mios copyright, then I get: ABCD 3###JKLMNOP0 ns The number signs denote changing numeric values, and the 0 is a zero and not the letter O

I finally got a display to work with my core module... The display shows the copyright information fine, but when it displays a patch name it is incomplete... This is what I get on the screen: A 1Inte 1al1---CH This is a 4 bit display, which i didn't realize until i recieved it. The sid app has been recompiled to compensate for this. Anything else to concider, or check?

Ok, I'm kinda new to burning pics so I hope someone can give me a little information on what I should see after burning the pic. I successfully got the programmer built with no problems, and brocolli acted as if everything was fine. I erased the pic twice before burning. (hint on avoiding the "run it till it works" thing... what I found to work best was to apply 3.3v 1st then apply the 9v for hvp... worked every time!) Here is what i get from readconfig: Configuration bits: 00 26 03 0f 00 01 81 00 0f c0 0f e0 0f 40 PID Bytes: 00 00 00 00 00 00 00 00 I burned the bootloader_v1_2_pic18f452.hex image. My only concern is when i run readdata, everything is all ff's. Im not sure if this is right. Since I don't have my core board yet, I can't try anything else really to verify the burn... Any suggestions?