Johey

Did you sort out the problem with your encoders? My MB6582 behaves just like you describe. It usually works pretty good once the encoders have been used for a while, but when the box has been on shelf for some time they are mad. I would believe the encoders are jumpy and that the software should be tweaked to wait longer to confirm a step. Maybe there is a firmware out there with some tweaked settings?

Would you consider selling one case separately?

This is so sweet! I'd love build my next MBSID based on eight psuedovirtual SID chips in an FPGA. I'd keep my MB6582 for reference of course, but a noiseless and potentially bug free version would know its place from time to time.

PCB received a few days ago. Thank you very much! Now it's just about to source the pots. :)

I mean separating the OLED panel from its own PCB, installing some kind of raisers. But I guess there is some kind of leading rubber list in contact with the PCB via some coal layer, and I don't have the equipment nor knowledge modifying that.

Figured it out. :) Before, with the old LCD: After installing OLED: Only problem now is that the OLED display is much thinner than the LCD, hence sinking very deep into the panel. I will try 3d printing some bezel to cover for it to some extent. That's probably what I can do, save trying to raise the OLED panel from the PCB, which would likely fail miserably.

Figured it out. :) Before, with the old LCD: After installing OLED:

SOLVED!!! :D So... I realized the problem was that I had configured the display to be 8 bit instead of four, but the motherboard was wired for four bit connection to the display. Hence, the garbage I saw on the screen was only based on half the data. I patched the four SMD jumpers between the PIC and J15, and now it works perfectly. Sorry TK for bugging you with PM. Please ignore and please forgive. :)

Not receiving a pm from you means all boards are gone?

I thought I'd better downgrade, but I am having a hard time finding the old versions of the hex files. After loads of googling I found MIOS 1.9g and MB SID 2.043. That's pretty close to what I had before, but I had MB SID 2.042. With what I have found so far, I am having no success with my display anyway. It still looks just like on the picture above. Worth mentioning is perhaps the fact that I tried to program a driver for an OLED (device_id_00_lcd7.hex) (have not yet installed the OLED, still using my old LCD), but after that the machine didn't even boot, so that was when I decided to upgrade to the latest and greatest system. Maybe there are some bits and pieces left from that driver in my PIC? Is there any way I can wipe everything in the PIC except for the bootloader to start fresh? Edit: Starting to think the device_id_00_lcd7.hex is the reason. Apparently it is not a driver as I thought, but a setting. So my questions is simply, how can I set it back to what it was? Is there an antidote hex file floating around?

Realized I haven't upgraded my MIOS and MB6582 firmware since I built the box. It was still on MIOS 1.9g and MB SID V2.042. In order to fix what was not broken I decided to have a go, just to end up with garbage on the display. The machine is still responsive and the data on the display is changing in a predictive way. I mean, it is the same each time I boot and it answers in a repeatable way to knob turns and button presses. It feels like it gets the data as before but with a different encoding or something. Any advice on how to fix would be most welcome. :)

I'm just about to try replacing my LCD with an OLED. Just wondering, what do the jumpers on the base board do? Do I need to patch them?

Is there a board left? I'd be happy for one.

Five years have passed since I built my MB6582, so I thought it's about time learning to use it. :-) I have been ripping my hair all day long while playing around with sequencers for basslines and drums. Selecting the sequence from the control surface mod matrix works perfectly fine on SID1, but not on other cores. Going back to the manual once again, I find this explanation: " Due to implementation reasons, the special step display works only when basslines are played on the master core. " What the... Not that I had any hair to rip of in the first place, but... This is just the thing I've been fighting against, I guess? Could anybody please explain to me what the implementation reasons are, and if there is a way to overcome this? Ok, I can trig it using an external keyboard or sequencer, but that is far from convenient. In a performance situation, I'd typically like to manage the bassline and drum sequences from the control surface, leaving the keyboard setup for a lead engine. When talking about sequencers and cores... Is there a way of syncing sequences between the cores? I mean, for instance, if I have a drum sequence running on SID3 and I start a bassline on SID4, the latter should start at step 13 if SID3 is at step 13.

Interested. Sent PM with questions.