TK.

You will see a 12 MHz sinewave. Not the voltage, but the frequency is too high for your soundcard (I guess that the sample rate isn't higher than 96 kHz?) If it is a reset problem (after reading your postings again, it seems to be the possible root cause - removing the jumper will cause a short reset pulse, the chip will reboot, windows regognizes it, but after a short time the chip will brown out due to missing power...) then you could try the following: use a short cable, connect it with 3.3V, and tip it for a short time on Pin 13 of the AN2131SC (or better: to the connection between C3 and R27). This should cause a reboot. The powerr jumper must be closed of course... If this helps, then maybe the C3 value I've selected (100 nF) was too optimistic, and I have to change the specs to a 1 uF or 10 uF cap Best Regards, Thorsten.

Hi, I can only say, that merging the two projects isn't so easy, since there are name conflicts. A proper solution would be a MIOS replacement just for simulation, but nobody created this yet Best Regards, Thorsten.

Hi Matthias, this is really strange, because it seems, that your USB module is powered from anywhere else? Are you using the MIDIbox-Link port(s)? In this case please ensure that the +5V lines at J8 and J9 are not connected to the core module. In order to exclude all source of errors, it's better to do the first test without any MIDI connection. Another question: which Windows version are you using (WinME, Win2000 or WinXP)? Best Regards, Thorsten.

yes, in addition you have to connect the clock line of the shift registers to another PIC pin, see also the note in this interconnection diagram: http://www.ucapps.de/mbhp/mbhp_sid_c64_psu.pdf Best Regards, Thorsten.

Yes, the MCLOCK_BPMSet() function is the right one, because it's always called when the BPM rate is initialized or modified. With "bpmCC = (unsigned char)value" you are trying to access a variable (name: "value") which doesn't exist. But without loosing too much words: it's really not required. Just write MIOS_MIDI_TxBufferPut(bpm - 80) instead of MIOS_MIDI_TxBufferPut((unsigned char)value); Best Regards, Thorsten.

Hi Alex, the LFO values are 16bit values, which are stored in a special structure. Without loosing too much words (because I think that the data structure is obvious): with movff SID_LFO1_BASE + SID_LFOx_RVALUE_H, WREG you will copy the high byte of the LFO1 output value into the working register with "clrc" and "rrf WREG, W" you can shift it to the right in order to get a 7bit value, which could be transmitted via CC Best Regards, Thorsten.

me too... for all 8bit processors I know this statement is not true. E.g. assembly language allows a totally different use of data memory, the code can store and access informations much more efficiently than a C compiler would ever allow. A more explicit example: C stores temporary variables on a stack, and stack operations consume a lot of cycles. In assembler, you can define your own set of temporary variables, and you have to manage resource conflicts by yourself. This also means, that such optimized data structures are mostly not relocatable, and hard to modify - but they are powerful! On the other hand: the architectures of modern 32bit CPUs provide a huge instruction set to support C compilers. There are so many possible variations for different situations, that on large projects a C compiler mostly creates a better/faster code than you could ever program in assembly language (within the same time). And another point: for finding new algorithms the use of high level languages definitely makes sense to save time, but if CPU load and memory consumption does matter, the job is not finished once the algorithm is working - the next step is to translate it into handwritten assembly code. Best Regards, Thorsten.

Hi Michel, in principle the code looks ok, but you don't need the bpmCC variable. It's even not required to convert this value into a different number format, because hexadecimal and decimal are just different forms to display/input values, but both will be translated into binary numbers by the compiler/assembler. One thing which should be considered is, that you have to take care for underruns. The clockbox provides BPM rates from 48 to 255. this means, as soon as the BPM are less than 80, you will get a negative result. For an "unsigned char" this means, that the result will be >=128 (since there is no sign), and such a value should not be sent as 3rd byte of a CC, since it violates the MIDI protocol (only values between 0 and 127 are allowed). So, you could add an if condition which ensure that values <80 and >(80+128) are not sent Best Regards, Thorsten.

Hi Ilmenator, yes, there are changes, they are described here: http://www.ucapps.de/mios_v1_7_hardware_mods.html Best Regards, Thorsten.

Hi, J1 is a power output socket, don't close it, because this will cause a short circuit. Or do you mean the nameless socket, which is close to the USB socket? This one must be closed, otherwise the module won't be powered. Strangely this doesn't match with your description, therefore I'm a little bit confused. Could you please describe the problem in other words? Best Regards, Thorsten.

Hi Dan, the links are not working (propably because these are temporary URLs), to which part # are you refering for? Best Regards, Thorsten.

The shift registers (SR) used to control DIN events can be mapped to the 16 shift registers, which are provided by MIOS. If all 16 shift registers are allocated by rotary encoders, then they cannot be used for "button inputs" (of cause...) - so there are many constraints which have to be taken into account, unfortunately nobody has written a graphical main.asm configuration tool yet ;-) therefore there is no other way than reading the details in main.asm Best Regards, Thorsten.

I guess that the OPL3 is part of one of the ASIC chips, so: no documentation, no chance to get use of it. But it's interesting, that the YAC512 stuffed. Propably because it's a mixed signal design... Yes, you have to hunt for a second card Best Regards, Thorsten.

Hi Dave, alright, so it seems that with v1.7a it's not possible to save the patch if no BankStick is connected (or in your case: regognized). I remember that this issue was reported long time ago. Some hints for debugging: check the 1k resistor, and especially the isolated cable between J4:SC and Pin #28 (!!!) of the PIC (it was pin #22 in older MIOS versions). The SID will output a sweeped sound once it detects the BankStick. The first time it will propably format the Stick, this will take ca. 1 minute. During formatting, you will here some beeps Best Regards, Thorsten.

Hallo, dieses Thema hatten wir vor ein paar Tagen schonmal: http://www.midibox.org/forum/index.php?topic=6051.0 solange die Baudrate bereits stimmt, kannst Du die ID auch mit der change_id Applikation aendern Gruss, Thorsten.

Du haettest die vorderen Buttons um 90° drehen koennen, dann waeren die verbreiterten Loecher nicht noetig gewesen, und die Buttons wuerden auch besser sitzen. Falls Du den entspr. Aufwand nicht scheust, koenntest Du die Buttons nochmal abloeten, und woanders auf die Platine hinsetzen - es lohnt sich :) Tja, das war besonders tricky: die 3 Module sind auf Pappe geschraubt, dann habe ich mir aus dem Baumarkt ein paar Halteklippse besorgt, welche man normalerweise zum Montieren von diesen Alu-Gardinenstangen hernimmt. Die Klippse sind mit Superkleber befestigt, die Module habe ich einfach druntergeschoben. Das haelt nun seit zwei Jahren ziemlich gut: das zweite DOUT Modul befindet sich unter der Modulationsmatrix - ich habe es ebenfalls mit diesen Klippsen befestigt, als Isolierung dient ein Flachbandkabel zwischen DOUT und der Buttonplatine. Zusaetzlich habe ich noch Widerstaende durch die Bohrungen gesteckt, und mit der Buttonplatine verloetet - sitzt, wackelt und hat Luft ;-) Links unten siehst Du uebrigens ein Reichelt-Tuetchen, in dem ich das DINX1 Modul versteckt habe... (diese Bilder beweisen, warum ich mit der MBSID niemals in Produktion gehen sollte ;-) Gruss, Thorsten.

Maybe the crystal is not connected properly anymore? Best Regards, Thorsten.

Hi, yes, you can chain as many modules as you want, see also http://www.ucapps.de/midibox_link.html The last core in the chain has to be configured as "MIDIbox Link Endpoint", the other ones as "MIDIbox Link Forwarding Point". In MB64, this can either be done from the LCD menu (but this requires, that each core has connected a dedicated LCD), or from Serge's Editor, or from a .syx created with the mk_syx script Best Regards, Thorsten.

Hi Dave, yes, you are right. Pressing the third button should save the patch, and it should especially not hang up. Not sure if this was an imperfection in v1.7a (nobody reported it before), but could you please try the same with v1.7303beta? -> http://www.midibox.org/forum/index.php?topic=6098.0 #B stands for Bank, #P for patch It only works properly when a BankStick is connected Best Regards, Thorsten.

Ok, one last feature (the last version was not cool enough ;-)): [tt] o each second LFO now provides a Sample & Hold functionality when switched to random mode. LFO2, 4 and 5 hold the waveform of LFO1, 3 and 5 for each period run. Example: - in the modulation matrix, enable LFO2 modulation for the Pitch of OSC1 -> this is the S&H output - set LFO2 to random mode, Rate=70, Depth doesn't matter - set LFO1 to sine or random mode, and vary Rate and Depth [/tt] -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta12.zip Best Regards, Thorsten.

Hi Julian, I know the anoying delay bug, it was fixed in one of the last v1.7303 releases. The interesting point is, that you are the first guy who reported this ;-) Random function: you are absolutely right, random gets powerful with Sample&Hold, therefore I've added this feature to v1.7303beta12 -> http://www.midibox.org/forum/index.php?topic=6098.0 Best Regards, Thorsten.

Frage lieber Admir, ich denke mal, dass es in seiner Gallerie am besten aufgehoben ist. Aber Du kannst hier dann gerne einen Link posten Gruss, Thorsten.

Hi David, the table lists an ON and OFF event for each individual input: [tt] [MIDI_OUT] ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 1 = 90 30 7F 90 30 00 @OnOff 2 = 90 31 7F 90 31 00 @OnOff 3 = 90 32 7F 90 32 00 @OnOff ...etc... [/tt] The "90" stands for "Note On at Channel 1", if you want to send a Note On over channel 2, then just replace 90 by 91 It's hexadecimal coding, and we are counting from zero. Means: 0...9 = MIDI Channel #1-#10, A = MIDI Channel #11, B = #12, C=#13, D=#14, E=#15, F=#16 MIDI Note 60 is hex 3C, if it should sent over Channel 3, then write: [tt] 5 = 92 3C 7F 92 3C 00 @OnOff [/tt] Best Regards, Thorsten.

Nicht unbedingt - wenn die Taster erstmal durch die Bohrungen passen (was wirklich in eine ziemliche Fummelarbeit ausarten kann), heize ich mit dem Loetkolben die Loetstellen nochmal an, so dass sich die Taster zentrieren lassen. Diese Prozedur wiederhole ich dann ein- bis zweimal, bis es bei allen Tastern passt. :) Gruss, Thorsten.

Hi John, thanks for the feedback! Don't hesitate to publish your application once it is finished, it will be at least a nice inspiration for other people :) Best Regards, Thorsten.