moogah

Oh Geez. Array failure... this makes me nervous to go to work tommorow... Thanks for the work TwinX! :)

OOOOOOOH :D This sounds like fun! As for the simplest solution I would just tap the input to the AIN with a transistor and resistor buffer to drive the LED. Simple, and is likely to work in most situations. However, this idea of using stereo pots and multicolor LED's is some good stuff! Without having a datasheet in front of me I would try to wire it up so that both sides of the LED get juice normally, and turing the pot from side to side shorts one end of the LED or the other. Add in a limiting resistor here and there and I think that would work without the need for buffers.

LOL. 4 Days will get a toe or two wet. 4 months and you will have gotten a good introduction to MIOS and the really stunning depth of TK's applications :) Where to start? 1.) Read 2.) Read it again 3.) Draw conclusions 4.) Test these conclusions 5.) Post results and questions 6.) Repeat steps 1-5 :) Sounds like an interesting idea, actually. Alot of you have projects I'd love to see in person, and something along the lines of the SDIY annual meetings would be a cool idea for us MIDIBoxers too!

Hmm. Those error messages are frustrating, but I'm no surprised by them. First I would take the time to not get frustrated by this, clear you head and work on some other things for awhile and then come back to this.. and start right from the beginning. I would want to know, 110% sure that the core is assembled correctly and the MIDI connections are correct. I've almost never had an issue with a bad IC myself, but if you have another optocoupler to swap with, go ahead. In MIOS studio are you using the "wait for upload request" option? It is possible you are just having trouble starting the upload in time. I use the wait feature and it's worked well for me. The strangeness with the LCD's isn't encouraging, but it wouldn't lead me to believe that you've caused any serious problems with the PIC. I've got 6 PIC's which I've really put through all sorts of hell. All of them still work. Also, there were more than a couple times where I had successfully uploaded MIOS and thought something had gone wrong because the LCD was all messed up. Each time it was a combination of not having enough juice going to the LCD (check that the output of the regulator is nice and stable with the LCD connected) and/or having the brightness/contrast setting in a bad position. I've found there to be a pretty narrow range of brightness/contrast that presents a readable screen. In your case this is something to think about next, I don't think you've gotten MIOS onto the PIC yet.

Perhaps this has already been resolved.. Can you specify your entire upload setup? What kind of PIC are you using? Where did you get it? Was it preloaded with MIOS? (I believe both Mike and Smash sell preloaded PIC's only) What program are you using to upload? Can you specify "update_without_installed_mios.hex" I don't recall a file with that name.

;) It's cool, I answer this question alot :) I think it would help if I could decide on using: Inspiried by "Sebastian's" clone, "MICROlarge's" clone or "Hallucinogen's" clone. Of course, all of which are the same person :)

Wow. Watching that clip again (and again) I'm really hooked on how the interface works. Really smooth design!

UUUUHHHH. TK? Thats the Nuttiest thing I have ever seen! I don't even know what is going on in that video! I just know I Really Really Really want one! ;D ;D ;D ;D

And finally! I won't recount how many extra steps were involved in getting this into an .mp3, lets just say I can't find my licence for cubase and I spent some time splicing audio in soundforge to remove artifacts from my laptops soundcard >:( More and better sound clips to come ;D SpiritIsWilling.mp3

Between work and school work has slowed down on the 808 quite a bit. I did get a few hours of work done yesterday tho. Depending on how late class goes tonight I think I can finally get some .mp3 samples out so people can hear what it sounds like. The case is coming along, Mr. Lowell has done a very good job in emulating the original look and feel of the 808 ;D

I've almost never found a dead IC in a year of working with this stuff, I always suspect some mistake I made first. I would suggest starting right from the beginning today, see if you can find some detail that doesn't seem related at the moment. Assume that everything you did is wrong and read the schematics and layouts again. Often that is where I go "AHA!". If not, you can get a rough test on your power line with a meter, check that the DC voltage before the regulator is 7-10v and the output is a nice steady 5v. If you've got that then go ahead and check the power pins on the AIN module to be sure something isn't getting messed up there. I don't know about any specific issue with a DC wallwart causing trouble, search the forums on that one. I would carefully double and triple check that the way you did this is correct, it at least could cause your problem. I say this assuming that you mean that most the activity is coming from pots 15 & 16, and IIRC they are assigned to the second 4051. The schematic shows how to do it, I assume you did it the same way?

Hey, I'm too busy with work and school this week to have taken a serious look into what your doing to offer insight, but, it looks like you've got the right idea and know how to find the relavant documents to help you along, keep studying and keep trying (and erroring) new things and I'm sure you'll do fine ;D

MIOS_DOUT_PinSet1(stored_pin) In this case you are passing the function "MIOS_DOUT_PinSet1" the variable "stored_pin" which you symbolize by putting the variable in parantheses right after the function: MIOS_DOUT_PinSet1(stored_pin) notice that there is no space between the function name and the variable in parantheses. Unless there is some other detail with the SDCC this is the correct way. I'll need to take a closer look.

Yes, that is definatly correct :-[ Java has ruined me ;) I'm still not seeing why were keeping stored_pin in parantheses... reason?

Ahh. I'm rusty ;D I see some problems now: "==" is the equality operator, use that to check wheather two variables are the same: if(x==y) "=" is the assignment operator, use this to assign a value to a variable: x=1 Or: x=y Those parantheses are not needed either, try this: void SetLed_NoDump(unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin, unsigned char pin) { unsigned int i; if(pin == stored_pin ) stored_pin = canc_pin; else stored_pin = pin; for (i=low_pin; i<= high_pin; i++) MIOS_DOUT_PinSet0(i); if (stored_pin != canc_pin) MIOS_DOUT_PinSet1 (stored_pin); return; } Without getting out pen and paper to check your logic seems to be correct. One last thing: you are using "i" as a counter variable (i for integer), but you are declaring it as a character. While this may still work, you should use the type "int" here. Since you know you don't need to count negative numbers the "unsigned int" is slightly more efficient.

Can you provide some more details about what this code is supposed to do and what (if anything) the function actually ends up doing? I'm pretty good with C, but I've not done any work with the C applications around here yet. Error messages from the compiler? if(pin == (stored_pin) ) why do you have stored_pin in parantheses? It prolly won't affect the program at all, but this shouldn't be needed.

I don't have any specific information about the PIC Burner module, but looking at the schematic I would want to know if pin 1 and 6 of the 74hc14 shows a clock signal.

Ahh yes! I didn't recognize you at first. I would do as you say, get a roll of both. AC has a good point too tho, a good way to save some cash!

The kits do not include the cable. Which one you need depends on the module, and your preference. Which modules are you getting?

Yes. People take note of this: USE A TOOL TO CHANGE YOUR TIP! The weller has a nice easy screw on sleve for securing the tip which makes it rather easy to forget about how hot it is. I've nearly grabbed it on several occasions... :o

I'll second that. I use a 1/64" conical for most work and I've also got a 1/16" flat top for making cables.

Yea, I bought one from Radio Shack some time ago. The tip is huge, which is the first problem. It does heat up and cool down just like they say it does, and could probably be nice for a portable repair tool (it would do jacks and cables nicely). However, the tips are very easily breakable, it didn't take me an hour of foolin' with it to break mine.

Indeed you can :) Yea, 220R of resistance makes for nice photon lights, but really is a bit hard to look at ;D

Best thing to do is not worry about the candel rating and just use a bigger resistor to limit the current. This increases the life of the LED as well. It can vary quite a bit from LED to LED but I find between 1k and 10k usually gets a nice comfortable level from ultrabrights. Also note that staring into ultrabrights can be as harmful to your vision as a laser pointer in some situations, if diffused ones were commonly available I would reccomend that the clears be avoided.

Hey! Glad to see you decided on using midibox for this project! This is what you will need from Smash (this is found in the "hardware costs" header of the SEQ design page): 1 Core 3 DIN's 1 DOUT 1-2 Banksticks 17 Encoders Last I checked his site he did not have any of the DAC modules available, so you will have to etch them yourself of use protoboard. There are two DAC's to choose from, the AOUT and AOUT_LC. The AOUT requires samples from microchip and a bit of luck from mouser to get the S&H chips needed. The AOUT_LC is an R2R version that is much simpler and most likely sufficient.