Wilba

Well, Winstar and OSD (One Stop Displays) still have them on their website. There's obviously still high demand for character displays, even long after other kinds of displays have been available, so perhaps it's just one manufacturer that's discontinuing for some reason, and Crystalfontz and Matrix Orbital are too lazy to switch to a new supplier. If there really was low demand for PLED/OLED, why would manufacturers be developing new products that use it? One Stop Displays (OSD) is proud announce the latest product reliability information for OLED displays.. Winter Park, FL -May 5, 2006 -- One Stop Displays (OSD) releases the latest news from OSD is their new 100k Hr OLED display offerings. This new lifetime advancement will allow new applications to consider OLED technology. The advancement is limited to monochromatic yellow display products. The lifetime is calculated for operational hours from initial to half-brightness at 25*C. The new feature product applying the latest material enhancements is the OSD5664ASYAT02, 256x64 monochrome OLED. This display is perfect for 1RU rack mount designs, automotive, avionics, and a full range of applications. The display can support 7-bits per pixel PWM for 'grayscale' image depth. The display offers compatibility with parallel, I2C, and SPI interfaces via a standard ZIF-style 0.5mm pitch flex interface. The display is a relatively large OLED display offered at 2.8? @ 84.0 x 25.8 x 2.2 mm outline dimensions. 2.2mm thick!

You might want to check out the Hypnocube, an interesting project using RGB LEDs: http://www.hypnocube.com But that's a bit off topic... For maximum speed and performance, use 108 individual DOUT outputs. This is also the maximum number of 74HC595 chips you'll need too, but since it's a coffee table, size isn't a critical factor. Each colour can be pulse width modulated with a minimum pulse width of the shift register update period, i.e. 1ms. It also means that each LED can be fully on and be at maximum brightness. So if you want to optimize the hardware, then you could use a matrix and multiplex the outputs. Maybe 6 is a good number of "columns" in your matrix, so you'd use 6 DOUT outputs (through a darlington array) to sink the 6 "columns" of 18 LEDs (6xRGBs), and you connect the anodes of each "column" in "rows" to 18 DOUT outputs. The only problem is that by multiplexing, you'll have less "grain" in your duty cycle. EG. in the first scenario, a 1ms update, with a max of 20ms (to avoid flickering, 1ms on/19ms off, etc.) gives 20 "shades". In the second scenario, the update might still be 1ms, but there's another 5ms gap where the other columns are active, so it's like a 6ms minimum pulse width. Divide that into 20ms and you've only got 3 "shades". You can cut down the number of matrix "columns" to get a smaller minimum pulse width, perhaps using three columns is optimal, I don't really know... I've probably rambled on enough ;D the short answer is: just use 108 DOUT pins, might be a bit more expensive and more to solder, but will be easier to code and work better in the long run.

I bought some of these knobs from ALBS for my MB-SID, and some other ones for the MB-Seq. I can confirm that they do fit perfectly to a plastic 6mm/4.5mm shaft like the encoders from Voti. (My encoders aren't from Voti, but they're from the same manufacturer). Expect long delays between emails from ALBS, but they do eventually deliver. However, they're probably not the best ones for a MB-Seq, a bit too big at the base, it might be better to order some of the narrower ones with the same sized shaft hole (the ones on TK's MB-Seq are also from ALBS, quote from parts list: "12 x "DK13-164 black-soft", 4 x "DK13-164 gray-soft", 1 x "DK38-144" from Albs"). I got the very narrow ones, "albs P/N 860006- -Drehknopf DK10-150 A.6/4,5 AT:13,5mm schwarz" and they also fit nicely to my encoders, as would any of the ALBS knobs with "A.6/4,5" in the description. Hope that helps you ;D

Why so many regulators? FYI, the "C64 Brick" has just one 7805 in it, with a massive heatsink, as it's regulating the second 9v AC coming out of the transformer, the first 9v AC goes direct to the plug. Following the experiences of others, including myself, who have reused the C64 PSU, that one 7805 should be enough for the 5v supply to four Cores, four SID modules, one backlight LCD and the required DIN and DOUT modules, plus all the LEDs. Also, you don't need that big a capacitor on the SID module, or even on the Core... these are big in case you supply those modules with AC and need to convert it to DC via a bridge rectifier and regulator. You can put those bits external to your stacked modules. See this: http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf and consider the 7805's removed from the Cores, each Core gets its 5v from a common supply, the one out of the C64 PSU. You can take that idea one step further and take out the regulators on each SID module, supplying each from a common 12v supply external to the modules.

If buttons 1-4 are working, then DIN->Core connection is OK, the fact that the non-working ones are all on one side (and the other side works) might mean you're connecting those components through the the ground (Vs) pin on J4, but that pin isn't connected to ground at all. Or, the break is higher up the wire, i.e. in the wire, or nearer the components. Test all the pins that should be ground, best way is probably to test for +5 volts and move the black probe to different points that should be at ground (so you see a change on the multimeter instead of always being zero!)

Zoink! Thanks mate... ;D

Yeah I meant DOUT. ;D

You don't always need transistors, the 74HC595 outputs can sink (just) enough current to light a column of LEDs. If you prefer to have the LEDs brighter, use transistors, but also remember you'd need to invert the output... i.e. if you connect the base of a BC547 to the DOUT pin (with a 1k resistor), then the collector will sink current when the DOUT pin is high. So only one of the outputs should be high at a time, instead of one of the outputs being low. The newer DIN DOUT module boards from SmashTV can have a darlington array chip fitted instead of the resistors (i.e. a chip of eight high-current transistors).

albs.de has them.

;D ;D ;D I don't know why "Link" isn't enabled by default, but you can recompile the app so that it is enabled by default. Saves pressing that button every time you turn it on... ;)

90201? How close to 90210 is that? ;D

I'd have to say the filter is the major difference between the two kinds of SID, if you like filters, get the 8580. The 6581 has a reputation for being very noisy (not dirty, this is overall background noise!) and a few other audible "quirks" which others appreciate. Unfiltered, and taking noise out of the equation, they sound pretty much the same, and I assume that applies to drum sounds too. Testing the SID inside a C64 falls outside my knowledge... As a quick test you can just plug in a game cartridge and listen to the intro... Learning how to poke the right bits into the SID registers to make sound is a bit time-consuming. I'd suggest buy the C64 for the case and PSU, and if the SID works, that's a bonus :)

I've used PIC16F84 before, long time ago, I burned them with a JDM programmer without any problems. If the programming pins are the same (I think they are, but compare the datasheets yourself) just try it with the same voltage as recommended for PIC16F88, it should work. If the programming voltage (VPP) is higher than expected, I think it will still work, and won't kill it ;)

If you're planning to scavenge a SID, you will probably have better luck finding an 8580 with a working filter, nearly all the 6581s I scavenged had dead filters and sometimes dead oscillators and sometimes just completely dead. But that's just my experience, others have had better success than me. 8580s are found in the newer C64C, the beige ones, although once I did find a 6581 in a beige one. Whatever you get, the case and PSU are useful, the PSU can be used to give you the 5v and 9v/12v required (see "Step C" page). If you're totally new to this, I'd suggest starting small, just get one SID going, without control surface, then evaluate whether you want to spend more time and money building a multi-SID box and/or control surface. Once you have more than one SID, a control surface becomes almost essential so you can assign the MIDI channels and patches to each SID. Definitely start out with SmashTV's modules (pre-programmed PIC) and follow the guides, especially voltage tests before you plug in chips or a display, and the Core-SID interconnection tests. It pays to make sure the SID should be making a sound before you plug it in... I do another undocumented test of the audio buffer, hook the output up to an amp and short the SID's output pin with ground without the SID plugged in!!! Also, you should get a 24LC256 from SmashTV to store your patches, an MB-SID without patch storage is (literally) a complete waste of time! SID preferences vary, and while I am obviously biased by suggesting the 8580 ;D it would seem to suit you better IMHO, especially the filter. Listen to the demo: http://www.midibox.org/midibox_sid/mbsid_v1_5_filter.mp3 First you hear 6581, then 8580, then 6581, then 8580. The second and fourth sounds are exactly how my SID sounds. Also, for the 303 bassline feature, an 8580 is recommended.

We should have a chat then, I'll email you.

I'm confused... which is the classic set? I like the ones that are currently installed.

You're welcome... ;) All the cool bits are by meeshka... The virtual keyboard is very cool!

If you can point us to the specs of the infrared slider, we can help out more... I'm also curious about it... you might not need an opamp at all... You can use a rail-to-rail opamp, but these can be expensive and hard to find. It's a lot easier to use a common opamp like LM324 and just supply it with more than 5v. Most opamps cannot output all the way up to the supply voltage, so for example if you supply an LM324 with 5v (like the Core module) then it will only output up to 5v-1.5v=3.5v. But you can supply it with 9v and it will then output up to 5v and so you'll get the full range of the PIC's analog input (0v to 5v). Opamps can be used to amplify the sensor voltage, but are also handy for buffering the voltage. Sometimes a sensor signal might be in a 0v-5v range but have a very low current, and not enough for the PIC to sense the voltage. An opamp can be used (with or without amplification) so it outputs the same voltage, but it is a high enough current for the PIC to sense the voltage.

Yes, it's Winstar brand, I own this exact model, works perfectly, you won't be disappointed! It does not use or need the backlight circuit on the Core module... the contrast pot is used to control brightness, so don't stress if it's all black when you turn it on first time, just turn the pot and the glorious green will appear. The more common term is "PLED" by the way... "OLED" is more commonly used to describe the full colour displays.

Araxis Merge is the best... especially for serious coders who need to do three-way merges regularly and compare whole directories... but it's not free. WinDiff is freeware and not bad, it comes with Visual Studio, but you can download it here: http://www.grigsoft.com/download-windiff.htm

I assume the voting question was specific to writing code as part of a MIDIbox project. Generally I try to participate in this "gift economy" (like in the Mars trilogy) where I share what I produce just like TK and the rest, so we all collectively can build things that are bigger than what one person could do alone. It is all "open source" only to a degree, because we also don't want people producing MIOS-based hardware and selling them on eBay, i.e. others shouldn't be making a profit on the sum of all the work done so far. But "rewarding" someone just for their time in coding something, that's different, isn't it? You are not paying them for the sum of all the source code. The programmer is not passing off MIOS etc. as his own work and selling it. If the result is also made open source, that's nice and in the MIDIbox spirit, but not really relevant. Furthermore, at the scale we're talking about here, it's just an exchange of favours not full time employment. Say you really want to make a custom MIDIbox, perhaps if you give the programmer enough components to make one himself, he'll help with the coding part, you put the result on the wiki so everyone benefits, and everyone's happy.

Yes, calculators and many other things with buttons will use a scanning matrix, but that's not too big a problem... most consumer electronics have buttons that are the button part with a conductive pad that bridges across contacts on the PCB... so you can cut the tracks on the PCB to make them individual switches. This might be an easier solution for you, and using the existing MIOS apps, than writing custom PIC code to handle a scanning matrix. As for specs, the suggested value for pots/faders on a MIDIbox is 10K, any higher and the current going into the PIC is not good for the analog to digital conversion. This is also a widely used value too. If you happen to find pots that are less than 10K then they'll still work fine, just use more current, you probably wouldn't want to use anything less than 1K. Gaming controllers are cool, something like a PlayStation Dual Shock controller has two analog joysticks which are perfect, and some of the buttons are even pressure sensitive too, but you'll need to adapt them a bit to suit MIDIbox as they're like a pot without a wiper, the harder you press, the lower the resistance. So to make any use of that, you need to convert that into a voltage range.

I'm assuming you want an actual LED matrix using two DOUT chips? I've done some code for another guy on the forum who wanted the exact same thing... the code appears to work, I can email it to you if you like.

Another useful thing to know: there's an "FE" (Active Sensing) message sent out before the upload request, which is the PIC testing if there's an IIC MIDI module connected.

One little problem with WinPic800: The ID it burns into the PIC appears to have each pair of bytes swapped around! Of course you only notice this if you're burning something other than all zeros! I discovered this while burning the bootloader 1.2 with the right bits for IIC MIDI... it would still transmit the upload request on the TX pin! So I uploaded MIOS and the change_id app and then changed the bits for IIC MIDI, and read it back with WinPic800. Here's what I've learned so far: An ID in WinPic800: 0000 | 0000 | xx00 | yy00 xx = IIC MIDI ID yy = MIOS Device ID (I will cut'n'paste this to the wiki!)