TK.

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.

Hi Michael, divisions are always time consuming, and with floating point values it will take even longer to get the result. For scaling values I'm normaly using a 8*8 bit multiplication, the scaled result will be in the high byte of the result register. Here a function which you can use (it's from the sid_random application, and it's assembler optimized) unsigned char Scale_8bit(unsigned char value, unsigned char min, unsigned char max) { // scaled value is (<8-bit random> * <range>) >> 8 PRODL = value; // 8bit value PRODH = max-min+1; // range __asm movf _PRODL, W mulwf _PRODH, 0 __endasm; return min + PRODH; } [/code] Best Regards, Thorsten.

Maybe you will like also this stuff: http://www.binaryzone.org/joytoy.php Best Regards, Thorsten.

Could it be that there is a feedback loop caused by MIDI-Ox or MIOS Studio? In MIOS Studio, ensure that there is no direct connection between MIDI In and MIDI Out of your core. Check the same in the port routing window of MIDI-Ox (for the case that you are using this software). Please also remember: so long no module is connected to the core, and the MB64 application is running, it's required to tie all analog inputs of J5 to ground in order to avoid random MIDI events. Only tie the analog inputs, not the J5:Vd (+5V) pin to ground! -> http://www.ucapps.de/mbhp/mbhp_core.pdf Best Regards, Thorsten.

you're welcome! :) The firmware is final now, next step is to write the documentation for so many new options (ooof!) yes, but the AOUT module is controlled by MIDIbox SID specific parameters, and there is no special menu which allows you to customize the function of each CV output. It can only be changed directly in the software. Currently the AOUT_LC outputs the filter and resonance parameter. Both can be modulated with LFOs and EGs, see also this demo: http://www.midibox.org/forum/index.php?topic=5633.0 Best Regards, Thorsten.

You could create a table which maps the values... Best Regards, Thorsten.

I'm just waiting until Google will provide the possibility to create and send the annual tax declaration, then they really know everything of the individuals ;-) Best Regards, Thorsten.

Hi Flo, you need a special variant of MIDIbox CV in order to get the module running (it's currently only supported by a beta version of MIDIbox SID). The gate will be available at the J5 port of the core module, which is normaly used for analog inputs... I'm still working on the next MBCV release, e.g. a friend brought me his MS20 synth, so that I'm able to implement and especially to test the V/Hz output curve feature. Also a 96ppqn sync output is under construction. If nothing unexpected happens, I will release it this weekend. Best Regards, Thorsten.