TK.

It would be interesting, if an AVR port of an application like MBSID V2 is possible without limitations. E.g., due to the reduced instruction set of AVR, I would expect a higher memory consumption. Also the direct way how PIC addresses RAM leads to a different (more efficient) programming model. However, I'm also sure that it is a very time consuming task, especially when you need to dig through foreign code in order to understand each detail and design consideration. It's mostly less time consuming to build up something from scratch. Best Regards, Thorsten.

Hi, no, I haven't tried this yet, but a code- and performance comparison based on a real (and very complex) project like MBSID V2 could be very interesting. Best Regards, Thorsten. P.S.: for those who could think that I'm considering to use AVR in future: don't worry, my own plans are to migrate the MBHP/MIOS to a 16bit or 32bit controller in mid term, therefore I still don't consider to use a different 8bit controller for my projects.

Der Ansatz ist um Grunde richtig - erstmal alles in C einhacken, und die Performance kommt beim Buegeln. ;-) MIOS ist nach wie vor komplett in Assembler geschrieben, das Interfacing zu SDCC erfolgt ueber einen Wrapper. Mit C kann man auf keinen Fall die gleiche Performance erwarten - vor allem das Stack- und Heaphandling wuerde sehr viel Zeit kosten, und es wuerde auch nur noch ein HW-Pointer zur Verfuegung stehen... beim AVR sieht das natuerlich anders aus, doch Wunder sind hier nicht zu erwarten. C Code baut nun mal auf bestimmte Methoden auf, die zwar universell, doch nicht immer optimal sind. Gruss, Thorsten.

Yes, it really looks like something is wrong with IC3, or around IC3 (open connection, or short) It isn't possible to check the crystal without a scope. It could make sense to measure voltages around the OPL3 and DAC chip, but since these are mostly digital waveforms, you won't read any meaningful values, it can only give (an expert) a hint, if for example a connection is available between one pin to another. Sorry, I can also not say exactly the expected voltages for the OPs without opening my case. Is there anybody who has an opened case and could do the measurements? Best Regards, Thorsten.

Nice work! Btw.: your MIOS installation is outdated (MIOS V1.9 instead of v1.9f) ;-) Best Regards, Thorsten.

Hi, no, a glide function for analog outputs is not supported yet. But a "smoothing" function for CCs is on my ToDo list, it could also be provided for notes which are sent to the AOUT interface Best Regards, Thorsten.

Hi, wouldn't this be even more confusing, e.g. when you are changing tracks within the record menu? The tracks could output wrong (untransposed, or non-arpeggiated) notes which are out of scale - this isn't a consistent behaviour... However, in order to bypass the track mode checking for all selected tracks, following branch has to be inserted in seq_core.inc, line 1334, below the "check for transpose or arpeggiator function" comment: BIFCLR SEQ_RECORD_MODE, SEQ_RECORD_MODE_STEP, BANKED, rgoto SEQ_CORE_Clk_SendEvent_NoRec call CS_M_HLP_ChkTrkSelected bz SEQ_CORE_Clk_SendEvent_NM_Ply SEQ_CORE_Clk_SendEvent_NoRec [/code] Best Regards, Thorsten. P.S.: due to the inconsistent behaviour, I won't add this change to the MBSEQ release.

Hi, I'm sure that serge's SysEx loader is not compatible with MBSID V2, I'm surprised that it was more successfull than using MIDI-Ox. Maybe the output buffer size in MIDI-Ox is too small? I'm using a buffer size of 1024 bytes, but maybe your MIDI interface requires at least the size of a single patch dump (patch dump size is 1036 bytes). 2048 should be a save value. A 24LC256 provides only 32k EEPROM memory, the patch size (don't mix this with SysEx dump size - it's a different coding) of MBSID V2 is 512 bytes, accordingly only 63 patches can be stored (the first patch is located in internal EEPROM). I just tried to upload the presets into a 24LC256, and noticed following effect: the upper 64 patches will always be stored into the patch A001 position (internal EEPROM) - I would expect that they will be rejected with an error response. Sometimes storing patches into internal EEPROM takes longer than 750 mS, therefore you will sometimes receive MIDI overflow error response. However, the missing rejection is a minor issue, but it will be fixed with the next release candidate. I guess that patch A002-A064 have been uploaded correctly? With a 24LC512 you will be able to upload the whole bank Best Regards, Thorsten.

Here some infos about measuring current: http://www.hobby-electronics.info/course/html/ch02s05.html It helps you to determine, which part or module consumes most of the current. E.g., for a single core module w/o LCD backlight and without DIN/DOUT module I would expect a current drain of about 50 mA, with backlight maybe 150..200 mA - this can be measured at port J2 (if you are using the optimized PSU circuit) or at J1 (if you supply the core module on the common way). You need to disconnect one cable (use the +5V line), and insert the multimeter there as a "bridge". By connecting the DIN module, the current drain shouldn't increase - if it increases, it indicates that there is a short somewhere around the 74HC165. This can be visually checked at the bottom of the PCB (search for soldering clumps, etc.) Best Regards, Thorsten.

Du programmierst den LCD Treiber in C und nicht in Assembler? Die CPU scheint wohl ansonsten nicht ausgelastet zu sein... ;-) Gruss, Thorsten.

Hi Dave, yes, the MBFM application doesn't output the 1kHz tone, instead you should be able to trigger an epiano sound, which is located in internal EEPROM (so, it should even work w/o BankStick). Hope that you've used "Smart" mode during the application upload - just to ensure that it was really uploaded. could be related to the voltage regulator - is the 7812 getting hot? yes, it is Best Regards, Thorsten.

A new release candidate is available: o multi engine: improved approach for routing LFOs to filters (only LFO of last assigned voice will be used for more predictable results) o reduced intensity of LFO pitch modulation for multi and bassline engine (Lead engine: intensity can be reduced by decreasing the depth of the modulation path) o 8 external switches can now be connected to - DOUT shift register (-> DEFAULT_EXT_SWITCH_DOUT != 0) - port J5 of the core mode (-> DEFAULT_J5_FUNCTION == 3) The switch states are stored in the patch structure, and can be accessed via Control Surface (EXT menu) or via Parameter Change (NRPNs/Knobs/Wavetables) o support for dumping ensembles via SysEx o the SysEx structures are now completely documented under doc/mbsidv2_sysex_implementation.txt [/code] Note that the file structure has been changed to improve the oversight. Include files are now located under src/, documents under doc/ Best Regards, Thorsten.

Your PSU is not strong enough, this causes the issue. During Power-On, the PIC requires most of the power. For these 1..2 seconds the voltage probably sinks below 4.6V, and unexpected things will happen - or nothing will happen... I would propose to try it without LCD backlight first, and maybe only with a single PIC (remove the slave PICs from the sockets) just to check if my assumption is correct. Best Regards, Thorsten.

No, this isn't normal - the LCD output should be stable. Best Regards, Thorsten.

Hi Paul, welcome to the forum! :) Note that a 2x20 LCD is recommented for MBSID, with 2x16 some messages are not completely visible. I don't have so much experiences with supplying a MIDIbox from batteries, and also cannot give you a proven schematic for a low-drop regulator. Yes, it should already work with 7809 and 7805, the only danger I see is, that on a battery brown out something unexpected could happen - e.g., if you try to write a patch into the BankStick while there is no power anymore to finish the procedure, invalid data could be written, or the whole BankStick content could be corrupted (thats only an assumption - you wanted to be informed about possible issues...) Best Regards, Thorsten.

Hi Dave, the voltages at IC5 outputs seem to be ok, a positive offset between 2V..4V has to be expected. I would propose to check this first with removed IC3. You could connect the audio input of your mixer/soundcard to the IC5 outputs w/o much risks - you should hear a silent, but noticable sinewave (with the testtone app). If you don't hear it, we have to search for another debugging approach. Best Regards, Thorsten.

Yes, it should be a 1:1 connection. Best Regards, Thorsten.

I guess that DragonMaster means an integrated crystal oscillator, but it won't really help, since clocking the PIC with 40 MHz from external is out-of-spec, and using the PLL to quadruple the frequency will lead to asynchronous effects - so, there is no benefit at all. The frequency stability can be tested the following way: assign all SID cores to the same MIDI channel, select the same BPM rate, select the same drum or bassline patch, and start the sequence with a MIDI note. Last time I checked this, all cores were still running in-synch after ca. 30 minutes, thereafter I stopped the experiment. Best Regards, Thorsten.

The bottom connector is normaly connected to shield, but it will also work without. It would even work if no ground is connected to the middle pin, as MIDI is a current loop. When you are writing "got my leds to light up" - does this also mean, that the Tx LED is flashing when a MIDI event is tranmitted over the IIC port? Receiving MIDI data: did you connect the RI_N output of the IIC_MIDI module with J6:SI of the core module? Best Regards, Thorsten.

It could work somehow, since the control surface already routes most of the parameters through the CC layer (-> CS_M_HLP_TrkCC_Set function), so that the extension only needs to be added to a central function. The mute functions are not routed through the CC layer, but this could be changed... But I already see some issues: how do you want to re-initialize the changes when a song is restarted? Do you want to record all initial CC parameters? Thats a lot of events which will cause a huge delay. To which MIDI port should the events be routed? I think that you don't want to record them over the same port like the events which are directed to synths? Does Sonar allow you to filter incoming events, before they will be recorded? Best Regards, Thorsten.

You are doing everything correctly, my assumption is, that there is anything wrong with the shift registers. You are able to test each seperate pin with the dout_enc_v1_3 test, which is available at the MIOS download page. When selected, the pin should output 5V, when not selected, 0V Does it work? To answer your other questions quickly: I cannot say if the display is broken, but if it flashes during power on, it seems to be ok. This effect tells you at least, that the 74HC595 are powered correctly. Yes, dot LED doesn't need to be connected. Yes, the digits should display the BPM once the MIDIbox SEQ startup screen is visible after power-on. No, you don't need to go into the BPM page to activate the display, it's a hardware option. Display connections: always a confusing topic, it's easier to try out the LEDs directly. Desolder the display, or remove the 74HC595 from the sockets and to the test by connecting cables to the empty socket pins. Connect ground over a 220 Ohm resistor to one of the cathodes, and +5V to a common anode line. The selected segment should lit. Don't forget the resistor - without you will fry the LEDs! Note that it is also possible to do this test by connecting a resistor to the anode instead of cathode - it doesn't matter when the resistor is located, it's only important that you don't drive the LED pins directly with 5V! Best Regards, Thorsten.

Yes, I would prefer the audio solution for delaying the metronome signal. Best Regards, Thorsten.

Thats a strange behaviour, which EEPROM are you using exactly? E.g., I would expect that for the case you are using a 24LC256 (32k) type, the message "<only 32k BS>" would appear on LCD when a patch >64 is selected. For BankStick #1 (Bank A) it's important that all chip select lines (pin 1, 2 and 3) are connected to ground. The write protection (pin #7) has to be connected to ground as well. Best Regards, Thorsten.

Could it be, that the socket for the C64 PSU plug is broken? I would expect such an effect if one of the 9v AC pins has no connection. Best Regards, Thorsten.

You are clever! ;-) Best Regards, Thorsten.