TK.

The new beta version is available now, it does not only contain bugfixes, but also new features: an update to MIOS V1.9 is required, since memory above 0x7c00 is allocated! This beta will crash with older MIOS versions! LFO sync bug fixed Modwheel/Aftertouch/Velocity/WT problem: I remembered, that this is a general problem with the data structures which I've used in the firmware. Recursive forwarding (e.g. WT -> Modwheel -> CC parameter) doesn't work properly in all cases, and if CC assignments are changed during notes are played (via MIDI or from the WT sequencer), the content of some internal registers could be destroyed, so that the patch needs to be reloaded. I added a simple workaround (WT sequencer is stopped on CC assigment changes - this works only for the master!), but a full fix will only be available in MBSID V2, where the data structures will be organized in a better way back to new features: there is now an SEO menu page to change the "sound engine options": 303 (303 mode), FIP (Filter interpolation) and E2P (linear portamento realized with the help of ENV2) the internal WT editor now allows to modify the parameters of a whole track at once, this speeds up the initialisation of a new WT sequence. Just select the position beyond 31 ("All" will be print) and modify the Mod, #1, #2 or #3 column the WT editor now marks parameters with a '!' so long they haven't been stored in EEPROM Direct Link: -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta15.zip Best Regards, Thorsten.

Sorry, this was a writing error - I meant "heat" and not "head". Hope that this makes clear, why -5V/+12V is the better solution! I don't have -12V available, only -15V/+15V from the Behringer PSU, and -5V/+5V/+12V from my own regulators... Best Regards, Thorsten.

:) Best Regards, Thorsten.

Hi Alex, the CEM3378 datasheet says, that +12V/-5V is for best performance. +12V/-12V would produce more heat, whereas +5V/-5V doesn't allow to reach the maximum cutoff frequency. For the AOUT_LC module any voltage can be used within the supported range of the TL072, it's very flexible! I don't think that you need to take care about such special cases. If somebody needs -5V instead of -12V, he can just replace the 7912 by a 7905, or he has to adapt his circuit... Best Regards, Thorsten.

Hi Ilmenator, yes, this makes sense. It seems, that the datasheet is totally wrong, because your observations indicate, that the CE input is low active. I think that RD/WR are low activate as well - and the reset, too! So: use the original driver, clamp CE to ground and RESET to +5V. I think that this will work You don't need to upload MIOS again if the core "hangs up", normaly this happens if the driver runs in an endless loop (e.g. due to a missing timeout). In this case, just upload a modified application via 1st level bootloader Best Regards, Thorsten.

Yes, the SSM2044 should do the same, a sound comparison could be interesting. It is for the CEM filters, and as the negative voltage is available, I'm also using it for the AOUT_LC module. The CV inputs (of the *external* CEM3378 circuitry -> see datasheet) are working in a range of ca. 1V-7V (CutOff) and 0V-3V (Resonance). In addition to the gain/offset trimmpots of the AOUT_LC module, I'm using 10k trimmpots against ground at the filter CV input side - all 4 AOUT_LC modules deliver the same voltages when the CVs are swept from min to max, and with the additional 10k pots I'm able to fine-adjust the desired maximum resonance and I equalize the CutOff frequencies of all filters on an easier way, than with the non-linear gain/offset pots Best Regards, Thorsten.

Yes, these are the strings and the icons which are printed out. There could be another interesting check before you unsolder this display: according to the T6963C datasheet (I just had a look), the CE (chip enable) line is low active. But in the Wintek specs it's listed as high-active signal. However, I assume that this is an error, and that all three - RD, WR and CE - are low-active signals. This means: CE_N must be connected to ground in order to activate the bus. And you have to use the unmodified driver (no bsf/bcf change) This could also explain, why there isn't a change regardless of the RD/WR polarity. Best Regards, Thorsten.

First I tried to order at robotikhardware.de - I created an account, filled all informations into the form, and finally - after 5 minutes of typing work - got a notification, that the chip is currently not available :-/ Best Regards, Thorsten.

Since months I was thinking about a nice housing for my 4 CEM3378 filters and AOUT_LC modules. Finally I got the idea, that nothing would be easier than just to integrate the modules directly into a mixer. So, I opened my "Eurorack" linemixer from Behringer and was very happy to find enough room for all the boards: As a nice side effect, the PSU is already there. It delivers +/- 15V. I'm using a 7905, 7805 and 7812 to regulate the voltages. The AOUT_LC module is supplied with +12V/-5V (+12V to get enough headroom for the filter CV). Two modules are stocked for best utilisation of the available space in the mixer case: And here the first audible results I got out of a MIDIbox FM / 4*CEM3378 combination: http://www.midibox.org/midibox_fm/PimpMyBehringer.mp3 I especially like the bubbling sounds when the filters are in high resonance, and controlled by the LFOs and EG5 :) Best Regards, Thorsten.

Hi Ilmenator, are there any new findings in the meantime? There is a simple way to debug the driver: just use MIDI events as "log mechanism". When you add following code to USER_LCD_PrintChar: USER_LCD_PrintChar movwf TABLAT ; save character movlw 0xc0 call MIOS_MIDI_TxBufferPut movf TABLAT, W andlw 0x7f call MIOS_MIDI_TxBufferPut movf TABLAT, W ;; ... [/code] each character will send out a program change Best Regards, Thorsten.

Hi Leo, did you select the HS oscillator type? Best Regards, Thorsten.

Just got my SpeakJet today - I ordered it at http://www.sander-electronic.de/be00064.html. The webshop doesn't work, but I wrote an email and received the chip within 3 days :) Best Regards, Thorsten.

I don't want to exclude the possibility, that it is a similar problem at my side. Even though both displays are working fine, sometimes strange things can happen. However, it's a little bit difficult to get the box opened (because there are some other MIDIboxes at the top :)), but I will check this sooner or later. Both displays are passive (data lines in high impedance mode) when the enable lines are 0, and this is definitely the case. There might be a difference because of higher capacitances, but I've already excluded timing issues by inserting NOPs (see above). However, thats all I can say to this, I cannot say when I will continue. Maybe somebody else with a MBSEQ could doublecheck the results? Best Regards, Thorsten.

The update procedure was complete, and if the display shows the same behaviour, it is propably related to the driver. I just have uploaded the new driver versions - app_lcd.inc is still the same, the framework is based on the v1_9 skeleton. All drivers (beside of the IIC driver) have been tested with my own displays, so please use the most recent "lcd7_*_v1_9" versions -> mios_download page (maybe it's required to refresh the page) Yes, app_lcd.inc is the right location, the driver is located there. There is a timeout loop, which you could disable (just remove the "bz USER_LCD_WaitUnbusy_Disable" branch) - if MIOS hangs up thereafter, you know that the issue is related to the busy state Yes, you are right - different polarities have to be considered. I just had a look again into the datasheet of your GLCD, it lists "RD" and "WR", but no hint about low active signals, they could be high active! Solution (try this before removing the timeout mechanism): search for "GLCD_RD_N" and "GLCD_WR_N". Each time a "bcf" is used, turn it to "bsf". And change each "bsf" to "bcf" This could help! :) Best Regards, Thorsten.

Hi Ilmenator, this bar/stripe pattern sounds like the access to the display is partly working, but the RAM hasn't been initialized, and font's are not displayed. Something like this can happen on a timeout (see app_lcd.inc, search for TIMEOUT). Either your display is slower than the one I've tested so far, or two data lines are swapped, so that commands are not forwarded properly. But I just have noticed another thing: I just have hooked my own T6963C display (donation from d2k) on a MIOS V1.9 core and noticed, that the font is scrambled. This is realted to a the "font location change" (font is now located at the end of flash memory). This means, that all LCD drivers need to be recompiled with the new mios.h file This file can be found in the migration/ directory of the MIOS v1.9 source package And there is another point for which you have to take care about when using a graphical display: the update_with_old_mios.hex and update_without_installed_mios.hex file don't contain the font, it's only part of the mios_v1_9_pic*.hex file. For the case that this is too confusing, here some step-by-step instructions: - upload mios_v1_9_pic18f452.inc in order to ensure, that the font is available - copy migration/mios of the source code package into the directory of the LCD driver - rebuild the application and upload it to the core Maybe this already helps before fixing the timeout mechanism. I will wait for an driver update until I know, that your GLCD is working Best Regards, Thorsten.

Hi Martin, from the MIOS application side this shouldn't be a big problem, because the transmission of a single MIDI event takes 960 uS, and the app. will propably process this within 50 or 100 uS. Even if your host program gets use of the "running status" feature (in this case only two bytes need to be sent for a 3byte MIDI event), it should be ok. I think that not MIDI itself is the problem, but the protocol you are using. You could control the lamps with a significantly higher framerate by using SysEx streams. Instead of sending one 3-byte event for each CV out, you could send 2 + 64 bytes instead (F0 <64 bytes> F7) The resulting frame rate would be 1 / (320 uS * 66) = 47 frames per second With the C application I sent you this can be realized without much effort, I guess that I also gave you this hint some time ago Best Regards, Thorsten.

Hi Thomas, I just have tested it on my MBSID/MBFM (one display) and MBSEQ (two displays) It works fine on MBSID and MBFM, but I would like to see a "pass message" to know, that the test has been executed. I've modified the code in the following way: void Init(void) __wparam { char error = 0; TRISB = 0x00; // enable drivers of port B // for more details about the available SFRs, just have a look into // the PIC18F452 datasheet, which is available at the Microchip // homepage: http://www.microchip.com for (i = 0; i < 8; i++) { error |= TestPins(0xb, i); } if( !error ) { MIOS_MIDI_TxBufferPut(0xf0); MIOS_MIDI_TxBufferPut(0x1a); MIOS_MIDI_TxBufferPut(0xf7); } } [/code] and I've modified TestPins(), so that it returns a value != 0 if a mismatch has been detected. On my MBSEQ I noticed a strange effect, for which I currently have no explanation: F0 00 00 0B 0E 0F 0E 00 F7 (RB0-RB4 are zero, although only RB4 should be 0, and the rest 1) I would have to open the case in order to do further analysis. I've already added some delays between the PORTB value assignment and the PORTB != TRISB check, I've also assigned the pattern "LATB = ~(1 << pin)" instead, but the result is the same... hm... Best Regards, Thorsten.

Evtl. funktioniert es auch mit einer Aenderung in mb64_button.inc. Dort gibt es bspw. die Funktion "MB64_BUTTON_Toggle", welche (wenn sich der Taster im Toggle Modus befindet) eine LED beim ersten druecken ein- und beim naechsten druecken ausschaltet. Hier koennte man abhaengig von der Button Nummer auch verschiedene Flags des MB64_BUTTON_VALUES_SR0 arrays gleichzeitig setzen/loeschen Falls Dir die Assemblerprogrammierung zu kompliziert wird (ich gebe zu, an diesen Stellen habe ich zuviel optimiert ;-), koenntest Du die Steuerungslogik immer noch mit C realisieren, muesstest dabei jedoch auf die speziellen Features der MB64 Applikation verzichten, denn die vertraegt sich nicht mit C Gruss, Thorsten.

Hi Ilmenator, the connections are correct (you can compare it against the pin definitions in app_lcd.inc), but I've no idea, why the core should send these strange MIDI messages, there is no MIOS_MIDI_TxBufferPut command within the app. A lot of "FF", "F8" and "FA" indicate, that there could be spikes of 30..100 uS on the Tx line It could be related to your power supply - is the backlight already in use? Try it without first Best Regards, Thorsten.

Thanks Thomas, I like the idea! I would like to test this by myself first, if it runs successfull on all my MIDIboxes (with all the different pin configurations), I will copy the package to midibox.org/users/th0mas Best Regards, Thorsten.

This was a problem with the file format used in MIOS V1.8, MPASM cannot handle "unix style" linefeeds. However, this version is expired anyhow. An update to MIOS V1.9 is strongly recommented, and the source code compiles fine Please read the README.txt of the mios_update_v1_9 package carefully before uploading a modified MIOS V1.9 !!! Following update path is required in your case: follow the instructions described for case B), thereafter do the modifications in the source code and upload the modified MIOS version via 1st level bootloader Best Regards, Thorsten.

Hi, this could also be realted to the Java MIDI bug, are you using the workaround I've described at this page? -> http://www.ucapps.de/jsynthlib.html Best Regards, Thorsten.

The errata list continues: - when LFO synch is enabled, there is a short delay/popping sound which can be really annoying especially on low frequencies (this bug exists since v1.7a) - problems when using the modwheel to control certain CCs, and the WT sequencer is running - various UI imperfections These issues will hopefully be solved during my easter break. Thanks to Wilba for testing the firmware so intensively :) Best Regards, Thorsten.

I'm not sure about a maximum delay for the CS line, but there shouldn't be an issue. There was a major problem with the MBHP_SID module realted to asynchronous accesses (details see http://www.midibox.org/forum/index.php?topic=5748.0), with the effect, that the gate will be retriggered randomly under certain circumstances. But you should hear a sound, regardless if the SID is clocked synchronously or asynchronously to the microcontroller (if your firmware works with asynch. accesses, you can solve this later...) No digital background noise: especially on 8580 chips its really quiet (< -70dB). But: have you ever used the SID without the transistor at audio out? Buchi wrote at his website, that he fried a SID by not using it - I took this into account from the beginning - all of my SIDs are still working after more than 3 years usage, and the MBSID is running each day (nice ambient lights ;-)) I don't think that there are other voltages which could be important. Maybe you should doublecheck the caps. Also for trivial errors (e.g. wrong signal polarity). This reminds me, that the noise at the audio out should be very high during reset - maybe this helps you to check, if anything is comming out of the SID. Best Regards, Thorsten.

You should really read the answers carefully, because there is an explicit hint to the MIDI troubleshooting guide - it has helped 100tes of people to debug the MIDI interface, and I'm sure that it will also help you! Best Regards, Thorsten.