TK.

yes! Best Regards, Thorsten.

Hi Matthias, it's very interesting, that the other PC detects the USB chip! Would be interesting, if the OS version, or the USB host is the reason. However, I think that the "(2131Q/2131S/2135S)-EEPROM MISSING" selection is the right one, but I guess that it doesn't really matter, because all of them are pointing to the same driver file. It's propably only the device description that you are selecting here Best Regards, Thorsten.

The MIDImon is an exception, it uses the analog port as digital inputs. Here I prefer pull-ups to make it similar to the DIN module Main intention of the AUAIMBCTG rule is to have "stable" values, and to prevent floating inputs... Best Regards, Thorsten.

Hi Christian, yes, it's correct, that code cannot be fetched from an external memory. The PIC doesn't provide a generic parallel interface anyhow, so that your software has to handle external bus accesses via the GPIO pins in the same way like it accesses the interface of the LCD. This costs time, but in most cases it's fast enough. For you MIDI controller project, the CPU load will be very relaxed anyhow when I compare it to applications like the MIDIbox SID (as an example), therefore you could even use a serial flash or EEPROM, it will still be fast enough. Short calculation: assumed that you are planning to use a graphical 240x64 LCD (too bad, that you didn't mention the display you are planning to use, it would simplify my answer). The whole display consists of 15360 pixels, makes 1920 bytes. Assumed, that you are fetching the graphical data from a serial EEPROM (like my beloved "BankSticks"), it would take ca. 30 uS * 1920 = ca. 60 mS to write the whole screen. This is fast enough, because I don't think that you want to playback a movie? And even if latency does matter, you could split the display update into several parts (preemptive multitasking), so that on each "mainloop" only one or two lines are updated. By doing so, you would achieve an overall latency which is still less than 1 mS If you are planning to use a character LCD, then you don't need to consider such things... Even when you are writing the application in C, it doesn't matter, that (for example) the PIC18F452 doesn't provide enough code memory for your project. Because by using clever data structures, you don't need so much code anyhow. Menu structures, character strings, MIDI events and streams, parameter values or whatever can be easily saved in (and accessed from) an external non-volatile memory. The program itself only needs to know, where the informations are located (even such infos could be saved in the ext. tables). Sending different MIDI events depending on the menu just only means, duplicating the external data tables... Such methods have also another advantage: by using a socket for the external memory (like the "BankStick"), you could allow the user to switch between different setups (it doesn't matter, how many synths are part of the setup), or to make backups, or whatever. It's also easily expandable by multiple memory devices. Best Regards, Thorsten.

Hi Alex, the link to the schematic is missing... No, schottky diodes have a slightly different symbol. But before you are doing a seperate order: you can also use a common diode like 1N4001, it will do the same so long the PSU is not too strong The ground of the 5V and 9V pin is the same, the SID chip doesn't provide a clear seperation between analog and digital ground. When thinking about wiring: star topology is the best, this means, that a ground connection between SID and CORE is not required (this would result into an unwanted ground loop) Best Regards, Thorsten.

Yes, with the C interface the implementation should be easier than programming MB64 meta events Best Regards, Thorsten.

Hi, I'm not sure, are you able to measure the voltage at SID pin 28 within the C64? This would be interesting! Best Regards, Thorsten.

Hi Rene, did you already try to swap the master with a slave PIC, just to check if this was a code upload problem? Best Regards, Thorsten.

Thanks, I will check this! I guess that you were able to reproduce this with beta13? Best Regards, Thorsten.

In theory "gpasm" could be used to compile an assembly based application. It's already used for C based MIOS applications, and works on all platforms. It also handles the missed linefeeds correctly. Only problem is, that it cannot handle with my beloved "IFSET", "IFCLR", IFGEQ", etc... macros. But maybe there is a simple way how to make them compatible to gpasm? Then I would spend the effort to release all apps for this alternative assembler Best Regards, Thorsten.

Hi Rowan, when I think about all the plans I already have for this (and the following) year, I fear that I won't find the time for just another project. But I fully aggree, that the KMK protocol is better compared to LC. My own problem is, that I haven't any benefit from it for myself (yet). However, writing the driver based on MIOS C shouldn't be so difficult, maybe somebody else is interested? The C based MIDIbox MM driver already provides all the basics (e.g. SysEx parsing) Best Regards, Thorsten (Logic PC user...)

Ok, the LEDs are controlable via button, now you can change the LED map (either with Serge's editor, with the mk_syx tool, or by hand in mb64e_presets.inc) LCD issues: did you take the golden AUAIMBCTC rule into account? -> http://www.ucapps.de/mbhp/auaimbctc.pdf Best Regards, Thorsten.

yes! This connection is only required if somebody wants to use the C64 PSU No, there are no objections so long you know what you are doing - take care for the polarity, once swapped, it will destroy your chips! You could add a shottky diode in parallel to the 5V/ground rail of the core module, and the 9V/ground rail of the SID module in order to protect the modules against polarity issues. The anode has to be connected to ground in this case Best Regards, Thorsten.

I know that it is no software error, so it can only be a configuration error. Or maybe you overwrote something important during your modifications? Did you change the mapping in main.asm or setup_*.asm? (if you are using a setup_* file, you need to do the change there!) Or the upload was not successfull? (are you using MIOS Studio?) My suggestion: download the application from my website again, do only the modifications which are required, and upload the new .hex with MIOS Studio Best Regards, Thorsten. P.S.: as mentioned above, mb64e_leds.inc controls the LEDs...

Hi Alex, psu2.png is the better one, but note that the GND output of the 7809 branch is not ground, it's on the same level like the 5V output of the lower branch. On the other hand: if you've measured 10.5VDC before the 7809, than this is excellent! So, in this case, you could connect the AC output of the transformer directly to J1 of the SID module Which voltage to you measure before the 7805? Because I fear that it's not high enough Best Regards, Thorsten.

...you have to write "db 0x01, 0x00" into the first line of ..._LED_MAP This means, that the events of the first 8 Button events are mapped to the DOUT register, which is selected with DEFAULT_DOUT_SR_PIN_01_08 (see main.asm) If you want to control DOUT SR#1 instead of SR#5 (which is the default value), you have to change the settings in main.asm --- LEDrings must be disabled, the SR numbers of DEFAULT_DOUT_SR_PIN_* needs to be modified Best Regards, Thorsten.

MIDI parsing starts at "MB64E_MIDI_Scan" in mb64_midi.inc, But I think, that this is the answer for which you are searching for: in mb64e_leds.inc, you will find the function "MB64E_LED_Update_InitLoop", which contains the lookup table that branches to the appr. init routines depending on the LED MAP value. You could swap the "rgoto" statements. Or another possibility: if you are doing edits on the mb64_presets.inc file anyhow, you could change the mapping there. Search for MB64E_Presets_LED_MAP - each byte contains one nibble of the 8bit map value, with "db 0x01, 0x00" you will select the first SR, with "db 0x01, 0x01" the second, etc Best Regards, Thorsten.

It seems that windows has detected a USB device, but wasn't able to get the vendor ID. This means in other words, that the connection between your USB host and the MBHP_USB module is still not stable, or that anything which is related to windows itself prevents the module to transmit the ID. Something which could help is to try another USB port. Not because the other doesn't work, but because this will force windows to re-install the driver. If this doesn't help, then it's definitely a hardware problem. Win98: propably on this PC the "hide system files" option is enabled, you need to turn it off somewhere on the option panel of the file explorer It would be very interesting to know, if the module works with another PC It maybe also makes sense to search in the internet for postings about this issue, e.g. with "ez-usb winxp" I found some interesting ones... Best Regards, Thorsten.

Hi Alex, the maximum voltage of the cap should be at least 2 times higher than the AC voltage. In this case there is no need for 12V. But since your transformer only delivers 9V AC, and the 7809 requires a little bit more (appr. 11V) to regulate the DC voltage, you propably need to use the same method like with the C64 PSU. My strong suggestion: draw a schematic of the circuit you are planning to build, and post it here. 1000 words are no guarantee for correctness, only with the schematic somebody can say if it will work or not Best Regards, Thorsten.

my deepest respect, it sounds better than most of the commercial stuff today! Best Regards, Thorsten.

See this posting http://www.midibox.org/forum/index.php?topic=6039.0 Best Regards, Thorsten.

This page describes the easiest way to build an application: http://www.ucapps.de/howto_tools_mpasm.html Best Regards, Thorsten.

o ensure that the EEPROM is not stuffed on your module! (if this is the case, unmount it and remove/connect the USB cable) o click Systemsteuerung->System Icon o select "hardware" slider o click on "gerätemanager" o uncollapse "USB-Controller", search for the "unknown" device (if it isn't unknown, you will read "Cypress EZ-USB... EEPROM missing" o doubleclick on this icon o select "Treiber" slider, click on "Treiberdetails" - which one is displayed? o click on "Aktualisieren..." o select "Nein, Diesmal nicht" and "Weiter" o select "Software von einer Liste..." and "Weiter" o select "Folgende Quellen ebenfalls durchsuchen..." and "Durchsuchen" o select the directory ez-usb/driver within the mbhp_usb package anything missing? Best Regards, Thorsten.

Yes, the PIC18F4620 is pin compatible, you don't need a new core module or something like that (this is really a FAQ, it should be written into the Wiki) Maxim UART chip: I prefer the IIC solution, because it's more flexible and and requires less pins. The maxim chip couldn't be used on MIDIbox projects which already allocate all pins. However, do you know a IIC (I2C) UART? Best Regards, Thorsten.

Another point: for Cubase you need to select the "Mackie Control" emulation mode: main.asm change LC_EMULATION_ID to 0x14 Best Regards, Thorsten.