TK.

Hi Che, 11.8V are ok, nothing to be worried about :) Best Regards, Thorsten.

Thanks! :) I don't want to start a seperate filter project, my analog skills are low, and there are a lot of functional circuits available in the web. The CA3080 is still available, but very noisy. A multi state filter based on the LM13700 gives better results (I built it some years ago, unfortunately I've no idea where in my flat (or possibly in the cellar?) I can find this board. ;-) However, a Moog cascade filter can be build with common general purpose transistors, just only the resistor values have to be adapted. I will start a new MIDIbox SID analog extensions page in some weeks and add some links to other websites which are specialiced on analog DIY stuff DrBunsen: yes it's possible to replace the 15 select buttons by a matrix of 64 buttons, but this requires some (rel. simple) changes in the firmware. However, I prefer the existing solution, because it's smaller. It doesn't make a big difference from the ergonomic point of view, because mainly you want to see which modulation sources are linked to the targets, the buttons are only used for the configuration, and this will normaly not be changed that much during a playing session. On the other hand: this control surface is not the ideal solution for everybody, our workflows are too different - other variants are welcome! :) Hope to see some nice cases, but especially to hear some great SID tunes in the next weeks/months! :) Best Regards, Thorsten.

Pan control will be possible with the AOUT extension :) In the meantime I've revised the PSU circuit for the best signal/noise ratio. No 50/60 Hz hum and no digital HF noise in the background anymore. http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf Results: no heat source within the case anymore, since the +5V are regulated by the external C64 PSU 6581: -76 dB signal/noise ratio 8580: -90 dB signal/noise ratio (CD quality!) Please don't ask if your own PSU variant brings the same results - it was a long try and error session until I found out this solution ;-) Best Regards, Thorsten.

In the meantime I found some time to continue with the case. But there are still some issues which have to be solved: due to the 9V output voltage of the C64 PSU and the high current consumption caused by the LEDs and the backlit display, the 7805 gets extreme hot and therefore requires a big heatsink (or just a large metal plate) I haven't found a good solution for mounting the Audio & MIDI plugs, as well as the USB socket at the backsite yet there isn't so much room in the C64 case for more extensions anymore However, here a snapshot of the current status: I've also created a first demo, it's a remix of an older song originally arranged with MIDIbox64SEQ and an AN1x synth. In the remix everything you hear (beside of the Synth Toms in the background ;-)) comes from a MIDIbox SID . Not all sounds are played at the same time, the tracks have been recorded successively. See^H^H^HHear http://www.mp3.de/frequencies "Floating Sequences (SID remix) Part I" I'm not very satisfied with the results... the new (more powerfull) sounds and the old sequences are not really matching - just because the original composition hasn't been made with a MIDIbox SID ;-) Part II is planned, and this demo should give an impression of a new feature: an external Moog filter! I'm in contact with Dirk Lindhof who has a lot of experiences with modular synths - here a link to his homepage http://www.msc175.de/. He will send me a PCB of his 24db Moog filter module in the next days. The MIOS based MIDIbox SID (later also MIDIbox64SEQ) will support an interface function to the MAX525. This DAC provides 4 analog output channels with 12 bit resolution, it will supply the control voltage (CV) for any external extension. Of course, the 4 channels will also be integrated into the modulation matrix, and they will be controllable via CC :) Best Regards, Thorsten. P.S.: StepC is available for download...

Hi Pilo, yes, with a 74HC47 and some modifications in the application specific handler up to 24 digits could be driven by one DOUTX4 module - good idea! Best Regards, Thorsten.

Panel & Case nearly finished - update :) Best Regards, Thorsten.

DriftZ has finished his second sequencer, see: http://users.pandora.be/DriftZ/DriftZ_MBHP_pics.html "just" another MIDIbox of the week. The case is really ergonomic :) Best Regards, Thorsten.

I'm hoping that this doesn't lead to a star cult and I'm still able to visit an exhibition without sunglasses ;-) if you are interested - some pictures of me which have been made in former times can be found under http://avalon.mud.de (click on "Treffen", search for "avatar"). However, I'm not a photogenic person ;-) Since 4 years I'm employed as Design & Verification Engineer for 16 and 32 bit microcontrollers (C16x and TriCore family) at Infineon Technologies. As I'm not working with ready-made silicons in my job, but mainly with simulation models which are implemented in VHDL or Verilog and which are running on a huge compute farm, the MIDIbox project is the perfect compensation for myself to gain my experiences with "reallife applications". :) not yet ;-) the complete migration of all existing PIC16F projects to MIOS, the release of MIOS under http://www.sourceforge.net, some analog extensions for MIDIbox SID, getting inspired by your suggestions and picking out some interesting stuff for myself. Bicycling, rambling, traveling around the world :) I'm still a human ;-) Best Regards, Thorsten.

Hi Jeroddumas, you have to store the button state in a register, it has to be inverted every time the button is pressed. Possible modification for the AIN64_DIN128_DOUT128 application (untested) - replace USER_DIN_NotifyToggle ;; a button has been pressed or depressed. ;; Send value which has been defined in MIOS_MPROC_EVENT_TABLE ;; save button number in TMP3 - we use it later to print out a message movff MIOS_PARAMETER1, TMP3 ;; save button value in TMP4 movff MIOS_PARAMETER2, TMP4 by: USER_DIN_NotifyToggle ;; a button has been pressed or depressed. ;; Send value which has been defined in MIOS_MPROC_EVENT_TABLE ;; don't continue if button has been depressed IFSET MIOS_PARAMETER2, 0, return ;; toggle button state btf BUTTON_STATE, 0 ;; save button number in TMP3 - we use it later to print out a message movff MIOS_PARAMETER1, TMP3 ;; save button value in TMP4 movff BUTTON_STATE, TMP4 the BUTTON_STATE variable has to be located to a free address in app_defines.h If you want to use more than one toggle button, you could store up to 8 states in this register: USER_DIN_NotifyToggle ;; a button has been pressed or depressed. ;; Send value which has been defined in MIOS_MPROC_EVENT_TABLE ;; don't continue if button has been depressed IFSET MIOS_PARAMETER2, 0, return ;; save button number in TMP3 - we use it later to print out a message movff MIOS_PARAMETER1, TMP3 ;; toggle state of button 0 to 7 movf MIOS_PARAMETER1, W ; get button number call MIOS_HLP_GetBitORMask ; get mask - here for XOR (invert) function xorwf BUTTON_STATE, F ; invert the appr. flag ;; set TMP4 (the button value) depending on flag setf TMP4 ; by default it's set (0x00 will be sent) movf MIOS_PARAMETER1, W ; get button number call MIOS_HLP_GetBitANDMask ; get AND mask andwf BUTTON_STATE, W ; mask out the appr. flag skpz ; skip if flag is zero clrf TMP4 ; else clear TMP4 (0x7f will be sent) More than 8 buttons w/ toggle function can be realized with an array. And if you want to select the toggle function, you need to add a "enable" flag. However, the upcoming migrated MIDIbox64 application will support this on a more comfotable way :) Best Regards, Thorsten.

Hi Lo, which firmwares are you using exactly? Best Regards, Thorsten.

Hi Chriss, thanks! :) before I have to burn the code into my PIC16F in order to check the settings, could you please ensure that you've downloaded the correct .zip file? Some webbrowsers don't regognize that a file with the same name has been updated, so possibly you've got the old file from the file cache. The new firmware has following timestamp: Jun 24 19:39 midibox_sid_v1.4_to_com.hex Sorry for the circumstances, but I'm not able to burn a PIC16F877 under Linux anymore (no driver for the JDM, and the new PICstart firmware doesn't work with picp) Best Regards, Thorsten.

Hi Pilo, do you have a link to the pin description? Best Regards, Thorsten.

Just use the USER_SR_Service_Prepare hook which is called periodically before the DOUT registers are loaded. The update frequency is 1 mS by default. Example: in app_defines.h following variables have to be assigned to free addresses: DOUT_LED_CTR - a counter which will be incremented on every update cycle DOUT_LED_FLASH_ENABLE - this register holds the information if the LED should flash or not. Up to 8 flags for 8 LEDs can be stored here, if more flags are required, an array should be used (not shown here) Code (untested, but should work) USER_SR_Service_Prepare LED_FLASH_Handler ;; increment counter incf DOUT_LED_CTR, F ;; skip next block if LED should not flash IFCLR DOUT_LED_FLASH_ENABLE, 0, rgoto LED_FLASH_Handler_Skip0 ;; skip if DOUT counter < 128 (bit #7 not set), this leads to a ;; flashing frequency of 1 / (128 * update_cycle) = 1 / (128 * 1 mS) = ca. 8 Hz IFCLR DOUT_LED_CTR, 7, rgoto LED_FLASH_Handler_Skip0 ;; get value of LED at DOUT #0 movlw 0x00 call MIOS_DOUT_PinGet ;; result in MIOS_PARAMETER1, invert it comf MIOS_PARAMETER1, F ;; write back result to DOUT #0 movlw 0x00 call MIOS_DOUT_PinSet LED_FLASH_Handler_Skip0 ;; thats all return Best Regards, Thorsten.

Hi, I haven't sent the layout to Mike yet, I will do this now. Best Regards, Thorsten.

I just took the cheapest shottky diodes which are available at Reichelt. ;-) I guess that shottkys with I_tot=0.25A should also work Best Regards, Thorsten.

Alright - no there won't be a difference. Although the application sends messages to SID3 and SID4 sometimes, it won't stall if the appr. slave cores are not connected to the master. Best Regards, Thorsten.

Yes, this is the simplest solution, because the PIC16F firmwares are very static and don't allow so much possibilities like MIOS Best Regards, Thorsten.

Jeweils 8 Motorfader benoetigen bis zu 1A Gruss, Thorsten.

Hallo Jack, ich habe Deine Mail gleich dreimal erhalten, mir war mir allerdings unsicher wo ich die Library am geschicktesten ablegen koennte. Nun habe ich sie erstmal unter Concepts->MBHP->DIN abgelegt. PIC fuer mehrere GLCDs/CLCDs: hier musst Du schon genauer sagen, welches Setup Du Dir vorstellst und was alles angezeigt werden soll. Ich kann uebrigens nur den PIC18F452 supporten, und die anderen PIC18F sind nicht unbedingt kompatibel. Gruss, Thorsten.

Hi Pascal, I thought the answer to matteo made it clear? http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1056228215 2 SIDs driven by one core module: not this year. CS and 2 SIDs option: not possible. From another posting: up to 8 BankSticks will be supported. Best Regards, Thorsten.

I think the timings are more relaxed when you take the required transfer time of a MIDI message into account. A three byte MIDI event requires 960 uS - nearly one milisecond. This means that the BankStick is 10 times faster than the transfer itself. Note also the MIOS provides a 48 byte transmit buffer which relaxes the timings even more, since in this way the bytes are sent in background and your application can continue to read from BankStick or to calculate the next events (I read that you plan some interpolation features for CC events...). I also don't think that your code has to read so much data from the BankStick during every MIDI clock when everything which is time critical is stored in RAM. The planned MB64seq port for example will be implemented in a different way compared to the PIC16F solution, but will work with a better performance. Of course, the possibilities will not be so powerfull like your plans, but I guess that the principle method, the skeleton will maybe open your eyes. I've planned to realise it in following way (this is only a short abstract from my ideas, if I would have to write all ideas, it would be faster for me just to program the assembler code in order to "document" what I mean --- and every time I have to write more details, the day of release will be more delayed ;-)): either the USER_Timer or the incoming MIDI clock triggers the sequencer with 24 ppqn (note: higher resolutions should also be possible). The timer itself doesn't process the sequencer data at the same time, but only notifies to the main program that the pulse should be processed "as soon as possible". The main program checks if the sequencer has been triggered as often as possible. This handler will be called from USER_Tick - this hook is triggered ca. every 5-50 uS (microseconds) if nothing else is to do (no button event, no encoder event, no pot event, no MIDI event, no display event). If - for example - a button function has to execute a long running part of code, e.g. if it has to write something into the BankStick, the sequencer handler can also be called during every single write operation. In this way extreme low latencies are guaranteed without any OS overhead. What will the sequencer function do: anything you want ;-) Mainly it will handle with a lot of delay counters, once a counter reaches zero, any action will be performed - sending MIDI events from BankStick or derived from RAM variables, or whatever... Best Regards, Thorsten.

Hi Duggle, especially based on your (yes, really!) idea with character offsets I integrated a special function into MIOS called "MIOS_LCD_YAddressSet" (see the documentation) - one advantage of this function is that it allows you to shift a 2x16 screen to the middle of a bigger LCD However, the interface to MIOS functions can be found in mios_vectors.inc, to user functions in user_vectors.inc A MIOS function can be overloaded by disabling the appr. entry in mios_vectors.inc and by adding a replacement with the same name into the application. Best Regards, Thorsten.

Good that you've identified Vss and Vdd, so the others pins should be in the same order like known from the Displaytech, I never saw a display with a different order yet (except those displays with a 2x8 pin header). So it's maybe a good idea to check the tracks on the core module, too - when you read the last postings you will notify that users mostly have problems with these pins (exchanged wires or bad solderings) Did you already ensure that the box is running? Does it send any MIDI data? Best Regards, Thorsten.

So far as I know vmidibox doesn't provide the MB-Link protocol - or does it? Serge? Best Regards, Thorsten.

Now you will find the .hex file in the official mios_v1_3.zip package. I'm a little bit carefull with this file as the ".hex" extension implies for an unexperienced user (who normaly never reads a README) that this OS release has to be burned directly into the PIC. But thats not the case - never use IC-Prog to upload the OS, since this would remove the first level bootstrap loader. Regarding the device ID: I'm not sure, but maybe you don't know that the device ID of the MIDIbox SID application has to be changed in order to get the multisetup running. The MIOS device ID is a different value which is mainly used for firmware uploads. In other words: the MIOS device ID identifies the core module, the MIDIbox SID device ID identifies the SID The reason why others didn't notify this "problem" is possibly that they are using a PIC16F for the slaves... the PIC16F solution doesn't provide a specific device ID Best Regards, Thorsten.