TK.

Wenn man statt des MIDI Filters eine MIOS basierende Applikation hernehmen wuerde, koennte man (fast) alles mit einem einzigen Core Modul erschlagen: mit der "ain64_din128_dout128_v2_0" Applikation koennte man bspw. die Zugriegel und die Tastatur abfragen, die Transponierung laesst sich in die MPROC_NotifyReceivedEvent() Funktion einbauen (dazu koennte ich auf die Schnelle auch ein Beispiel schreiben), die MIDI Outs der beiden MIDI Keyboards koennte man mit dem MIDI Merger zusammenfuehren, bevor die Daten durch das "Master Core" Modul gehen. Doch ich moechte hier eine deutliche Warnung aussprechen: wer schonmal eine "normale" MIDIbox aufgebaut hat, wird die notwendigen Ergaenzungen in der Hardware (-> externer MIDI Merger) und Software (-> Transponierung, evtl. auch einbauen der Scanmatrix Routine, falls der Tastaturblock gemultiplext ist) sicherlich relativ schnell hinbekommen, doch wer neu in die Materie einsteigt, sollte nicht davon ausgehen, dass alle gewuenschten Features auf Anhieb funktionieren. Auf meiner Webseite gibt es nirgendwo eine Schritt-fuer-Schritt Anleitung zu finden, welche genau fuer diesen Anwendungsfall ausgelegt ist, man muss sich also eine Menge Informationen zusammenpuzzeln. Deshalb auch nochmal zwei Links, fuer den Fall, dass Du nach einer fertigen Loesung suchst (bei beiden bin ich mir jedoch nicht sicher, ob sie auch das Transponieren von Noten beherrschen). der c't "Klangcomputer" - er wurde speziell fuer "Master Keyboards" entwickelt und ist bestens dokumentiert: http://www.heise.de/ct/ftp/projekte/klangcomputer_ii/ wer Zeit sparen moechte, kauft sich einfach ein paar fertige Module bei Doepfer http://www.doepfer.de/home_d.htm - hier muss man sich jedoch mit der mangelnden Flexibilitaet abfinden Gruss, Thorsten.

Hallo Michael, allgemein beantwortet: ja, das geht recht simpel, vor allem wenn man mit dem MIOS C Wrapper, so dass man selbst Anpassungen am Programm vornehmen kann. Gruss, Thorsten.

No, it isn't possible to store code in a BankStick, the PIC can only execute from internal Flash. Currently your program allocates the range from 0x3000-0x47ff, thats ca. 6k The range from 0x4800-0x7bff is not used yet, means: 13k are free so, just ca. 33% are allocated yet, I don't think that you will hit the border so fast... and even if this happens, there is always room for optimizations in the code ;-) Best Regards, Thorsten.

I will go for the even more powerful single core solution as planned, because I think that people (and myself of course, otherwise I wouldn't program it) will be much more happy with it. Main advantage will be, that nice chord combinations can be found live and induitively, and triggered with a small number of keys (2 or 3...) - I don't really like to prepare anything "static" on a PC, it wouldn't really make fun. Another point: who would write the PC software? ;-) If you want to have a solution based on your imaginations, then there is no other way than to program it by yourself, or to find somebody else who is doing this for you (infos are located at mb64_meta.inc) MBSEQ: yes, in song mode you can change the track set with the 16 general purpose buttons. This works like known from groove machines. With the track set you can decide by yourself, which tracks should be muted. A synchronized switching is still planned (and prepared), but not fully implemented yet. Best Regards, Thorsten.

You are right, writing meta events to "fire" chords which are preadjusted with pots is a piece of cake, but what happens if you change the note number while keys are already pressed? Hanging notes will be the result, and to avoid this a real note stack will be required (like known from MBSID/MBFM/MBSEQ/MBCV), and this requires memory which is just not available anymore in the MB64 application (it's already overfeatured). However, if something like this would be put into a special application, it would be much more easier and better maintainable, therefore my thoughts about doing it really powerful (no tinkering solutions!) Best Regards, Thorsten.

Hallo Moroe, die Polung sollte schonmal richtig sein (wenn ich mich jetzt nicht selbst vertue) - nun koennte ich mir noch vorstellen, dass die 220 Ohm Widerstaende bereits im Keyboard eingebaut sind, und die zusaetzlichen Widerstaende dann das Signal zu sehr abschwaechen. Vielleicht schraubst Du das Keyboard einfach mal auf, und verfolgst die Leiterbahnen. Wenn sie direkt zu einem Mikrocontroller gehen, dann sind die 220 Ohm Widerstaende auf alle Faelle empfehlenswert (denn sie schuetzen den Controllerausgang im Falle eines Kurzschlusses), doch wenn da bereits Widerstaende dazwischen sind, kannst Du darauf auch verzichten. Gruss, Thorsten.

Hi, you can applaud/smite once you've written a certain number of postings, this is some kind of protection to ensure, that somebody doesn't create new accounts just to cheat the score. I also don't see any reason why somebody gave you a smite! If the appr. guy reads this posting, please give us a statement (even if it was just a click on the wron button) - if there is no reply until next week, I will reset the smite counter. Best Regards, Thorsten.

Yes, as a part of MIOS Studio. Adam: this is not an explicit request to you, but maybe somebody else with Java knowledge, who has the time (and the need) could integrate this into MIOS Studio? Best Regards, Thorsten.

Hi Joey, thanks for asking here! This shows me, that you are aware of the community and the rules. I must ask back do check if we have the same understanding: are you planning to implement new software + hardware designs based on MIOS. Will you release all specific informations to the public (source code, circuits), so that (alternatively) everybody will be able to build your creations without paying? Considered that you've explicitely mentioned that large manufactured runs are not planned, I will propably grant it. Best Regards, Thorsten.

Not the size of the .hex does matter, but the last memory address which is allocated by the program. For the PIC18f452 it's 0x7bff (because the bootstrap loader begins at 0x7c00). The easiest way to determine the last address before the upload is just to run the hex2syx script, because it shows you the used address ranges. Also MIOS Studio shows the address block addresses during the upload - once you've reached the upper boundary, MIOS will report an error acknowledge. Best Regards, Thorsten.

I think that a full patch editor wouldn't be worth the effort, for such things we already have JSynthLib, which is also a java application. But an alternative SysEx patch librarian to TL's SID/FM manager would be very useful - a patch manager which allows to load/store/copy/paste/move patches within a bank for all MIDIbox applications. Best Regards, Thorsten.

Hi Dave, the 10mV at the CS# pin are ok. If all signals can be toggled from the core, then it's either a very general problem (e.g. notes played on the wrong MIDI channel), or there is a problem with the clock (oscillator - one guy just had this some days ago, he mounted this part in the wrong direction) or the audio stage of the SID module (around transistor T1) In order to exclude those "general problems", I've written a testtone applications which is available at the MIOS download page. Once you've loaded this app into the core, the SID should output a 1kHz tone. I hope that this helps you with debugging. Best Regards, Thorsten.

Hi, just one week ago I purchased a small book with chord tables... ...in order to get an oversight, because I'm thinking about such a special application which is doing similar things that you described. The only thing about which I'm unsure is, how to play the chords. A single key is mostly not enough, and once you want to play transpositions (e.g. instead of C-E-G the notes G-C'-E') it will get even more difficult. So long it isn't clear to me, how the "user interface" must look like, I won't start. If anybody knows how chord variations are handled by "entertainer keyboards", then please let me know. This feature will definitely not be part of the MB64 firmware, because the flash is already completely allocated. It will require a seperate core. Maybe once the 64k PIC is bugfree, this could be an option for MB64, but I fear that it will still take months until Microchip will release it. However, a second core can be easily added to the MIDI chain via MIDIbox Link, so this isn't really a disadvantage. Sequencer: long time ago this was part of the MB64, but in the meantime it's also a seperate application: http://www.ucapps.de/midibox_seq.html Best Regards, Thorsten.

This is a nice MIDIbox SID "-to-go" variant made by Mesak :) He wrote: More pictures are on his website!

Hi *, the MIDIbox CV firmware goes into the next round: V1.1 supports a selectable gate polarity, different CV characteristics (e.g. Hz/V for Korg MS-20), a clock sync output with up to 96ppqn, a new calibration menu and a driver for the new low-cost AOUT module. Infos: http://www.ucapps.de/midibox_cv.html ChangeLog: http://www.ucapps.de/midibox_cv_changelog.html Download: http://www.ucapps.de/mios_download.html Finally also the MBHP_AOUT_LC module is ready for public use. I've tested it with two different filter circuits and with a Korg MS-20. Works good enough for the part costs (ca. 5 EUR!) and the resistor network gives some good soldering practice ;-) -> http://www.ucapps.de/mbhp_aout_lc.html Best Regards, Thorsten.

ok - Du haettest mit MIOS Studio auch gleich das setup_8580_slave.hex File aufladen koennen, die ID wird in diesem Fall im Upload Fenster selektiert (ich muss die Bootstrap Loader Seite wirklich mal ueberarbeiten... ;-)) Gruss, Thorsten.

Ok, preloading the BankStick isn't that difficult, since MIOS provides an upload mechanism which is very similar to the flash/EEPROM upload. The data needs to be located to 0x400000 - and thats all :) Here an example. I'm using an assembler program, so that it is easier to locate data. Filename: bs_1.asm ;; preload file for BankStick #1 list p=18f452 ;; BankStick address range: ;; 32k BankStick (24LC256): 0x400000-0x407fff ;; 64k BankStick (24LC512): 0x400000-0x40ffff org 0x400000 ;; 16 bytes of data db 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 db 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f ;; a string db "This string is stored in BankStick!", 0x00 ;; some words (16 bit) dw 0xdead, 0xbeef dw 0xaffe, 0xdead ;; another byte at a specific address org 0x400400 db 0x12 ;; DONT FORGET THE END! END [/code] the .hex file can be created with following command: gpasm bs_1.asm Now you can upload bs_1.hex with MIOS Studio - the BankStick number (#1..#8) can be selected in the upload window. Within the C program you can use the MIOS_BANKSTICK_Read(address) function to read from the BankStick. With MIOS_BANKSTICK_Write(address, data) you can change the data, but note that a write takes 2 mS for each byte The address range is 0x0000...0x7fff for a 32k BankStick, and 0x0000..0xffff for a 64k BankStick If multiple BankSticks are connected to the core, the stick has to be selected with MIOS_BANKSTICK_CtrlSet(bs_number) before. bs_number range: 0..7 Example for printing a 16 character string, located at 0x0010-0x1f, from BankStick 3 (the 4th BankStick) [code] unsigned char i; MIOS_LCD_CursorSet(0x00); MIOS_BANKSTICK_CtrlSet(3); for(i=0; i<16; ++i) MIOS_LCD_PrintChar(MIOS_BANKSTICK_Read(0x0010 + i)); For a faster load/store the MIOS_BANKSTICK_PageRead and MIOS_BANKSTICK_PageWrite functions are available, they handle 64 bytes at once. This is especially useful for writes (64 bytes are stored within 2 mS). However, when using these functions, you need a 64 byte buffer (an array of 64 "unsigned char") which is located to an "aligned" address, means: 0x40, 0x80, 0xc0, 0x100, 0x140, 0x180, 0x1c0, 0x200, 0x240, 0x280, 0x2c0 - all other address ranges are already allocated by MIOS or the stack. So, in other words: using byte writes and reads is the easiest method. Best Regards, Thorsten.

Danke fuer die Arbeit, die Du Dir beim Fotografieren gemacht hast! Die Module sind wirklich vorbildlich aufgebaut (nicht ohne Grund sind meine eigenen Fotos manchmal ein wenig verschwommen ;-) Nun gibt es schon drei Blogs, somit sollten Newbies ausreichend informiert sein :) Gruss, Thorsten.

Super! Du meinst aber sicherlich, dass Du das setup_8580_slave.hex geflasht hast? (MIOS Studio liest nur das .hex Format) Gruss, Thorsten.

Hi Goule, In general it isn't a good idea to use dynamic memory allocation for strings which will never change (or especially: those size will never change, and which will preloaded by the C program each time after power-on). Because this means that the same data is stored twice: one time in flash (the routine which preloads the data), and one time in RAM. And RAM is very costly on a PIC! The simplest method is the use of constant arrays. A constant array is just a table which is stored in flash, and from which the C program reads directly whenever the array is accessed. However, the program cannot write into the table - if this is required, a special technique has to be used, but I guess that this is not for interest in your case. Here an example: const char parameter_name[8][16] = { // <-- 15 chars -> "Parameter 1 ", "Parameter 2 ", "Parameter 3 ", "Parameter 4 ", "Parameter 5 ", "Parameter 6 ", "Parameter 7 ", "Parameter 8 ", }; [/code] Note that the size of each string must be equal. In this example each string contains 15 bytes, the 16th byte is the 0x00 delimiter, which will be added by the C compiler automatically when you are using strings. So, this array format is very handy, because now you can print out a string in the following way: MIOS_LCD_PrintCString(parameter_name[pin]); (the 'pin' variable contains 0..7) As a sidenote: it's also possible to store strings in a BankStick - if this is for interest, I could create an example which demonstrates, how to preload a BankStick via MIOS Studio Best Regards, Thorsten.

Hm... did you ever check the slave cores standalone? Maybe there is a short circuit on those core modules. You could try to find out the "bad" core by testing them standalone, like you would test a master core. You don't need to update the firmware, just remove the MIDI-Link connections and attach MIDI In/Out directly on the slave core which should be tested. Now you can try to access the core with MIOS Studio (e.g. open the Debug Window, select "SRAM Read", enter address 0x000 and No.Bytes 0x10, the core should return 16 bytes) Maybe you should test this on the working master core before in order to get a feeling of the handling, then continue with the slaves. If a slave doesn't reply on the SRAM Read request, you know that this is the module which causes the problem. Best Regards, Thorsten.

Hallo Dimi, nach der Aenderung in main.asm muss die Applikation neu assembliert werden. Am einfachsten geht das, wenn man MPASMWIN direkt aufruft, dadurch faellt das komplizierte IDE Geraffel weg (das man sowieso nicht braucht). Die notwendigen Schritte sind hier erklaert: http://www.ucapps.de/howto_tools_mpasm.html Wenn der Assembler ein "ok" anzeigt, steht ein neues main.hex zur Verfuegung. Falls er einen Fehler anzeigt, schaust Du am besten in das "main.err" File - dort sind alle Fehler aufgelistet. Zum Konvertieren von .hex nach .syx musst Du das "hex2syx.pl" script in der Kommandozeile wie folgt aufrufen: perl hex2syx.pl main.hex -device_id 0x00 denn der Core hat ja noch die urspruengliche Device ID. Erst wenn dieses .syx an den Core gesendet wurde, kannst Du weitere Aenderungen mit: perl hex2syx.pl main.hex -device_id 0x01 versenden. Hierzu noch ein grundsaetzlicher Hinweis: mit MIOS Studio geht das alles wesentlich einfacher. Man muss nicht mehr nach .syx konvertieren, sondern laedt direkt das .hex file ein, und sendet es an den Core. Auch die Device ID laesst sich ohne Rekonvertierung selektieren. Der Upload geht also wesentlich flotter von der Hand, und man kann auch nicht viel falschmachen (einziger Knackpunkt: wenn der MIDI Out des Slaves nicht mit dem PC verbunden ist, muss man "Don't use Feedback from Core" aktivieren!) Punkt 1 und 2 waeren hiermit beantwortet. Punkt 3: ja - das sind die bereits vorbereiteten Files, welche mit "convert.bat" konvertiert wurden (reinschauen lohnt sich) Punkt 4: mittlerweile bin ich der Ansicht, dass es am einfachsten ist, saemtliche PICs im Core Modul des Masters zu programmieren - damit waere der MIDI Out auch mit dem PC verbunden, MIOS Studio kann mit "Feedback" arbeiten, und somit ermitteln, ob alle Code Bloecke richtig aufgeladen wurden. Ausserdem faellt das Einschalten des MIDI-Links weg (es waere besser, wenn Du die entspr. Buttons/LEDs schonmal einbauen wuerdest, das vereinfacht die Bedienung ungemein). Punkt 5: wenn Du "durch" den Master programmieren moechtest: ja Gruss, Thorsten.

It isn't so difficult: MIOS_MIDI_TxBufferPut(0xc0); // program change, channel #1 MIOS_MIDI_TxBufferPut(prg); // program number For more informations see also this nice site: http://www.borg.com/~jglatt/tech/midispec.htm Best Regards, Thorsten.

Hi, sounds like the MIDI connections of the slaves are wrong - check the schematic: http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf - the MIDI Out of the master goes to the MIDI IN of all slaves. If you would connect a MIDI Out of a slave to this line, the described effect would happen - no MIDI transfers would be possible anymore. Best Regards, Thorsten.

Hi Dave, yes, the voltage at pin 28 is the problem, once it's below ca. 10V, you won't hear the sound anymore. Also the voltage at C10 is too low, it should be >= 14V Maybe the C64 PSU you are using doesn't deliver enough voltage for the simple PSU circuit, you should consider the use of the optimized PSU - all parts can be canibalized from a C64 Best Regards, Thorsten.