TK.

of course, the IIC connection won't work if this resistor is not available normaly, the selections should be done automatically, because they are stored in the .hex file If your programming tool doesn't handle it correctly, here the values: Oscillator: HS (!!!) I don't know what CCMPX means, but the values seem to be correct. Ignore the write protection WRT Best Regards, Thorsten.

I would propose to disconnect all modules to reduce the number of possible errors, use only the core module for the first upload test, even the LCD should not be connected (yes, the black bar is normal so long MIOS hasn't been uploaded) Pin 25=0.5V: sounds like the PIC is not running, or that there is a short between the Tx track and another track Best Regards, Thorsten.

I remember that I read about a similar issue short time ago somewhere else in the forum? Best Regards, Thorsten.

There is a lcd_interconnection test available at the MIOS download page which helps you to find out, if the cables between core and LCD are wired correctly. It doesn't ensure if the pinning is correct (thats not possible), but it might give you a hint Best Regards, Thorsten.

Not before you've done "TEST PC2" of the troubleshooting guide Best Regards, Thorsten.

A primitive octave quantisation is possible by forwarding the note or a whole chord (up to 4 keys or auto-chord - 16 predefined key combinations) to a track in arpeggiator mode, because the arpeggiator allows you to select the key number and the octave seperately. And since it is possible to split the transpose function from the arpeggiator function (transpose: left keyboard half or one "loopback" track, arpeggiator chord: right keyboard half or another "loopback" track), there are also some complex stuff possible here :) But I know, this again is not exactly for what you are searching for. I would say: I will try to combine one or two parameters in single bytes to free some space within the track memory, and after the first or second release of MBSEQ V3, I can decide for which purpose these reserved bytes are finally used. If there is no better idea, a max and min limit with wrapping function will be included (for myself it's a minor feature) For efficient handling a 16bit or 32bit controller would be required, so it can really only be considered in a future version (MBSEQ V4?). I don't want to say, that the PIC is not able to handle 14bit MIDI values, I only want to point out, that in the MBSEQ V3 application the data and task handling is already so complex, that such features will only reduce the overall performance, and this is what I definitely want to prevent. The communication between two cores will cost more performance than handling everything in a single core. One of my secret options, about which I already thought about, but for which I propably won't find the time (considered that I will start with MBSID V2 sooner or later) is the re-implementation of the sequencer engine in VHDL, so that it can run on a FPGA. This would result into the first true-zero-latency sequencer of the world ;-) It could still use the MBSEQ V3 control surface, but only as a "entry terminal" to the engine, coupled via a fast interface. But such a project would also increase the skill barrier for electronic newbies My experiences with the new PIC18Fxxxx derivatives are so bad, that the next platform won't be based on Microchip products anymore. Maybe in 2008 I will look for an alternative 16- or 32 bit controller which fits the needs for a DIY project (which especially means: low-cost toolchain, high reliability, good worldwide availability, low support effort from my side) It should be a microcontroller family for the next 10 years... No, the first note would be stopped immediately before (no glide) or after (glide flag set) the second note. This is required to fasten the note array handling. Since 16 tracks can play up to 4 notes, the note array has 64 entries. On each 96ppqn clock, the sequencer has to process all entries - it has to decrease the delay counter and it has to send a Note Off event once the counter reached zero. This simple handling speeds up the code at many places (e.g. it makes it easy to switch from one to another pattern without searching for "open notes" which relate to the old pattern), that I want to stick on this solution. I believe this, but negative delays are not so easy to handle by the engine. E.g., I don't know how to ensure that the track is still on-sync when you are quickly switching between different patterns with different groove settings without waiting until the track has reached the end. After I saw this desaster, by decition was: before spending some weekends in implementing and debugging new compensation and synchronisation routines, it's better to keep it simple at this place and to focus other features. Best Regards, Thorsten.

Hi Hazes, yes, it's perfect! Best Regards, Thorsten.

No, I don't have the document anymore. It was not complete anyhow, I had to reverse-engineer the details about the last 6 bytes of the SysEx stream, for which it turned out, that their purpose is to write the waveform control registers two times - one time without, one time with gate flag. So, with the sid_play.inc at least a parser is available which is 100% working, the question is: what else are you missing? The main protocol is quite simple - it just dumps out the content of all SID registers on each update cycle (traditionally called raster interrupt) of the 6502 emulation engine (50 Hz) Best Regards, Thorsten.

Could also be a PSU issue, I remember that QBAS had the same "reset during flash programming" problem: http://www.midibox.org/forum/index.php?topic=7359.0 Best Regards, Thorsten.

Yep! Thats the reason, why buttons and LEDs have a common ground - to simplify the wiring Best Regards, Thorsten.

Hi Ixox, thanks for writing this down! I think the best would be to add a link to this forum article to the wiki, e.g. at this page: http://www.midibox.org/dokuwiki/doku.php?id=forum_highlights This has the advantage, that people can read about the history (some thoughts which flew into the design), and that they can add comments Best Regards, Thorsten.

Wenn die Multi-BankStick option erstmal in der MBSEQ V3 implementiert ist, wird die Groesse in main.asm einstellbar sein. Ein 32k BankStick kann dann 64 Patterns speichern, ein 64k BankStick 128 Patterns. Fuer den Songmode benoetigt man noch einen zusaetzlichen 32k BankStick, oder man kombiniert Song/64 Patterns auf einem 64k BankStick, so wie bei der MBSEQ V2 Gruss, Thorsten.

Hallo, zum Soundblaster kann ich nicht viel sagen, aber "Unknown Device" koennte darauf hinweisen, dass der Treiber Deines MIDI Treibers keine Multi-Client Option unterstuetzt. Es kann also immer nur ein MIDI Interface auf den MIDI-Port zugreifen, alle anderen erhalten eine kryptische Fehlermeldung. Abhilfe schafft ein virtueller MIDI Port wie bspw. MIDI-Yoke - siehe auch http://www.ucapps.de/jsynthlib.html Gruss, Thorsten.

The stack boundaries are defined in the file header of mios_wrapper/mios_wrapper.asm: ; the upper boundary of the stacks are defined here ; customize the values for your needs #ifndef STACK_HEAD #define STACK_HEAD 0x37f #endif #ifndef STACK_IRQ_HEAD #define STACK_IRQ_HEAD 0x33f #endif [/code] The default setup is 64 bytes for main tasks, 64 bytes for interrupt tasks. (stack pointer is counted down, there is no collision control to save runtime) Since a PIC18F4620 has enough memory, you could use two 256 bytes stacks located at the upper RAM pages: #define STACK_HEAD 0xeff #define STACK_IRQ_HEAD 0xdff this should relax the situation. Note that the appr. memory area (0xd00-0xeff) should be reserved in the projekt.lkr file Best Regards, Thorsten.

Please note, that the correct writing is "MIDIbox", not "MIdibox" Best Regards, Thorsten.

It isn't a big problem to ensure that incoming MIDI data won't get lost, when you are writing an own handler which checks for new data periodically. The period must be less than 320 uS -> see also the MBHP_TV application Best Regards, Thorsten.

Just think about it: do you think that I would ever throw away my existing MIDIbox SEQ frontpanel? Apparently, it's an optional feature, and I for myself will built this into a seperate 19" rack case. The sequencer works nice without the Button/Duo-LED matrix - it's just one of many features :) The schematic is a mix of the button and historic single-colour LED matrix, I will publish it once I find the time to draw the connections. Here some additional infos from the ChangeLog: [tt] o overworked LED matrix, implemented button matrix There are several configurations possible, here the tested ones: a) historic 4x16 LED matrix which replaces the 1x16 GP LED row Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 3 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 4 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; can be optionally selected if LEDs with high power consumption are used #define DEFAULT_SRM_DOUT_DUOCOLOUR 0 ; no DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 0 ; no button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_L 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_R 0 ; only relevant for button matrix Note: compared to the old schematic, the cathodes are now mirrored! This means that you have to change the wiring on your existing hardware Upper Row: DOUT pin D7 second Row: DOUT pin D6 third Row: DOUT pin D5 fourth Row: DOUT pin D4 b) 16 "GP LEDs" + 4x16 seperate LED matrix recommented solution, since this allows the firmware to display menu parameters seperately below the LCDs Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 6 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 9 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; can be optionally selected if LEDs with high power consumption are used #define DEFAULT_SRM_DOUT_DUOCOLOUR 0 ; no DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 0 ; no button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_L 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_R 0 ; only relevant for button matrix c) 16 "GP LEDs" + 4x16 seperate DUO LED matrix recommented solution, since this allows the firmware to display menu parameters seperately below the LCDs Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 6 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 9 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; SHOULD be selected with DUO LEDs (high power consumption) #define DEFAULT_SRM_DOUT_DUOCOLOUR 1 ; DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 7 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 10 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 0 ; no button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_L 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_R 0 ; only relevant for button matrix d) 16 "GP LEDs" + 4x16 seperate DUO LED matrix + 4x16 seperate button matrix recommented solution, since this allows the firmware to display menu parameters seperately below the LCDs The 4x16 additional buttons should only control the step gates (and other assigned triggers) Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 6 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 9 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; SHOULD be selected with DUO LEDs (high power consumption) #define DEFAULT_SRM_DOUT_DUOCOLOUR 1 ; DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 7 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 10 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 1 ; using button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 1 ; only control gates (and other assigned triggers) with these buttons #define DEFAULT_SRM_DIN_L 11 ; DIN register of the left side #define DEFAULT_SRM_DIN_R 12 ; DIN register of the right side o there are now 4 additional buttons and LEDs for selecting the track group (G1=track 1-4, G2=track 5-8, G3=track 9-12, G4=track 13-16) The pin assignments are made in mios_tables.inc (or within the setup_*.asm file) [/tt] Best Regards, Thorsten. P.S.: thanks for your nice feedback! :)

I've added the question to the FAQ. Bosone: please let me know once you have your PIC18F4620 based MBSEQ up&running (via email), so that I can send you the latest snapshot with improved live record function But as Steve said: this is a different topic and should not discussed in this thread Best Regards, Thorsten.

Die Anzahl der eingesteckten EEPROMs spielt keine Rolle, zur Platzierung kann ich nichts sagen, man erkennt es eigentlich an der Codierung zwischen Pin1, 2 und 3 (+5V = 1, 0V = 0) Vielleicht koenntest Du sie ja mal herausfieseln, und ins Wiki stellen? (Eine Skizze waere nett, ich kann sie dann auf den midibox.org Server aufladen) Falls Du aus der Schaltung nicht schlau wirst, stecke das Board einfach mal an die MBSID, und ueberpruefe, welche Baenke formatiert werden. Gruss, Thorsten.

Great! :) Best Regards, Thorsten.

For the case you missed this: Best Regards, Thorsten.

Where are you living? Maybe there is somebody who lives close to your location and could help you (or you could send him the PCB via mail service) - all your assumptions cannot be answered remotely without testing the circuit, because when you are very sure that the boards are soldered correctly, and if you are sure that you connected the LED at MIDI Out with the right polarity, it must flicker. Otherwise the only possible reason I know is, that the bootloader hasn't been burned into the PIC, but this is unlikely, since this never happened before Best Regards, Thorsten.

(I've merged the two articles in order to avoid, that people miss the new findings) Best Regards, Thorsten.

It could also be that your PSU works out-of-spec, means: the output voltage already sinks even when the circuit draws less than 500 mA. A better PSU helps to reduce the hum significantly Best Regards, Thorsten.

The previous code of lc_init.inc is now located in main.asm, USER_Init function. It's not referenced in the program, but yes: there are two comments which refer to lc_init.inc instead of USER_Init Best Regards, Thorsten.