TK.

Hi Jess, beside of the new chip, no additional hardware changes are planned. Just only extensions (like controlling a second MBHP_SID board from a single core). I've read your proposals, they are good and I have to think about how to combine them with the other ideas and requirements. Once I've a clear picture, I will enhance the wishlist To point 5: this is already possible by enabling the "E2P" sound engine option (CC#111 = 0x04), and by synchronising envelopes to the MIDI clock (CC#125 = 0x04) The sound engine option is an immediate solution to keep the MBSID V1 engine compatible, with the overworked MBSID V2 engine(s) such special features should be considered from the beginning, and therefore it will be easier to find them Best Regards, Thorsten.

Hi Jess, welcome aboard, I'm very glad to hear from you after so long time! Just two weeks ago I highlighted again the importance of the curve parameter (with an explicit hint of the originator of this algorithm -> http://www.ucapps.de/howto_sid_bassline.html) :-) Current situation: MBSID V1 will only get minor changes in future due to various reasons, e.g. code and patch memory allocation. But with MBSID V2 all concepts will be overworked (see MBSID Wishlist posting, which you've already discovered - more about this topic there) - which means: than more ideas are discussed now, than better the chance to get this into the next major redesign. So, you are joining this forum just in time! :) My thoughts on your proposals: yes, a dedicated envelope with analog output would be the best solution for MBSID V2. Currently it would only be possible to introduce a new "sound engine option" (4 bits are still free) in order to enable a path from a selected envelope (e.g. ENV2) to the volume register, or to an analog output (-> MBHP_AOUT_LC module). Modulation of the volume register could already be tried out with a small number of lines. I will try it this evening just to get a feeling about the benefit and post the required code here. Note that the resolution is 4 and not 8 bit, however, we will see.. But as you already mentioned, an external VCA would be the best solution - especially if it has a log characteristic (to match with the dB damping and to decrease the required resolution). Here you can find a schematic for this concept http://www.midibox.org/users/kd/kd_fmsid.pdf but nobody tried it out so far. To the filter calibration: so far I understand your suggestion, this would only require a linear scaling routine, and not a table (which would consume too much memory). Thanks to the hardware multiplier, it shouldn't consume so much execution cycles (see math_mul16_16.inc), I will give it a try, but would need the help from some people who own different SIDs Best Regards, Thorsten.

Alright, so maybe you forgot to configure the Y offsets in the application? -> http://www.ucapps.de/cmios_fun.html#MIOS_LCD_YAddressSet Best Regards, Thorsten.

FFs are Flip Flops... Seems that I mixed the RGB idea with the LED touch detection. However, here you can use shift registers as well, so long they can be switched into high impedance state (e.g. 74HC595: OE# pin). This will require a second chain of input registers (e.g. 74HC165) - a lot of hardware, but still less expensive than multiple microcontrollers. Also speed is no issue, since the LED capacitance is discharged very slowly (according to the basic example > 1 mS) Best Regards, Thorsten.

Hi Steve, yes, this is a bad idea, because it will add some more digital noise to the 12V voltage domain. Therefore it's better to handle these two domains strictly seperated like you can see in the optimized PSU schematics (there are also some hints in the .pdfs which are worth to read). However, so long no LCD backlight is connected, I guess that the 7805 won't get that hot Best Regards, Thorsten.

The biggest problem is the high power consumption - too much for the Micro, therefore a 4051 (transmission gate) won't help, some FF or SR would be better, and I guess that you can easily service 200 or more multicolour LEDs from a single core with an update rate of less than 1 mS (and I guess that such a high update rate is not really required) Best Regards, Thorsten.

Hi Thomas, yes, everything is correct. You could upload the MBSEQ V2 firmware just to check if you didn't made any error during the software reconfiguration. Best Regards, Thorsten.

There is a hardware reset at MCLR# (PIC Pin 1) which you could try - just tip it to ground. Maybe it would already help to enlarge the reset time by adding a cap (100 nF or higher) against ground, and to increase the resistor value from 100 to 10k Best Regards, Thorsten.

Ikea? Just kidding ;-) Have you already searched in the local Praktiker or Obi store? Best Regards, Thorsten.

From my side it's ok when you open new threads for ebay findings, or when you are discussing about things in this forum which are not related to MIDIbox topics so long it's done in this Misc. section - it can be easily masked out in the search function of this forum, so that the postings don't appear in the result list. Moebius: ok, now we know your oppinion, but please avoid this offensive articulation in future. This should stay a friendly forum, and I guess that you know the netiquette very well, so that I don't need to repeat it! Best Regards, Thorsten.

You can find a circuit in the troubleshooting section which allows you to test the 6N138 without MIDI: http://www.ucapps.de/howto_debug_midi.html (search for mbhp_core_opto_test) The used resistor values of the core circuit are working, you don't need to try other values Best Regards, Thorsten.

MIOS itself only provides a redirection to the IIC MIDI Out, for MIDI In the changes have to be made at the application side, since the MIDI streams have to be merged properly (see MIDI router project). I don't plan to integrate merging of IIC_MIDI streams into MIOS, since depending on the use case different strategies are required - all the variants would unnecessarily blow up the code. This doesn't make much sense: First of all, this would increase the code size of the 1st level bootloader, so that it wouldn't fit into the 1k range anymore. Second: the IIC MIDI In is not so performant like the internal EUSART, the optimized polling method would require an additional IO connection which is not possible with most (main) applications (or I would have to reduce features) Third: there is no (known) bug for the internal EUSART Rx input, therefore it can be used without problems. So: the MIDI Input of the MBHP_IIC_MIDI module will only be used by special applications like the MIDI router project. Best Regards, Thorsten.

It will work without problems, you don't need to change the software settings Best Regards, Thorsten.

in main.asm ; define the display size you are using: ; 0: 2x16 ; 1: 2x20 ; 2: 4x16 ; 3: 4x20 #define DEFAULT_LCD_SIZE 3 [/code] und wahrscheinlich: [code]#if DEFAULT_LCD_SIZE == 3 ; 4x20 #define DEFAULT_YOFFSET_LINE0 0x02 #define DEFAULT_YOFFSET_LINE1 0x42 #define DEFAULT_YOFFSET_LINE2 0x82 #define DEFAULT_YOFFSET_LINE3 0xc2 #define CSMD_YOFFSET_LINE0 0x00 #define CSMD_YOFFSET_LINE1 0x40 #define CSMD_YOFFSET_LINE2 0x80 #define CSMD_YOFFSET_LINE3 0xc0 #endif falls das nicht funktioniert, muesstest Du selbst weitertuefteln (try&error) Gruss, Thorsten.

Hi Michael, yes, there is a better method: don't use a lookup table, but just calculate the address directly, it's: (unsigned int)patch << 6 In addition, you could organize the data structure in RAM in the same way like it should be stored in BankStick. By doing so, you can use the MIOS_BANKSTICK_WritePage function in order to store the whole patch at once (a page consists of 64/0x40 bytes). The advantage of a page write operation is, that it takes appr. the same time like writing a single byte (see 24LC256 datasheet for the timings, so far I remember it was appr. 4 mS) - so, at the end a page write works 64 times faster! Best Regards, Thorsten.

tippe in der Suchfunktion "kx driver update" - mehr Details sind nicht bekannt. Gruss, Thorsten.

Fein :) Koenntest Du bitte Michael ueber dieses Problem informieren? Es besteht die Gefahr, dass noch mehr fehlerhafte Boards rausgehen (wenn es nicht bereits geschehen ist... :-/) Gruss, Thorsten.

How did you connect the PSU? Best Regards, Thorsten.

Hope that you don't fry your SIDs in the same way :-/ Best Regards, Thorsten.

MIOS is a text adventure, keep trying ;-) Best Regards, Thorsten.

It's better to set the DEFAULT_DIN_MENU_* values to an invalid pin number >= 128 I don't understand part 2. The midibox64e.ini file is a configuration file, the resulting .syx contains the configuration data which can be sent to the MIDIbox64E firmware. You don't need to rename it, you only need to follow the steps which are described in the readme The main.syx within the application package is a converted memory image of the application code (old and expired method to upload code, ignore it) Best Regards, Thorsten.

Yes, it will work without any additional circurity. But if you don't see the empty bar line, then propably some connections are wrong - you have to double check this. And I hope that a wrong connection didn't destory the LCD, this can happen very fast! Maybe the contrast pot of the other core modules is not adjusted? However, please don't try this, check the wiring first! Best Regards, Thorsten.

Hallo Joscha, auf Anhieb wuerde ich sagen, dass die beiden markierten Stellen etwas kritisch aussehen. Ich bin mir nicht sicher, ob es sich hierbei um Flussmittel, oder leitfaehiges Material handelt, doch Du koenntest es einfach mal mit einem Schraubenzieher wegkratzen. Wenn das nicht weiterhilft, waere es interessant zu wissen, ob die Buttons funktionieren, wenn entweder die SCLK, oder die RCLK Leitung nicht am zweiten DOUTX4 Modul angeschlossen ist - so wuesstest Du, welche Leiterbahn nochmal genaustens untersucht werden muss. Manchmal kann selbst ein kaum erkennbarer Loetklumpen zwischen den Leiterbahnen zu einem Kurzschluss fuehren... Die 300 mA sind ein bisserl wenig. Kurzes Rechenbeispiel: an den LEDs fallen ca. 1.8V ab, es werden 220 Ohm Widerstaende verwendet, macht ca. 15 mA pro LED. Bei 64 LEDs liegt der maximale Stromverbrauch bei 960 mA! Und falls ein LCD mit Backlight angeschlossen ist, kannst Du nochmal ca. 200-300 mA draufrechnen, und fuer die restliche Logik (dazu gehoert auch der PIC) nochmal 50 .. 100 mA Ein zu schwaches Netzteil kann durchaus zu seltsamen Effekten fuehren, doch wenn die SRIO Kette bereits ausfaellt, wenn ein unbestuecktes DOUTX4 Modul angehaengt wird, dann vermute ich (nach wie vor) eher einen Kurzschluss. Gruss, Thorsten.

these are not valid MIDI events, they violate the MIDI spec. E.g., FA is a single byte event which doesn't touch the running status. By sending FA 01 02, MIOS (and any other properly implemented MIDI device) will interpret this as FA <last-running-status> 01 02. This explains, why you are sometimes getting more bytes than expected. For more informations regarding the running status, google for "midi spec" For intercom messages I would propose to use proper SysEx streams. They begin with a F0, they end with a F7. The bytes within this stream must be <=0x7f (8th bit always 0) Best Regards, Thorsten.

do you see a black bar at the upper line for 2 seconds, thereafter an empty screen, thereafter those short flashes? Best Regards, Thorsten.