TK.

Hi, did you check the pin orientation? Maybe you've swapped the pins? Best Regards, Thorsten.

this is possible since ca. 4 years ;-) -> http://www.ucapps.de/midibox64e/midibox64e_sfb_table.txt Best Regards, Thorsten.

Hi Lall, Miss Parker with I2C interface would be superb, and for me a reason to build the project and to support Fx parameter control from the MIDIbox SID :) Best Regards, Thorsten.

You wrote that you did the MIDI troubleshooting, but you are not writing about the results of each test. E.g., it would be interesting, if the IO loopback without PIC is working: Best Regards, Thorsten.

Hi Rowan, no, it's not required to add new hardware. I've written a tutorial for the 303 mode which can be found here: http://www.ucapps.de/howto_sid_bassline.html Best Regards, Thorsten.

The three voices can be assigned to different channels via SysEx (see SysEx implementation table), but the usage is too difficult. It's better to assign them to different keyboard zones, this can be done from the CS or with JSynthLib Best Regards, Thorsten.

An impressing assembly code in respect of the comments is Jarek's AVR Synth (-> http://www.jarek.synth.net/AVRSYN.asm) - note especially the aesthetic ASCII art ;-) However, not everbody has the talent to document his code in an understandable way... Yes!!! Especially the button reconfiguration for the 2x40 LCD options is a FAQ, it would be great if a step-by-step guide would be available Best Regards, Thorsten.

There are only three possible combinations, keep trying! ;-) Best Regards, Thorsten.

Since MIOS V1.8, FSR2 is saved as well, and FSR0 is saved by the C wrapper Most of the older docs are inconsistent in the meantime, I know... biggest problem is, that all ISR related comments in the main.asm file are not correct anymore... just ignore it Best Regards, Thorsten.

Looks like the ones I got from d2k some time ago - they are (still) working nice! Best Regards, Thorsten.

Are you really using the optimized PSU circuit? (http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf) - there is no connection to J1 of the core module... Best Regards, Thorsten.

See mm_leddigits.c of the MIDIbox MM application (non multiplexed) Best Regards, Thorsten.

Hi Simone, you could create Meta Events in mb64e_meta.inc, which set the global MIDI channel, e.g.: MB64E_META_Handler_00 ;; set global channel to the second byte of a F0 xx meta event movff MB64E_GLOBAL_CHANNEL, MIDI_EVNT1 return Meta Event F0 01 assigned to a button will set the channel to #1 Meta Event F0 02 assigned to a button will set the channel to #2 Meta Event F0 03 assigned to a button will set the channel to #3 etc... F0 00 will disable the global channel feature (MIDI events are sent via the programmed channel) Best Regards, Thorsten.

no, but you could just change the pinning at the DOUT module (connect the LEDs to the right pins) Best Regards, Thorsten.

Such effect can happen when there is a problem with the MIDI connections to the PC, the PC MIDI Interface or the MIDI driver - e.g., I can reproduce this with a 10 m USB cable enhancement (out-of-spec) to a MIDIsport 2x2 interface - code uploads are not reliable in this case, and MIOS Studio shows errors - this is correct, problem is not MIOS or MIOS Studio here, but the unsteady transfers to the core. So, did MIOS Studio report an error during the upload? However, as Sebo has mentioned, you can revive the core by uploading the application via 1st level bootloader (MIOS itself propably doesn't need to be uploaded again) Best Regards, Thorsten.

Just to ensure (I'm not sure if there is a misunderstanding of the circuit, or something else...): which voltage do you measure at J1 of the core module? Best Regards, Thorsten.

Changing the CC value there means, that you would also have to adapt the assignment in the SysEx table... I think it's easier just to send an additional CC from the appr. button handler in cs_menu_buttons.inc Best Regards, Thorsten.

Hallo Andreas, yep - kann man auch auschalten. Entweder in main.asm, oder per Tastendruck. Die Details stehen im ChangeLog Nein, MIOS Studio kann keine IDs aendern. Du koenntest im Notfall die ID mit der change_id Applikation abaendern, oder vor dem Brennen die ID im .hex File patchen - dabei muss die Checksumme angepasst werden. Hierfuer habe ich irgendwo ein paar Beispiele gepostet, doch ich kann sie gerade nicht finden... :-/ Gruss, Thorsten.

Can you send me your .ini and .syx file? I will try this out on my own box - but propably I won't find the time before this weekend (too much other things to do in parallel...) Best Regards, Thorsten.

You can be sure, that I don't understand this as critism! :) But I know, that it isn't done with putting just an additional comment to a line of code (how big is your screen?), it is still useless for people who don't know the whole programming concept, who don't know how to read assembly code, and which programming rules I'm using in my code. Let's go back to the CS_SID_VOICEx_FINETUNE example: as you can see in this line: ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE, CS_MENU_OSC, 0x09, 0x0a [/code] (do you see, how many comments I would already have to add to this single line?) it's a parameter number. And these numbers are defined in app_defines.h - where you can find the hint: [code] ;; offsets to registers (we are using the same like for the presets (sid_presets.inc), ;; so that SID_SYSEX_TABLE can be reused so, you are addressing registers with these parameter numbers, registers which hold the sound parameters. The same parameters are also part of a patch, and which are stored in a SysEx structure. For a newbie this might lead to following questions: - what is a parameter? - what is the difference between a register and a parameter? - what is a SysEx structure - what is finetune? - what does the VOICEx mean here? - what is a voice? - what is the difference between a voice and an oscillator, if any? - and what the heck is the purpose of all the other constants and function names in this single line: ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE, CS_MENU_OSC, 0x09, 0x0a [/code] So, hope you see the desaster. "adding some more comments" is no real solution. I think that it would more help, if somebody would describe in his own words, how he did the modifications, where he found the informations, etc... It could also be required to describe, how a synthesizer is working, what for example "finetune" means...? Finding out all the details might take some weeks, regardless if I'm giving even more hints or not. There is definitely no 1-2-3 way for CS modifications, and I hope that - in distance to others - you are writing down all your findings in the Wiki MIOS is a text adventure... Best Regards, Thorsten.

nein, Du kannst ihn nicht komplett ersetzen. Man kann lediglich CCs intern generieren. Probiere es erstmal mit den Encodern aus, MIOS bietet eine Accelerator Funktion! Diese ist uebrigens nicht fuer das "Datawheel" (also dem zum Menu gehoerigen Encoder) aktiviert, weil man hier eher feine Einstellungen vornimmt. Die restlichen Encoder beschleunigen automatisch. Bedeutet: langsames drehen - langsamer sweep. Schnelles drehen (eine Handdrehung), sweep ueber den gesamten Wertebereich - man gewoehnt sich dran. ja, wenn Du den Programmcode in die Applikation (MIDIbox SID) einbaust, der die Poti-Werte weiterverarbeitet Es gibt weder 9 Eingaenge (sondern 8 ), nocih eine Bruecke. Vielleicht hast Du dieses Dokument uebersehen: http://www.ucapps.de/mbhp/auaimbctg.pdf Vielleicht kann auch jemand anderes nochmal ein paar Anfaengertips geben (habe gerade wenig Zeit...) Gruss, Thorsten.

Hallo Andreas, die Power LED sollte immer leuchten, VPP und VDD LED leuchten zufaellig - entweder sind sie an oder aus - solange der Druckerport noch nicht initialisiert wurde. Das passiert erst, wenn P18 gestartet wurde - beim Programmstart sollten beide LEDs ausgehen. Miss doch einfach mal direkt am LPT Port, wenn Du die einzelnen Pins von der P18 aus unter Hardware->Options umschaltest. Die Pinbelegung befindet sich im MBHP Burner Schaltplan. Gruss, Thorsten.

Hi, MK_SET_OBJ clears the object list and creates a new one. MK_ADD_OBJ adds objects to the current list. It's just a preparation for an unimplemented feature, which would allow to build multiple .hex files with different objects with a single "make" run. Best Regards, Thorsten.

For the oscillator button, this behaviour has to be explicitely activated. I use the "faster handling" (one 1--, -2-, -3-) instead, and when I want to change multiple OSCs at the same time, I just click on the appr. "general purpose" button in the menu section (which shows the OSC selection as well), and change the desired combination there. This behaviour can be changed in main.asm: ;; if 0: OSC button selects also combined modes (7 states, combined OSCs) ;; if 1: OSC button selects only one of three OSCs (faster handling) #define CS_MENU_OSC_BUTTON_BEHAVIOUR 1 [/code] I hope it's acceptable from your side, when I cannot help that much here. I've already a very reduced sparetime to continue with my MIDIbox projects, and each moment I find some time, I've to decide "should I reply some emails", "should I help some people in the forum", "should I continue with any documention", or just "can I continue with programming something new?" - what would you prefer? It has also to be considered, that writing a really understandable documentation takes 2..4 times longer than just hacking the code. I really know, that for some people it's difficult to understand the whole programming concept since many parts are scattered over different .inc files - on the other side, this is the only possibility for myself to reach such a complexity and variability. So, I think that your question was just because you didn't thought about how much effort a sufficient answer produces at my side. Therefore I give you just the hint: open the main.lst file, which contains the whole assembled code and search for some keywords there (this file is only available when you've started the assembler by yourself, it is deleted on release packages). And if you want to help the community by yourself, document your findings in the Wiki. Another point I want to highlight: writing a complete documentation means for me, that I have to take care that I don't change conceptional thinks too much anymore, because this would either require to write a second documentation about the new implementation, or that the old one is expired, and no new one is available (-> wasted effort) I see this as a inhibition threshold for implementing anything new. E.g. the CS handler like it is currently implemented in MBSID was very different in older releases, I changed most of the functions in order to make it faster, and to reduce the memory consumption. I'm planning a redesign again for MBSID V2 And this is by the way the next point: what happens, if I decide to make a certain button or LED of the control surface more important than it currently is? Do I need to take care for all the variations which could be created in future by different people (variations, which I could never try out by myself), or do I have the freedom to change like I (and most other users) find it optimal? Just my thoughts... hope that this also makes it more understandable, why - in the meantime (it was different 4 or 5 years ago), I really cannot give detailed answers on any questions, regardless if they are interesting for multiple people, or only for a single guy... At the end I think, that the community has to push the documentation forward without much help from my side. Everything else is additional effort at my side for a small number of people. It prevents me to continue with new stuff which makes myself and many other people happy. Best Regards, Thorsten.

This nice MIDIbox SEQ has been tinkered by MTE :) He wrote (in german)