TK.

Hi, from http://www.ucapps.de/mios_bootstrap_newbies.html if multiple cores are connected to a single MIDI port in parallel or in a chain, each core should get it's unique device ID, so that the upload tool can address the code to the right receiver. The device ID is part of the ID header, which can only be modified during the flash programming of the bootstrap loader, or with the change_id application. The device ID selected in the upload window must match with the device ID of the core which should response to the transfer. This means in other words: after the MIOS device ID has been modified by the change_id application, the ID in the MIOS Studio Upload Window has to be changed as well, so that it matches with the new ID value. So long only one MIDIbox is connected to the MIDI port, it's save to use device ID 00. A project where different device IDs are required is the MIDIbox SID (the master gets the ID 00, the slaves the IDs 01, 02 and 03) Especially MIDIbox SID users will notice the problem, that the MIDI Outs of the slaves are not connected to the PC (only the MIDI Out of the master core). Accordingly, the upload tool of MIOS studio won't continue after the first code block has been transfered, since it doesn't get a response. There are two adequate solutions to overcome this: the Newbie method: plug the slave PIC into the master core socket and program it in the same way like you did for the master PIC. Only differences: you have to pick another .hex file, and you need to change the device ID. This has the advantage, that you can also ensure that the software is installed properly with the master core/SID as a "reference". Best Regards, Thorsten.

Hallo Constantin, die Baudrate wird im sogenannten "ID Header" festgelegt, der zusammen mit dem Bootloader in das Flash programmiert wird. Ohne Programmiergeraet gibt es nur die "change_id" Applikation als Alternative, doch diese muesstest Du zusammen mit MIOS ueber ein normales MIDI Interface aufladen. Hast Du eins in Reichweite? Gruss, Thorsten.

Did you also try to upload MIOS via 1st level bootloader, just to check that a corrupted installation isn't the issue? You can do this the following way: power-off the core, enable smart mode, load the latest MIOS .hex file into MIOS Studio (mios_v1_9f_pic18f4685.hex), and press the upload button. Now power the core: MIOS Studio should start with the upload after the upload request has been received. Best Regards, Thorsten.

Hi Lars, unfortunately these LEDs are not the right ones, because they either lit yellow or green depending on the polarity (so, you cannot mix the colours). In order to get use of the two colours, each LED has to be connected between two output pins, and some changes in the firmware are required as well (at different places - I cannot list them without testing it by myself). In general, duo-colour LEDs with 3 leads are only supported in matrix configuration as shown in the schematic Best Regards, Thorsten.

It's also normal that the PIC18F452 version of MBSID V1.7303 behaves strangely, because the PIC18F4685 is not completely compatible. Could you please create a SRAM dump from address 0x000, range 0x80 and address 0x500, range 0x100 and copy&paste it here? This give me the required informations about the LCD state. The SRAM can be read with the debug tool of MIOS Studio like shown here: Best Regards, Thorsten.

It's ok from my side so long this is a one-term business, although I find it strange as well. Best Regards, Thorsten.

There are two possibilities: 1) either forwarding 6 independent transposed/sequenced/arpeggiated key values to CV outputs 2) or forwarding 6 independent oscillator frequencies to CV outputs Option 1 would already be useful for most cases (especially for TB303-like hardware, as glide is generated by an analog circuit and controlled from a digital pin) Option 2 would give you a lot of additional possibilities, as it would include the portamento/glide/glissando effect, Pitchbender, Finetune/Detune and the modulation matrix output. You can turn your analog synth immediately into a modulation monster! ;-) Drawbacks of Option 1: none Drawbacks of Option 2: the appr. SID oscillator needs to be disabled, as the SID frequency register doesn't work linear. However, you can still control your SIDs from a second, third or fourth core, or from a second MIDIbox Digital gate options: a) gate/glide and accent of OSC1 Left and Right channel (makes 6 digital outputs) b) the 6 gates of the 6 oscillators Option a) would be perfect for TB303-like hardware, these are the control signals which are going into the analog domain. But you could "only" control two synth modules per core Option b) would give you exactly the same features as with 6 SID oscillators (however, the SID itself would be silent... or it shouldn't be stuffed at all) Means: fat Lead patches with multiple modulation possibilities, punchy drum synth, two basslines with additional modulation possibilities, and a multi engine for polyphonic sounds (or 6 independent voices) with dynamic or static voice allocation. Hm, would be interesting how a Minimoog sounds when it is controlled from a wavetable or fast C64-like arpeggiator ;-) These are the changes I could include into the firmware very easily. In fact for Option 1) I only need to copy the key value to the AOUT register, and for Option 2) I only need to select a linear frequency mapping and copy the oscillator value to the AOUT register The flags for option a) and b) already exist as well, and only need to be copied into the AOUT_GATE register All options would still allow to forward the SID filter value to CV outputs in addition. By doing so, the external synth filter (or any other CV source) would be part of the mighty modulation matrix Thats all what is possible without much effort, only question: should it be a soft- or hardoption. Means: is it ok for you to build a new .hex file and upload it to the core in order to configure the CV routing, or is it really required to control this from a menu page during runtime (which increases the effort at my side dramatically, and makes it less flexible) Best Regards, Thorsten.

Ok, I checked the GNUWIN32 status and found out, that it is very similar as some time ago - you still need Cygwin (at least bash) to use the tools like "configure", and you need to install a lot of additional packages in order to get the toolchain running. So, I think that two or three independent windows users should evaluate your approach, if it is easy enough to understand, especially when a certain tool doesn't work immediately. I won't give much more comments anymore to ensure that nobody is influenced by my own oppinion (which might be too conservative?). The result should be a clear picture, if people who have used MPASM (see http://www.ucapps.de/howto_tools_mpasm.html) for assembly based firmwares, or the current SDCC setup http://www.ucapps.de/mios_c.html) in the past, will be able to rebuild the source code of an application if it is completely handled by autotools with similar 1-2-3 instructions (install this, install that, push the button). Note that most users who have to (re-)build an application are not programmers, they maybe only want to configure their MIDIbox and create a new .hex file with hardware specific settings. Therefore it would be important that after a basic windows setup has been found out, some additional users without programming knowledge try to rebuilt a .hex by themself based on instructions. Note: if the concept works, then an "all-incusive installation package" could be created. Best Regards, Thorsten.

Ok, I will check it this evening and give you feedback. I haven't expected that the development still continues, I did the evaluations ca. 2 years ago, and only found unix ports with flaws... Problem is, that most of my own assembly programs can only be assembled with MPASM due to the more powerful macro pre-processor. Some time ago I wanted to switch all my programs to a GPASM friendly format without these macros (could be automated easily) but I felt handicaped while programming without my beloved IFSET and IFCLR macros. And there are more complex macros, e.g. in the MBSID firmware, which cannot be replaced on an automated way, and where the code looks really ugly if you try to transform them into multiple lines... A solution would be to extend the GPASM macro processor, but after I looked into the source code I noticed that this won't be an easy task (at least for me) However, the SDCC wrapper on the other hand cannot be used with MPASM. All C based, and some of my newer small applications (like the MBHP_IIC_* and MBHP_USB_PIC firmwares) are completely GPASM compatible. For people who are not writing so much in assembler, or who are not used to work with complex macros, don't have any disadvantages here though... You can start a poll, but I think the result is clear: there will only be one person who prefers to work with MPASM, and thats me ;-) Best Regards, Thorsten.

This approach won't work. The PIC17 is a very different chip, it especially has only an OTP (one-time programmable) memory instead of flash. Therefore it will be dangerous to program it with a cheap PIC burner, if this has never been tested before. With bad luck you will quickly loose two or three PICs and a lot of money. In addition, the MIOS bootloader is located at a special memory range which is probably overlapped by the firmware. And it would require a special adaption for the PIC17 derivative... Unfortunately my PICstart kit (which can burn PIC17 chips) doesn't work on my PC anymore due to a missing COM port, otherwise I would be able to help you Best Regards, Thorsten.

...and I assumed, that you are building your own DSP based synths meanwhile? :) Looking forward for the pictures! Best Regards, Thorsten.

The problem is, that you need to specifiy DOS style pathes (with backslash) in the configuration files. For "make" there is the same requirement, and in addition all DOS make implementations I know ignore the PATH variable, so that tools need to be specified with absolute pathes. Accordingly, the Makefile* looks very different. At least these were the issues which prevented me from setting up the common Makefile approach for the SDCC wrapper, and why I decided to create a simple makefile generator which allows to create a batch file. I'm not really a DOS/Windows fan (in fact I work under Solaris/Linux @ Work, and mostly under MacOS @ Home), but I find it important to provide an universal solution, so that everybody is able to contribute, and not only a small group of people who have the right OS installed. We already have this issue with MPASM (which runs only under Windows), please don't do the same error like me with a new approach. Best Regards, Thorsten.

I selected the GPL at a time where MIDIbox was in a primitive state, giving other people the possibility to jump on the train and to continue with my initial work. Some years later I realized, that I spent an immense effort into the projects, but nearly nobody really contributed to the source code (*). Instead of that, sometimes low experienced people were trying to sell ready made MIDIboxes, completely based on my IP, over different channels to make profit without contributing in any way to the community (even not supporting the customers?) I think it is my right to switch to another the license if I changed my mind based on such experiences, and I also think that I don't need to justify my own learning process. Meanwhile there are other powerful open projects for MIDI (or DAW control) like Arduino or Monome which have been developed by multiple persons and distrubuted under Creative Commons license. So, if somebody prefers such a license, just jump on there and help to support these communities. Best Regards, Thorsten. (*) this has changed, meanwhile people have contributed new software and hardware projects, even tough MIOS is not licensed under GPL anymore. So, it seems that the decision wasn't bad for the progress...

Yes, thats the way how I normaly create libraries - it's the most effective way. You can do this if you have the time, but please do it in a way which allows to rebuild the library on a simple way without the need for installing a massive tool chain. So, rebuilding a .lib file should even work under Windows without installing Cygwin (or another unix environment) I would use a perl based makefile generator for this, which creates a .bat file (for windows) and a Makefile (for unix) based on an ordered list of all sources. Once the functions have been extracted, there is no need to re-do this process. So, first check if it is faster to do the extraction by hand (I would estimate an effort of about 15 minutes), or writing a script which you will probably only use one time, and never again ;-) All you need is a powerful text editor (IMHO) Best Regards, Thorsten.

Currently the MIDI IN ports of all core modules are linked together, but they could also be connected to individual MIDI Out ports. For such a case, just remove the J11 connections between the cores, and stuff all core modules with an optocoupler. Best Regards, Thorsten.

Under MacOS, you can use Osculator for this (http://www.osculator.net/wiki/). Problem with OSC: if a small microcontroller like the PIC should receive a lot of UDP messages in a short time, there is a certain chance for data loss. Therefore the RTP (or alternatively TCP/IP) approach is slower, but more reliable. Best Regards, Thorsten.

No, it doesn't look like a PIC Best Regards, Thorsten.

Yes, it would be possible to split the MIOS functions over different .o files instead of using a single kernel, but it's a different approach and leads to disadvantages. I already evaluated the micro-kernel approach ca. 2 years ago, there are so many dependencies between the modules, that a seperation leads to a higher memory consumption that we currently have if all MIOS functions are included in a static kernel (e.g. you have to isolate internal variables, e.g. by using a stack, and you have to use the 4-byte instructions "goto" and "call" more often than the 2-byte instructions "rgoto" and "rcall"). It's also more difficult to provide MIOS updates to users who are less experienced with programming like you (don't know, how many users really know how to recompile an application, especially when they have to use so many different tools). However, if I would design MIOS today, I would consider this from the beginning, especially because it would free some extra memory for applications which don't use a graphical display or motorfaders (functions which are only used by a small number of applications). I would also define the function interface SDCC like so that an assembly file conversion, which changes the FSR pointers, wouldn't be required anymore. But I don't plan to do this for MIOS V1, accordingly you don't need to try this out again - it would be wasted effort... Splitting the wrapper functions over different files makes sense, I would split them all. Best Regards, Thorsten.

It seems that it is using the standard USB-MIDI driver, so the firmware is probably buggy. I would open the case and check, if a PIC has been used - if so, I could give you an alternative firmware which works ;-) Best Regards, Thorsten.

What is the reason why you are not using seperate keyboard splitzones? Best Regards, Thorsten.

Hi Doug! :) The LED functions can be changed in the LED map (I'm not sure how you've changed the configuration - if you've used the mk_syx.pl script, see the midibox64.ini file) I just have noticed that the comments in midibox64.ini are wrong. Value 9 displays External Bank 1-8, Value 10 External Bank 9-16 The map is also located in mb64_presets.inc for the case that you want to change the source code directly. Best Regards, Thorsten.

At least it is possible to forward Key->CV within the modulation matrix. It shouldn't be so complicated to add a K2A (Key-to-AOUT) option as well (ca. 10 lines of code). It could also forward the gate, e.g. of the first oscillator, and the glide flag. The only reason why I haven't added this yet is, that I want to collect the requirements before adding such a feature. This should ensure that the implementation is universal enough... however, your requirements are still more simple than expected. Any other functions required? ;-) Best Regards, Thorsten.

Forget about just remaking existing clones - the analog TB303-like hardware can be controlled via AOUT module with the MBSID V2 firmware. Think about the powerful possibilities (modulation and trigger matrix, arpeggiator, wavetables, etc...). It's even possible to sequence an additional SID in parallel to a TB303 from a single core and from the same CS. Or add more cores to sequence even more SIDs or external synth hardware... So, the basics already exist, new software doesn't need to be developed, just start with the experiments... Best Regards, Thorsten.

Yes, I would also propose to use the integrated shift register handling of MIOS, it is *much* faster, and there are many C examples for the usage (see bottom of http://www.ucapps.de/mios_c.html) In addition, it makes sense to play a little with the examples in order to get a feeling about the programming model. What I'm missing in your C code is the initialisation of the IO pins at J5. By default these are analog pins, in order to enable the digital stage, following value has to be written into ADCON1: ADCON1 = 0x07; In addition, I would propose to set the pins directly on the following way: LATAbits.RA0 = 1; and LATAbits.RA0 = 0; This will result into a single instruction. The currently used "BITASSIGN" macro will probably generate 10 instructions or more Anyhow, as mentioned above: try some programming examples first, and especially consider the usage of the natively supported SRIO chain Best Regards, Thorsten.

I find this approach nice. I considered to use autoconf as well at the beginning, but found it complicated and not flexible enough for different operation systems. E.g., under Windows a Cygwin installation is required, but I fear that a normal MIDIbox user is already overloaded enough by installing perl/SDCC and GPASM :-/ Therefore I started the simple "perl makefile generator" approach. However, this shouldn't prevent you to start with a more proper setup of the SDCC skeleton! Feel free to enhance it in future, but please also understand that I will continue to maintain the "simple solution". Best Regards, Thorsten. P.S.: converting the wrapper to a shared library is an elegant idea, on the other hand: is the linker able to ignore (not link in) the code which isn't used by the project? Here I see the only benefit of a library