MRE

http://www.allegro.pl/item165150697_adapter_plcc_32_dip_32_profesjonalne.html There it is... Ok, so in the case of a PLCC package, its actually not a problem at all to mount. PLCC packages are usually available in thru-hole styles (In fact I dont remember ever seeing a surface mount PLCC socket), so absolutely no problem using PLCC packages in MidiBox cores there. The biggest fault of PLCC packages is the single/low quantity cost for sockets is rather high. Couple that with the fact that there are very few PLCC package PIC chips that are not also available in DIP packages and thus PLCC is just not a contender for home hobby jobs. That adaptor by the way is really more for breadboarding. Easy prototyping on DIP row socket boards and such. On a printed PCB however, the PLCC socket is a breeze to solder in. What chips were you wanting to be using?

Moving to PLCC/SMT type package is more about conserving space than more power. The current chips being used in MB is quite capable for current and most future designs, so 'more power' is not an issue for +90% of the MB projects out there. PLCC or SMT packages on the board require ICSP connectors for programming, and that, more than anything else is what keeps MB using DIP packs. Soldering SMT is really not too difficult with home hobby gear. A good tutorial would put everyone in the loop. However, those without PIC burners would need to build their core, then return it to someone for PIC burning, then have it shipped back to them. An unmounted SMT can not be coded. Putting the chip on an adaptor certainly solves the problem, but causes new ones in that someone must mount them all before burning them. Not to mention, the whole point of SMT is to SAVE space, not to use even more than space. There is nothing to stop you from using the faster/higher ram SMT/PLCC PIC parts in your own board. The thing is, if you REALLY need that extra ram/speed/etc... then you are likely designing your own PCBs from scratch anyway, and might as well mount your PIC directly. As a PS, the linkie is broken anyway :/

I admit I didnt read that all the way through, but it was very ENTERTAINING! Good luck with the padded walls simone, they are comming to take you away! ;) Thanks for documenting your progress for everyone else.

ultimately the choice is yours, some general guides: Pots are great for mixing sectios for volume, high, mid, low, cutoff, cross fade, headphone send, etc. These are things that dont change much, and often you want them to 'stay put' between power cycles/gigs/mixing sessons. Encoders are generally better for instruments, sequencers, performance gear. Etc. From song to song, much of their duty is relative. Again, some values you want to 'stay put' though, like the final output volume control of an instrument. It looks to me like you are building a mixing console, and thus most of those pots can stay right where they are. If you plan on using some special effects plugins, you might want to change THOSE knobs to encoders.

Kris: You do not need LED rings to use encoders. That was only one example (of visual feedback). Think of an encoder as a 'never ending pot' It will continue to spin. There are many advantages to encoders, and a few advantages to pots. as Lyle pointed out, an encoder can be dynamically altered by software without physically moving the dial. Let me make an example: Lets say you have a sequencer with a knob for note selection. As a pot the knob would act as follows: Pots are absolute, so 1: a predefined maximum limit on the number of notes it can represent. This is based on the physical properties of the pot, and the Analog to Digital converter attached between the pot and the micro-processor. For example, an ADC may only have a resolution of 256 steps. Thus 256 notes. Which, may be just fine for musical notes. EXCEPT: a) as pots degrade over time, they become harder to 'lock onto' the note you want. b) 256 steps on a one inch arc sweep might actually be a bit too fine for 'realistic' use. The truth about most analog game controllers is that while the knob may produce 256 steps of resolution (or 512), the game software cuts this down to two or three!!!! 2: When power is removed, the pot 'stays put' so it is preset to a certain value when power is re-applied. This can either be an advantage or disadvantage depending on how you work. Just remember that it will be preset and sending out note data at that position value untill you drop it back to zero. Is this knob a volume control? a note control? a filter setting? Every time you work with a song, you need to remember where everything goes. (there are many ways around the limitations of pots for use in a sequencer, but that is a different discussion. Pots can be made to continuously rotate, and on power-up the processor must 'remember' what pot value represents zero. For the sake of discussion this. [and for anyone who says: Thats not entirely true MRE ;) ] ) Encoders will behave as follows: They are relative, so they are directly opposite to pots! ;) an encoder's resolution is only limited by software (and thus under your full control via MIOS/host software! Yippiee!!). Each pulse is representative of one note (in our example). So, how far can your micro-processor count? How much knob turning do you want to do? There is no real limit here. Also, detented encoders give a nice solid click to let you know the note has changed, while non-detented give a smooth operation for volume or filter sweeps. Finally, encoders have no 'memory.' When power is re-applied, they are affectively at zero (unless your software remembers the setting.) This is actally very nice. For example: Loading a new song into your editor has a filter setting at 20 percent at the beginning of the track... then that associated knob is at 20 percent. For this reason, you will often see encoder knobs without a marker or pointer. It is all relative, and changes regularly. If you want to bump something up or down, you just turn the knob a little up or down. You dont have to ask "how much further can the knob go?" In most cases, encoders are best. However, immediately to mind Volume controls generally are better served by pots or sliders. Volume is absolute, with a diffinitive start and stop, and you almost always want it to represent 'true' setting, not relative. Case in point: It should not matter what the volume setting was saved into the song. When I power up for the first time with the slider all the way down, I dont want to hear anything comming out. Not a mistake my speakers can handle! ;)

hehe.. I COULD do that.. and spend.. like.. EFFORT on it! BAH! ;) Actually, it wasnt so much of a spacing thing as it was being lazy! Making the other picture would have been a column of things.. tedious.. and the wires on the sides would be loopy.. like ( bah.. too much work! :P

ohh well.. that would certainly be pretty easy to do. One at a time Import the circuits from eagle all onto one sheet and make the direct connections where the header pins would have gone. It WOULD exceed the free version size of Eagle, so you ould either need to purchase it or recreate from scratch in you prefered PCB app. You might want to consider a few changes. If you are comfy with SMT work then that would certainly reduce the size. I would suggest that you map all the connections to one or two IDE drive cables. One small SMT pcb with core, 3 DINS, 3 DOUTS, and 3 AINS would be pretty sweet kit actually (as much SMT as possible). This COULD be realized with the free Eagle as 3 or 4 seperate boards that are bussed with an IDE cable. Might be a fun project. See how many DINS you can fit on one 4 by 4... (contemplates Eagle fun...)

Likely that. They had some issues with the colors being dull and washy at first too. The hacker community quickly came up with the filter fix for that, so likely there is a fix for the sound? I dunno. I doubt you have direct access to the recreated sid chip lines either. They are buried somewhere down in the silicone. With Digital its pretty easy to replicate in an FPGA.. but the sid had some analog circuits inside, which cant be recreated.

"well THERES yer problem!!! Cant look for a strong Poker player when you actually want 'puter parts!!"

what amazes me is that the case is built from wood! The DTV is not actually an emulation. It is in fact, a full original (on the inside [of that silicone chip]) C64. All custom chips, the original CPU core, the SID, and the boot room are all built onto one chip. (FPGA?) So, many hacks are available that when all combined, restore all the original ports, their pins and functionality. You can even attach an original C= disk drive or C= printer! I think the only thing keeping you from using your original tape drive would be the analog support circuits. (the data pins are there!) A bit of of joystick jiggle on powerup boots to the usual C64 screen rather than loading the 'cartridge' file game burned into the chip. In fact, this 'feature' is only possible because of a ported flaw from the original hardware, where if you had a cart installed, and powered up, you could skip cart loading with the right combination of powertoggles/button presses/joystick wigglies.. I dont remember exactly how, but I did remember doing it once on a REAL C64 and that trash of a game moon lander.

Another option is to thread enamal wire through the holes of the pot tabs. It looks like bare wire but is coated with clear enamal paint. Take care to keep the wire from pot to pot short so that the slack wont short to to anything else. Now rub a part of the wire with a knife right where you want to solder to the pot tab and solder it in place. now you just need one new (normal) wire for each pot. Pots next to each other in a row: (arrange all tabs facing the same direction) It helps to bend one set of tabs slightly up, and one set of tabs slightly down, with the signal wire left in the middle. Thus, "high tabs" )all left tabs)= + and "low tabs" (all right tabs)= - and the signal wire helps to keep the two away from each other. [] [] [] [] --------o------------o---------o------------o -----s ----s ----s -----s ------------o------------o----------o------------o Pots in a column: With all tabs aligned the same direction, wire all the left tabs together and all the right tabs together. Make sure your design allows for space between the pot body and wire. If it does not, then wrap each pot body in electrical tape before building up, that way if a part of the enamal wire is bare and touching a pot, it wont short. I cant make a good ascii pic of this one :( An alternative to enamal wire is wire wrap wire. loop it through, then twist it twice. When you solder to the tab, you actually have to melt through the insulation, but it does work. (do it in a ventelated space! ;)

Well, I would say it is doable on a single side board. If all the circuit traces and circuit components were mounted on one side, with all knobs and buttons and such mounted on the 'blank' side of the board. (Pot circuit pads would be on the same side as the logic chips and reistor packs) Certainly, there would have to be some jumpers, and absolutely the components would all have to be SMT! Doable, but a HARD project. I guess it depends on how many pots/leds/encoders/buttons etc. you need. One possible way to do it would be to have all main electronics on one smaller dual side SMT board and all IO (direct wires to controls) going to a 2 x 40 connector like for an IDE drive (I have built a few projects where I used IDE drive cables.. one had 29 buttons). Would certainly be beyond the scope of the free version of Eagle.

Yeah.. In THEORY, TTL vt is 1.5 volts, with reliable Input High detection anywhere above 2 volts. 1.5 - 2 is sort of a gray zone, but chips generally switch close to 1.5 But, at 3 volts, you dont have much room if you experiance any voltage sag. So, if you can manage to get your key voltages closer to 5, then you are less likely to experiance missed keys on chords or something (just a guess here). But hey, if it all works fine at 3, then there is no need to worry.. 3 volts is fine as far as TTL is concerned.

to just drive A/DINs, you wouldnt even need shielded cable for at least.. 50 to 100 feet. There is some voltage drop to think about, but thats not really an issue below 20 feet or so.. more than enough for your project. An idea might be to mount an Ethernet jack on the back or side of the guitar, and on your midibox. This would give you 8 conductors for controls. Which would mean 6 switches, or 6 buttons, or 6 pots, or some combination. Make one conductor Positive 5 volts, one conductor ground (both 'sent' from the core box), and that leaves you 6 conductors to work with. I would advise that your positive and ground are the two wires normally associated with crossover cables. That way, if you AXEdentally (pun pun :) plug in a cross over, nothing will be damaged, your buttons, switches, and pots will just behave opposite of normal. Arcade games use Pots on the end of phone cords of up to 20 feet with no ill effects. You do have to take care of your cords though.

true true!

the 18F is bit diffent, but if you want some good reading, check out the 16F84/877 manual (it actually covers most of the 16F series). You can get a lot done with that machine as well. Many original MBs are built on the 877. Technical documentation?! Hell.. 99% of the commercial products out there have less tech documentation than MidiBox.

the config paging I really dont know much about. You might have to "hard code" your patch names and settings. Im guessing once you have a working system, and are looking at code... you will have a few ideas, at which point tossing them out here will get a helpful answer.

As for the Micro-controller question: If you went with another pic, you'd it be starting from scratch with code. Not that other pics are unable to do what you want, but why work hard, when TK has done that for you? :) It might make more sense to mount the controller to the chair...or at last make it attachable/detachable. Reason being, all but the most basic of midibox setups take up some space. Fitting all to the guitar would be very difficult. (were you still thinking on that line, or am I mistaken?) Anyway, you COULD mount the switches and LEDs to the guitar and use a metroplexing arangement to get them onto a small cable (ethernet perhaps). Then have the core somewhere else.

To be honest, I breezed through everything t'll the question list.. 2 - is impossible to answer. You tell me. Get a stop watch and get coding. ;) 3 - ALWAYS ALWAYS start with a known good configuration and modify. 4 - LED rings are well documented in the main site, wiki, or by searching of the forum. When you have a built system, and a SPECIFIC code question.. someone here will have a SPECIFIC answer for you. 5 - Its YOUR midibox. Make it what you will. However, it is always wise to start small. Midibox is very scaleable and reconfigureable. So, build a core, a few ins and outs, and play around. When you feel its time to go the next step, just re-load new code. Start with a knob, a button, and an LED and know you can configure them anyway you want them. Then keep adding up.

By the way, the table system implemented in C and many of the other features TK built into the whole Midibox system are quite advanced for a PIC application. Remember, back in its humble days, the PIC was only ment to be an intelligent Peripheral Interface Chip! The 877 is the grown up version of that little processor in your computer keyboard. TK crams, maximizes, minimizes, and otherwise bludgens code into a pretty small space. It borders on immaculate conception. The tricks involved often defy 'conventional' thinking in ASM to streamline things. Commenting such work would still get the reader nowhere. You have to intuitively understand the processor core. You would not catch the fact that he may be using a strange carry flag behavior caused only by a certain circumstance in order to save 3 instruction cycles. Us NORMAL guys just cant think that way. ;)

Having not dug into the include files myself, I can only offer a limited opinions: Midibox gets developed rather quickly. Being that it is an 'open source' project increases this development speed, and puts more 'hands in the pot.' TK is under no obligation to deep comment his code either. In fact, I think most would prefer he didnt, as time spent commenting is time wasted coding. Not to say that comments wouldnt be helpful. But ASM is a bear, and a lot of damage can be caused here. Anyone interested in coding ASM for the Midibox should have a strong grasp of asm in the first place. No point making it your first attempt at ASM, you would only cause havoc in your pic. So my argument on ASM is that anyone who feels they have a good grasp of ASM (enough to wrangle new features out of MIOS) wont need a load of comments anyway, and could always ask TK for details when they get a bit lost. My argument for C on Midibox is roughly the same. You sould have a good grasp of C before attempting new features. Now, in the case of C, more comments would be better then less. Most of the 'user' and 'application' layer is done from the C portions of code, and is the area most people are likely to want to change something. Now, Im not saying that if you dont know C, you shouldnt have need to change something. A menu edit is a good example here. Bottom line with code (ASM or C): Excessive documentation would only slow development. If someone wants to side-project commenting the C source, that would be mighty usefull, but doesnt necessarily need to be TKs responsability. Most of your qestions boil down to (and I hate to sound mean here): RTFM and by that I dont mean the midbox/mios manuals. I mean 300 plus page datasheets at Microchip.com. Much of the questions/points you have addressed here are clearly layed out in that datasheet. ASM language - all your questions about MIOS ASM can be cleared up in the Microchip manual or with a direct Q to TK How Electronics get the signals in and out - well..umm.. as far as the ASM side, its in the manual. As far as the actual electronics within the chip, and the limitations there of (example: how the ADC works for the AIN board).. you guessed it: In the manual. How the AIN board itself works.. Get a chip datasheet for the IC used on the board. Its pretty simple. If you cant wrap your head around it, you shouldn't be modifying Midibox too much. Ask a specific question and someone can easilly walk you through it. CPU exposed and how ASM intructions work within the PIC: Absolutely read the Microchip manual. No one here can concisely explain that one. Its a 300 plus page manual. Midi protocol: Thats one that absolutely could be addressed here. A few links to the midi spec itself, with a few pages dedicated to how it all works in MIOS would be useful to SOME programmers. But, If you are getting this deep into Midibox though, you are likely talking to TK a lot anyway. 4 Harware parameters etc: not exactly sure I understand you here, but I think your questions could be cleared up with a combination of.. drum roll please.. reading the Microchip manual, along side a comprehensive chart of the MIOS registers. So, good idea there. Where everything "sits" in the MIOS memory would be nice. A MIOS memory/IO map.. Anyone interested in starting that? 5 Software Program Cycle: Another nice thing to have. Not sure exactly how helpful it would be to anyone but an advanced MIOS asm programmer, but still... Only one who could concisely answer that would be TK. Likely he has several hand scribbled ones laying around from revision after revision.. if we were to be so lucky. I think what would more immediately be usefull is an index of functions, and their purpose in a nice handy chart.. Something like: Function | file name | purpose (taken from comments) | send and return values | example of modification CS_MENU_BUTTON_Sel1 | cs_benu_buttons.inc | select button #1, set cursor to 1st position |na| na - part of menu system

8bit processor core. some 16bit words (instructions) = faster

the beginings of a really good tutorial... hint

Takes a few tries sometimes to get the 8x2 connectors sorted out. And you say the data changes as you do things on the box? When it changes, does it stay stable or does it look like it resets back to that screen again? Is the MB otherwise in stable operation?

hmm.. well.. that got me thinking... You could mount all your units in one bus cage. The common bus could be tied to all Din, Dout, Ain and Aout cards. Then, using some sort of multi-position switch, only power the appropriate boards for the hardware you want to use.