Wilba

Your German is great, it's your English that isn't ;D These are the switches TK used on his MB-SID so they should work fine... I've used these before... well, I've used identical looking ones from ALPS... the SKHH series. You can make them fit in 100mil spaced holes... i.e. corners of 0.200 inch square, centred on a hole. I straighten the bend in the pin. If you're making this fit an exact panel hole, then perhaps solder them after you assemble panel to circuit board, so you can correct bad alignment. Cool idea! You can drive more than one LED, you can do it with two LEDs in series (DOUT->resistor->LED->LED->ground/DOUT)... but perhaps not that good for your situation as the second LED is on a different panel... perhaps have them in parallel: DOUT->+->resistor->LED->+->ground/DOUT | ^ | | +->resistor->LED->+ [/code] i.e. attach resistors to the common anode "rows" for each LED matrix, then just connect each LED matrix to the same DOUT pins (without resistors, direct to shift register pinouts). If you use bright LEDs, you won't have a problem with too much current draw, but if you want you can add some BC547 transistors on the current sinking DOUT... or even add a second 74HC595 connected in parallel! ;D

You might want to consider a LED matrix. One DOUTx2 can drive 64 LEDs, a DOUT for sinking 8 columns, a DOUT for outputting to 8 rows. Similarly, you can use a DOUT for sinking 8 columns and DOUTx12 for outputting to 96 rows... in this case you'll need a few transistors to sink the maximum current of 96 LEDs! When I say rows and columns I don't mean they have to be in horizontal rows and vertical columns, you can arrange them any way you like, you just connect the cathodes in "columns" and the anodes in "rows". Of course this means a little tweaking of the application code but I've helped others out with this kind of thing before... i.e. an 8x8 matrix of LEDs.

I haven't got around to a wiring diagram yet, sorry... you can look at the PCB layout and work it out ;D In the v1.74685 firmware, it will drive two SIDs at the same time, but the same data goes to both so there's no stereo effects (other than mismatched filter caps causing differences in cutoff freq.). So essentially it's no different to connecting two SID modules with the same cable. But if you're planning ahead for V2, then do the same thing, connect two SID modules with the same cable, except for the wire that connects to the CS pin on the SID (SID:J2:SO), for the right channel SID, connect Core:J14 instead. I've optimized it on my PCB as both SIDs are connected to the same pair of shift registers... if you use two SID modules, the shift registers on both are outputting the same data since they'll be connected to the same serial input ;D

Just to add my 2c... all my 6582 SIDs sold like hotcakes ;D but I'm trying to get hold of some more... a really BIG quantity, enough to fill a production run of the 8xSID PCB... (there's no point making 50 PCBs if there's not 400 SIDs to go with them, eh?) Stay tuned, I might have good news soon...

That diagram shows the wiring if you don't use a matrix. I meant I will soon publish a wiring diagram that does use the matrix.

Starting with the MB-SID v1.74685 release, you can put ALL the switches and LEDs in a matrix so that the full control surface only needs 5 DIN and 3 DOUT. 5 DIN = 4 DIN for all the encoders + 1 DIN for 8 "rows" of the switch matrix. 1 DOUT is the "column" selector of the switch matrix (and sinks a column of LEDs), the other 2 DOUT output the 16 "rows" of the LED matrix. If that's all too confusing, don't worry, it will be explained in more detail soon, with wiring diagrams (can't do that now sorry).

You can't measure DC voltage out of the rectifier, it's a series of humps! The rectifer just turns the sine waveform of AC current into "positive only"... imagine you just inverted the negative parts of the waveform. You can't measure it as AC voltage either. You need to put a capacitor after it to store the current between the peaks, and then measure that as DC (it will have a little ripple but that's OK). A 12v AC power supply should be able to supply a 7812 (after rectifier) with enough current so it outputs 12v at the current rating of the power supply (i.e. 500mA, 1000mA, etc).

If you mean does JDM work for 4682, probably yes, try it with PICPgm. Until I find a better place for it, (or TK puts it in the downloads section): http://www.midibox.org/dokuwiki/doku.php?id=pic18f4685_8bit_lcd_driver There's a complete lack of documentation ;D basically RE1 replaces RB2, (connect PIC pin 9 to D2 of J15), RE2 replaces RB3 ( connect PIC pin 8 to D3 of J15). This means you sacrifice two of eight analog input pins, but they're the 7th and 8th ones.

When I did something similar a long time ago, before I started using a C64 PSU, I recall I had a really wierd problem caused by the ground of the SID module not being the same ground as the Core. You have to pay attention that there is a bridge rectifier in the Core and also in the SID module (so each of those could take AC or DC power) and keep in mind that if you pass DC through another bridge rectifier, the ground is going to be 0.6v higher because it has to go through a diode. I would suggest you do the following (and I'm no expert, so do what you feel is right): * connect the SID module to the output of the bridge rectifier, and connect it to the input of the 7812 on the SID module (i.e. bypass the bridge rectifier on the SID module). * connect the Core module to the output of the 7809, and connect it to the input of the 7805 on the Core module (i.e. bypass the bridge rectifier on the Core module). This should mean the Core and SID will both have the same ground, and there's no need to connect ground between Core and SID module (and better you didn't), but you still need to connect 5v to the SID so connect it from the Core. The SID module's current draw on the 12v supply is very low, so there's plenty left over to power the Core... but check the current rating on the 12 AC PSU... if it's really big (i.e. 1 amp) then you'll have something like 16v DC going into the 7809 and may need to insert another 7812 before the 7809 to drop the voltage... you will probaby end up having some really hot regulators so just be aware of this and buy some heatsinks!!!

BTW, you can still use your JDM burner for the PIC18F4685! http://www.midibox.org/dokuwiki/doku.php?id=jdm_with_picpgm

My PLED display from OSD doesn't work properly in 4-bit mode, and MIOS detects this and disables the display (it looks like the display freezes but the app still runs normally). If anyone has similar problems, I can send my workaround... a custom LCD driver that uses two pins from port E as substitutes for the two pins being used for the CAN bus. So a little tip: only temporarily convert your Core->LCD cable connections to 4-bit. In 4-bit mode, you can (should?) leave D0-D4 pins on the LCD unconnected, so just desoldering those wires on the LCD is enough. If you have problems you can reconnect it as 8-bit... in other words, break the tracks to D2 and D3 on J15, connecting those pins to port E pins, keeping D0 and D1 connected to port B. Also the link to the diagram in the changelog is to a low-res gif, the better version is here: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf One final thing TK hasn't mentioned... this version supports all switches and LEDs in a common matrix... should you want to do the same hardware changes in your current hardware (i.e. only 5xDIN and 3xDOUT for the entire "step C" control surface!) then contact me and I'll give some advice.

I posted about costs in an earlier post: http://www.midibox.org/forum/index.php?topic=8389.msg62100#msg62100 It is obviously going to be a lot cheaper if you wait for a batch made by SmashTV... and if enough people really want a control surface identical to mine (and I don't think many would because it's a matter of personal taste, I went for minimalist white on black and really compact, others prefer more space and multi-colour artwork, etc.) then perhaps you can batch order the panels from Front Panel Express too and save heaps. I just don't want to release the layouts before I've done a revision and added the missing bits, taken out the redundant bits, and put in the bits TK suggested, i.e. the things I changed or took out because I didn't need them and was building it for me not for everyone ;D eg. the circuit for controlling LCD backlight brightness is not on my PCB as I use a PLED display. It's also easier for me to not spend a long time describe how I've "fixed" it to the new MB-SID V2 hardware changes, better that I spend that time fixing it on the layout and have less documentation and support issues (yes, I will be "supporting" this PCB and answering questions people have). I can't list many mistakes in this project, as there weren't many! Here's some advice: The #1 thing that helped this project was having so little free time to actually do stuff meant I spent a lot of time thinking about it, planning it in my head and allowing enough time to change my mind on how I was going to do things. It's not some skill I can easily transfer, the advice is not to rush things and then you won't end up ordering a PCB that's got mistakes or having the whole thing not fit together. The #2 thing was getting a cheap pair of calipers to measure components. You can trust datasheets most of the time, but sometimes you don't have datasheets... like how big to make a hole in a panel for the C64 power switch, and where to put the pads for the C64 power switch. The #3 thing is getting the components, especially the case, in your hands before you order PCBs to fit it, and making sure things will fit, with printouts of the PCBs. You can catch many mistakes that way, just by putting the printouts in the case to see how it will fit, or overlaying the front panel printout with the PCB printout (I caught misalinged switches that way!) OK, so there were a few mistakes: The height of the display was 10mm in the datasheet but was 11mm in reality. Not that big a difference except when you're fitting it in the 10mm gap between panel and PCB. That was easily fixed with a routed hole in the PCB, and I planned for that possibility too, if I needed a bit more space between the panel and the display's PCB (that's where the extra PCBs go with the select and SID buttons). Where the CS PCB and base PCB come close together at the bottom edge of the case, there's not enough space for SIL connectors (like on the bottom side of the PIC) and even the IDC connector is a tight fit, I had to remove the extra little bit of plastic (the bit the cable normally gets tucked under as stress relief). Since I only used those SIL headers for testing and uploading (it's the DIN/OUT port and Tx/Rx port) it wasn't a real mistake and I knew it was going to be a tight fit before I ordered the PCB. But in the next revision, I could probably move the 8x BankStick section up a bit and move all the Core sections up too and give more vertical room. I assumed I could neatly shorten one of those ALPS tactile switches and put them where they needed to be shorter in those extra PCBs above and below the display, but that didn't work out too well. Luckily they make them in just the right size to fit there too. I don't know if this counts as a "mistake", but while I really like this case, panel and the PCBs, it was a tight squeeze to make everything fit, especially the lack of room near the bottom of the case where the PCBs get close. It would have been easier to build it in a slightly bigger case, less challenging I suppose, but more accomodating if I needed more space between CS PCB and front panel, for example. And the final mistake (which I'm fixing now) is the LEDs I have are too bright, even when multiplexed in the switch/LED matrix (so all LEDs are only on 1/8th the time) with a 220R resistor on the DOUT outputs it's still way too bright, and I need to increase them to 2K or maybe even 3K-4K... that will make those transistors on the current sinking DOUT a bit redundant if I'm only sinking a max of 12mA through the current sinking shift register! The illuminated knobs were a bit of fun that I planned for (note the oversize holes in the panel) and while it works fine, I think they also are too bright, they'll be much better if they're white (so not confusing with the panel LEDs) and just a faint hint of light coming off them, just enough to give some contrast with the black of the knobs so they don't look like they're all black. I'll post the final pics when I've toned down the LEDs and swapped in some white LEDs under the knobs... still waiting on the white SMD LEDs >:(

It's certainly 100% working, with the PIC18F4685 version of the MB-SID v1 firmware and also with the MB-SID v2 alpha firmware ;D but as I said before, I will release the next revision of the PCB layout and people can do what they want... it will actually work out nicer as the space saved by removing the IIC MIDI modules will be used for a 12v and 9v supply and two power rails above the SIDs so people can mix and match 6581 and 8580/6582... my board only has a 9v supply as I don't have 6581 SIDs. Also there's the CAN bus wiring which I've added to my board but should be added to the PCB layout. All these little extras will mean anyone who uses it won't need to muck around with a lot of fixes, just solder the bits on and go. The CS is done too, and all works, but it's just not quite right... I think the LEDs are way too bright and perhaps too much blue, and I'm also going to change the knob illumination to use white LEDs (and very, very low brightness, just enough to make it visible but not so bright that the LEDs get lost). So the final pics of the finished box has to wait, sorry... I don't want to show off my mistakes! ;D

Yeah that makes sense... there's no C code that would translate to a rotate without carry. But I don't understand the ADDLW usage exactly, are you talking about a constant left-shifted? i.e. 4 << 2 becomes "movlw 4, addlw 4" ?

For some reason my photos weren't public, I had to get some "not for public" status removed before my photos showed up publicly. But now they're there ;D

The 7809 that regulates the 9v AC doesn't need a heatsink, mine doesn't have one and it doesn't get that hot as the input voltage is 11.3v (and I'm powering 8 SIDs from one 7809!). So you definately would not need one, the current draw for one SID is so low, and the input voltage isn't that much higher so there's not much power being turned into heat.

Basically the compiler is doing what it needs to do to support the C shift operators, which have no concept of carry bits, i.e. they always shift zeros into the byte. Which makes sense, because 99.99% of the time you're doing a shifting of bits in a bitmask, i.e. to generate a bitmask with just bit 2 set you write "1 << 2". So it's not just assuming you want that bit clear, it's meeting the specification of C, and there's nothing in C that does "rotate no carry", you have to code that explicitly. If you're shifting through one or more bytes in PIC ASM you would have to set the carry bit to the first (or last) bit prior to doing the "rotate through carry" ops.... this is generally achieved by doing an RRCF or RLCF putting result into W (i.e. just shift the bit into the carry but don't do the rotate on the register). A similar thing has to be done in C for every time you're bit shifting and want anything but zeros coming in... so for one byte you'd have to do something like this: /* rotate left no carry */ x = ( x & 0x80 ? 0x01 : 0x00 ) | ( x << 1 ); /* rotate right no carry */ x = ( x & 0x01 ? 0x80 : 0x00 ) | ( x >> 1 ); [/code] I don't know how efficient that compiles with SDCC, but it's going to be less efficient than just doing two RLCF or RRCF.

Sorry, my mistake... the 8580/6582 have the correct "logical AND" of the waveforms and the 6581 has something different... I recall they were inaudible on my 6581... a quote from the manual: http://www.midibox.org/dokuwiki/doku.php?id=midibox_sid_v1_manual Note: if a MOS 6581 is used, it is possible that on mixed waveforms the sound output is much lower or unhearable. This is due design bugs in the chip - the 8580 can handle mixed waveforms much better

my 4c on the topic ;D In the non-embedded world at least, recursive functions in C/C++ are generally avoided because it is all too easy to cause stack overflows depending on the input, i.e. cater for all possibilities. Take the classic example of a Fibonacci sequence number generator, i.e. calculate the nth number of the Fibonacci sequence, in which each number is the sum of the two previous numbers in the sequence. This is pretty easy to express recursively: int fib( int n ) { if ( n <= 2 ) { return 1; } else { return fib( n - 1 ) + fib( n -2 ); } } [/code] But then when you call it with n = 1000, your stack blows up. Of course there's no reason you can't do some things recursively with careful guards and limits on how much you recurse... the quicksort algorithm is a great example of this divide-and-conquer technique and it's harder to blow up the stack because you'd need a really huge number on the input to cause too many recursions. However, most times when you think a recursive function is appropriate, you can rewrite it as non-recursive using loops and state variables, or just think of another algorithm entirely. For example, the Fibonacci calculation can be done iteratively, like this: [code] int fib( int n ) { int a = 1, b = 1; for (int i = 3; i <= n; i++) { int c = a + b; a = b; b = c; } return b; } Once you get your head around that, you'll realise the iterative algorithm is just as complex (i.e. would take just as long to execute) as the recursive one, even if it is a bit harder to understand how it works. The same applies to most other recursive algorithms - there usually is an iterative way of doing the same thing... with no chance of stack overflow!

The shop is closed for now... all SIDs have been sold! I might have some left over if people change their minds...

Get a BankStick. You can store settings in the one internal patch but I don't know if JSynthLib works well like that... it's a lot easier (and more fun!) to upload 128 patches to a BankStick and switch between them with a program change MIDI event...

It's mainly about using a common ground. If you've supplied your Core and SID modules with separare power supplies (i.e. two plug packs) then the grounds of the two modules are connected (so the logic levels of Core->SID have the same 0v reference). This causes what is called "ground loops" which is a very complicated concept that I don't fully understand, but essentially means there's more than one path to ground... i.e. the current on the SID module could go to ground via the SID power supply or jump across to the Core and go to the ground of the Core power supply. The other issue is digital noise on the 5v/ground supply, to reduce digital noise, the optimized PSU circuit joins them up with common wires rather than each SID module being supplied by the Core to which it is connected. If you have multiple Core and SID modules, the best solution is to have one set of bridge rectifiers/regulators (i.e. for 9v and 5v) and join their grounds together and supply each module from one central PSU circuit... I mean you do not need an actual C64 "brick" PSU with 9v AV and 5v DC outputs... you can use two plug-packs to get your two voltages and copy the rest of the circuit, supplying a REGULATED 5v DC to all modules and a REGULATED 14v DC supply to each SID module (and use whatever regulator on each SID module to drop it down to 12v or 9v as required). Or if it's easier, use a REGULATED 9v DC or 12v DC supply (one 7809 or 7812 for all SID modules!) and connect it to where the REGULATED supply is required on each SID module (i.e. the output pin of the regulator on each module). Whatever you decide to do, DO NOT INSERT SIDS until you check the voltages on the SID socket pins, and also check that ground is ground everywhere... i.e. check difference in voltage between ground pins of the chip sockets and a common ground at the PSU...

The button toggles through: Tri, Saw, T+S, Pul, P+T, S+P, PST, Noi, off I think you can change a setting in the firmware setup so it doesn't use mixed waveforms (6581 doesn't have mixed waveforms).

Maybe I wasn't clear enough... Send me a private message with your order, include your real name, PayPal email address and address to send the SIDs, and I will send a PayPal invoice. You don't have to pay immediately, but I do need full details, if you change your mind afterwards that's fine.

I got a new batch of 6582 SIDs, new-old-stock, that have been sitting around in anti-static tubes for the past 15 years. Stock up now for the MIDIbox SID synth V2, which supports two SIDs per Core for cool stereo effects! If you already have an 8580 SID, you'll know what these 6582 sound like. They are, as far as I'm concerned, identical to the 8580, use a 9v supply (not 12v), and have a filter like the 8580 and very low noise, unlike the 6581. So if you already have one 8580, you can use a 6582 as the second one in a stereo pair without any noticable difference. This could be the last batch of SIDs I ever obtain and resell to the MIDIbox community, and as far as I know, they could be the last unused 6582 SIDs. I could sell them on eBay for AU$40 to AU$100 (and have!) to the C64 enthusiasts and SID fanatics, but I'd like to sell them to the people who want to make MIDIbox SID synths, especially those crazy like me who want an 8x SID synth. The price is AU$20 each (that's around US$16, 12 EUR). Postage and handling is actual cost to me, and it varies. If it's just sent as a letter, it's AU$4 If you want postal insurance, it's an additional AU$8, but to some countries, postal insurance is only available for parcels, so the postage increases from AU$4 to AU$8. When I sold off my 8580s last year, one parcel got lost, so if you don't get postal insurance I can't afford to replace or refund... it's up to you (unlike my eBay auctions where everyone pays AU$18 postage+postal insurance). Send me a private message with your order, include your real name, PayPal email address and address to send the SIDs, and I will send a PayPal invoice.