TK.

So, which code can be seen in main.asm, line 230? Best Regards, Thorsten.

Hi Zomoipotoi, I cannot give you an adequate number as this overrun issue depends on a lot of parameters (SID sound engine load, used CC, sent notes). It happens due to a too small MIDI buffer in the PIC16F based firmware which affects the realtime capability, there isn't enough RAM free for a larger buffer. My suggestion: when the MIDIbox SID should receive a lot of external CC data, switch to PIC18F - I never noticed a buffer overrun in this implementation. Best Regards, Thorsten.

Very experimental - it seems that you've had a lot of fun, and this makes this piece interesting! :) Best Regards, Thorsten.

ooops... (fixed) Best Regards, Thorsten.

Hi Lo, for the adaption to your encoders you need to change: mios_tables.inc: the correct encoder type (detented or non-detented main.asm: set CS_MENU_USE_DETENTED_ENCODER to 1 if you are using a detented encoder for the menu cs_menu.inc: the CS_MENU_EncSpeedSet function allows you to totally customize the encoder behaviour - however, changes shouldn't be necessary there Best Regards, Thorsten.

Maybe the syntax is wrong. You can find the error messages and the appr. files/lines in "main.err" Best Regards, Thorsten.

Yes, the PSU is the same (only the colour is different ;-)) Best Regards, Thorsten.

Hi Ilmenator, the additional 7809 is used to shift the +5VDC voltage level to +14VDC. Every SID module still requires it's own voltage regulator to convert this voltage back to 12VDC or 9VDC. Without the 7809 you would get a mixed DC/AC voltage which leads to a 50 Hz hum in the background when more than one SID is connected to the PSU. It seems that this problem is also related to a ground loop, but after I inserted the regulator for a clean DC supply this humming sound is completely vanished :) To confuse you completely: the humming sound doesn't appear when all core modules are stuffed with a seperate 7805 and powered by 9VAC, when all SID modules are powered with 5VDC + 9VAC, and when the ground pins of all voltage regulators are connected together. But I got rid of this circuit due to the power consumption (-> too much heat inside the case). The new circuit brings the best results. I'm using the PSU of a C64-A (which can be seen on the pictures). I guess that PSUs from the followers should also work, if they also deliver 5VDC and 9VAC Best Regards, Thorsten. /edit: we need a FAQMARKER

Since I'm now able to test the synthesizer implementation on a much easier way (thanks of the control surface) and since the upload of code changes takes significantly less time than with the PIC16F (thanks to the bootstrap loader), I'm now able to fix some bugs/imperfections which are annoying me since months :-) Unfortunately these changes will make the sound engine incompatible with V1.4, but I think that they should be done ASAP before the first sound patches are provided by users... (of course, I will also try to integrate these changes 1:1 into the PIC16F firmware) When a LFO is assigned to OSC pitch, the intensity depends directly on the "PitchBend range" value. Higher ranges are leading to erroneous waveforms, since the modulation handler used for Finetune and the Pitchwheel is working with a logarithmic scale. In an excelent book about modular synthesizers ("Synthesizer" by Florian Anwander, I can recomment it) I read that linear frequency modulation should be the prefered method, so I will change the algorithms in this way. the LFO depth->Pitch path will get a logarithmic scale so that it is possible to control the whole frequency range of an oscillator when "depth" is set to the maximum value currently the envelope depth controls only the half range of the modulation target (e.g. of the filter CutOff frequency). It should control the whole range Filter: I noticed that the quality of the 8580 filters is much better when expected! I've programmed some kind of calibration routine which scales the filter value before it will be written into the SID register. The result sounds already better than with a 6581 - I don't want to know how this routine is working with a 6581 (haven't found the time to try this out yet). However, the "calibration" will make the sound patches compatible to both SID derivatives, and it leads to an improved dynamic range :) More about this topic in the next days/weeks ;-) Best Regards, Thorsten.

Hi Zap25, in theory you could change the time base (1 mS) of the shift register handler to any other value, just only the timer1 period register of the PIC has to be modified. But in this case also other routines like the encoder handler, the auto-repeat for buttons, the display message timer, the global timer, etc. would be called more often and this makes the solution incompatible to any other application (bad re-use). Also the CPU load would be significantly increased. Last but not least it has to be taken into accound that MIOS loads the DIN and DOUT shift registers in parallel, this makes it difficult to use the same driver for handling with a button matrix (since for this method the digital outputs have to be preloaded before the digital inputs will be sampled). There is also no reserved memory for more than 128 buttons in the system, so the whole driver cannot use the standard hooks like USER_DIN_NotifyToggle In fact it would make more sense to write a dedicated shift register driver for such a matrix and to connect the registers to spare pins (if available). This driver could be hooked to the USER_Timer (the only standard timer provided by MIOS). The registers which are necessary to save the state of the buttons and maybe also the debouncing timers have to be located into the memory region which is reserved for the application. Best Regards, Thorsten.

Hi Steven, the term "wavetable" is an artefact from the good old C64 days. It has nothing to do with audio samples, but with CC controllers which are played sequently - so fast, that the resulting noise sounds like a new waveform. There is a lot potential in this kind of synthesis, especially when you are able to control any parameter (not only the pitch, the waveform, the sync/ringmodulation switch, but also LFO/envelope/filters and also the wavetable CC assignments and the rate --- really any parameter) like with the MIDIbox SID ;-) Here are four short preset examples: http://www.ucapps.de/midibox_sid/mbsid_wt_demo.mp3 First three sound patches: the wavetable rate (speed) is varried from 0 to 119 Last sound patch: this is one SID playing one patch - it should demonstrate that wavetables are not only usable for C64 like drum sounds. Best Regards, Thorsten.

Thanks Frank, the four points are a nice abstract of my goals. I've also the same oppinion about DIY like you wrote, but I think that I should also clarify what the GPL means: it opens the design also for commercial parties. Pilo: the GPL says that - from the legal point of view - these projects can be distributed, modified and re-used for other projects. They could also be used for commercial products so long as the terms of the GPL are not violated. In fact this means: if a big company would build and sell MIOS based MIDI controllers, they would have to publish all the stuff which is necessary to reconstruct the complete product (with all it's improvements) for free. An improbable Example: if Yamaha would start to build MIDIbox SID clones with cost-optimized PCBs, an improved circuit and usefull application enhancements, they would have to publish the results also under GPL - it would be a benefit for us all. However, Yamaha would never do this, as other companies could use these sources to offer an even cheaper MIDIbox SID for less profit. In theory... the other side of the story is my willing to support people who want to commercialize my projects. As MIDIbox should stay a hobby project for myself, I will spend no minute to give design & programming hints for those peoples - even for a fee, as my sparetime is more valuable than money. I will also not help a user (consumer) who bought a ready made MIDIbox for the same reasons. Robotfunk: please don't take this statement as personal attack against you (I played with your software a time ago, it's a really usable and mighty tool! :-)) - I will just prevent any additional effort for myself before a "go" decition triggers an avalanche of requests from other interested parties (I refused all requests successfully in the last years). If you want to sell MIOS based controllers, then do it, but please don't expect any support from my side, and make all the project sources free available. Steve: what you are doing is 100% accepted from my side so long as you help these people if they notice problems with the design. One last statement to this issue (summa summarum): I don't like commercial MIDIbox products and I will ignore any request, but the GPL allows others to sell ready-made MIDIboxes under the circumstances which are listed under http://www.gnu.org/copyleft/gpl.html To the first question - I don't see the possibility for a MIDIbox Convention in the next months, especially because we are spreaded other the whole world (think about the traveling costs... ;-)) but maybe we could try an online conference via IRC or a tool like Netmeeting one day. :) Best Regards, Thorsten.

Age: 0x1e ;-) Other RPGs: no. In fact I never played Avalon, I'm just only one of the administrators and programmers ;-) (but I'm not active anymore). We started this MUD 1994. It was a great time, I learned a lot about the internet, object oriented programming, teamwork and topics like "find a bugfix as fast as possible so that the 3-head firedragon doesn't eat up so much players during lunchtime" ;-)) Best Regards, Thorsten.

No, I'm still at home ;-) Best Regards, Thorsten.

Unfortunately not - the sound chip of the VC20 (called VIC) is very primitive compared to the SID and it isn't compatible. Best Regards, Thorsten.

Hi Nat, yes, the enc_example3 shows how to drive up to 64 LED rings. Of course, the same routine could also be used for MIDIbox TC, although only one LED ring should be driven :) Best Regards, Thorsten.

My advice: don't use MPLAB as it makes everything more complicated than required ;-) The main.asm file can be assembled directly with MPASM: MPLAB IDE/MCHIP_Tools/mpasmwin.exe Just click on this program (make a shortcut on your desktop) and load the main.asm file. The result will be a "main.hex" file which can be converted within the DOS shell by executing "convert.bat" (Perl must be installed) to a main.syx file. The source files (main.asm and all *.inc and *.h files) are editable with your favourite text editor. I prefer emacs, but there are also some other usefull editors especially for Windows available on the net. Especially "code highlighting" is an important feature, so that comments can be regognized easier. Best Regards, Thorsten. P.S.: Ian - I've received the encoders last week - thanks again!! :)

Yes Ilmentor, and this jitter will be especially appear in the region where the output curve of the logarithmic pot has it's highest increase rate where a sampled voltage value changes between 4V and 5V without moving the pot. However, the implementation of a scale table is very simple, especially if only 7bit values should be converted. Insert a table into your source code with 128 values: Conversion_Table db 0x7f ; value #0x00 db 0x7e ; value #0x01 db 0x7d ; value #0x02 [..] db 0x01 ; value #0x7e db 0x00 ; value #0x7f Now you can convert a pot value in this way: ;; 7-bit pot value saved in TMP1 ;; move converted pot value to TMP2 TABLE_ADDR Conversion_Table movf TMP1, W ; get pot value 0x00-0x7f TABLE_ADD_W ; add WREG to table pointer tblrd*+ ; read from table movff TABLAT, TMP2 ; copy table entry to TMP2 Best Regards, Thorsten.

yes, thats correct. But you should use capitalized letters for all constants (register names), just for consistency reasons. Migration of MB64: I'm unsure, although it wouldn't take longer than one day, it's just a low-priority task for me. It could happen in one week or in one month... Best Regards, Thorsten.

No, in the PIC16F solution the menu buttons are not free assignable, only the MIOS based application will provide this feature (and it will allow to control the button functions also via MIDI for remote control :)) All other buttons are 100% free assignable, so a diagramm isn't really necessary. However, this schematic helps to locate the menu buttons: http://www.ucapps.de/mbhp/mbhp_dinx4_32buttons.pdf Best Regards, Thorsten.

Ok - so when I have nothing else to do I will try it out by myself in order to ensure that it really works. Best Regards, Thorsten.

Cool! This saved my day! ;-) Best Regards, Thorsten.

Hi Sephult, is your core unit running in the meantime? Another user reported exactly the same problem, but we were not able to locate the root cause. It could be the MIDI interface of your PC or a bad soldering on the PCB - i'm unsure. The XTAL shouldn't be a problem if you were able to upload MIOS once. Even more a short circuit somewhere? In the MIOS download section you can now find a CRC test program which calculates an overall checksum over the operating system range. If you are using it with the most recent MIOS V1.3 (which has been updated in the meantime), you should see the value "FD45" on the LCD screen. It might also help to increase the SysEx output buffer size to 2048. This change is (for example) required for the MBHP USB module due to a bug in the microsoft USB driver which inserts some zeroes into the stream if it doesn't fit into one buffer. Best Regards, Thorsten.

Hi Pay, a different device ID doesn't change the checksum. But ok, you found your solution :) Best Regards, Thorsten.

Hi LO, MIDIbox MF V1.000 was the very first firmware which provided the MIDIbox Link feature, I'm not sure if this was the final solution. The last combination which I've tested some months ago was http://www.ucapps.de/midibox/midibox64_v101b.zip and http://www.ucapps.de/midibox_mf/midibox_mf_v1000pre3.hex.zip MIDIbox MF was the forwarding point, MIDIbox64 the endpoint. If you are already using these versions: do you see the same invalid MIDI events when the position of the boxes in the MIDI chain are exchanged? Best Regards, Thorsten.