TK.

Do you have an explicit suggestion? (Reichelt part number) Best Regards, Thorsten.

Hi Robm, ok, this possibly wouldn't work with this low-cost solution due to the missing amplifier. And an amplifier would also require a schmitt trigger circuit to improve the stability. All this is integrated in the QT320 device (-> keyword hysteresis). You only have the connect the DINs with the appr. OUTx pins of the QT320. The programming of the sensor characteristics could also be done from a MIOS application, but it requires some programming skills... Best Regards, Thorsten.

Hi Pay_c, yes, this could be the reason, From the SID datasheet: "CAP1A/CAP1B/CAP2A/CAP3A - these pins are used to connect the two integrating capacitors required by the programmable Filter. C1 connects between pins 1 and 2, C2 between pins 3 and 4. Both capacitors should be the same value. Normal operation of the filter over the audio range is accomplished with a value of 1000pF for C1 and C2. Polystrane capacitors are preferred. In complex polyphinic systems, where many SID chips must track each other, matched capacitors are recommended. The frequency range of the filter can be tailored to specific applications by the choice of capacitor values. For example, a low-cost game may not require full high-frequency response. In this case, larger values for C1 and C2 could be chosen to provide more control over the bass frequencies of the filter. NOTE: Cut-off frequency variation may occur from chip to chip due to process variations, and power supply voltage. Capacitor values and voltage regulation can compensate for these variations." Sidenote: the suggested C1/C2 values are the same which are used in the original C64 designs. As the datasheet says, the best value differs with the chip version. Best Regards, Thorsten.

Wow, da ist sogar ein 82'er dabei! :) Hast Du die Bilder schon an Kubi geschickt? (http://www.kubarth.de/sid/index.html) Im habe ich auch schon seit Monaten ein paar Photos von meinen SIDs versprochen, aber man kommt ja zu gar nichts mehr... :-/ Gruss, Thorsten.

http://www.germankraft.de/ Best Regards, Thorsten (has got his tickets ;-))

Hi PW, what does the press say? ;D Best Regards, Thorsten. P.S.: Too all guys who don't know the famous MIDIbox magazine yet:

Oh, this has some historical reasons - in the first months I just wanted to prevent that everybody has to change the wiring of his box with every new release. The very first MB64 supported only 16 LEDs and 24 buttons, and I improved the driver successively. However, today the shift registers are freely assignable to the button and LED entries in main.asm (thats the purpose of the DIN_MAP and DOUT_MAP). Als the menu buttons are free assignable to any pin (not only to the first 64, but also to the remaining 64 digital inputs...) Best Regards, Thorsten.

Hi LO, it seems that this is no transmission error, since CC #4B is properly incremented (...5A, 5B, 5C, 5D, 5E...). On a bad MBLINK connection I would assume a totally different - or invalid - MIDI event. "B1 48 xx" is assigned to a pot, isn't it? Did you seperate the analog from the digital wires (are the wires itself shielded, or only the whole cable?) Do you have more logfiles? Best Regards, Thorsten.

Hi Robm, you don't need to buy those sensor ICs, MIOS provides a software based solution - up to 128 capacitive touch sensors can be connected :-) A schematic diagram can be found here: http://www.ucapps.de/mbhp/mbhp_din_touchsensors.pdf This article describes, how it works: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1062462975;start=1#1 Best Regards, Thorsten. FAQMARKER

Hallo Nova, ich kann eigentlich nur das wiederholen, was in den letzten Tagen schon des oefteren anklang: alle unbenutzten analogen Eingaenge (-> Port J5) muessen auf Masse gelegt werden! Ansonsten zu dem Thema, wie man merkt, ob MIOS korrekt aufgeladen wurde: an der Checksumme waehrend des Transfers, oder mit Hilfe des CRC-Tests (siehe MIOS->Download). Aber bei Dir ist wohl alles glatt gelaufen... Noch ein Tip: solange keine Motorfader angeschlossen sind, sollte das "ENABLE_MOTORDRIVER" flag in main.asm auf 0 gesetzt werden Gruss, Thorsten.

Dieses (geniale) Foto hast Du aber nicht mit einer digitalen Kamera gemacht, oder? Gruss, Thorsten.

Hi Erik, in theory you could control it via the debug SysEx protocol provided by MIOS itself (it allows you to execute any function - like MIOS_AIN_UnMuxed), but it's much simpler just to set the appr. option in the main.asm file of the MIDIbox64 application. Best Regards, Thorsten.

Far from it - they are the highlights of this forum! :-) Best Regards, Thorsten.

Since it turned out that KS0107/KS0108 based displays with 240x64 resolution are not available anymore, I'm thinking about an alternative way for controlling graphical LCDs without performance loss. It's clear that this requires a second microcontroller, but on the other hand the total-costs of this solution are less than I payed for my high-performance Displaytech 64240A. So, a conceptional (!) preliminary (!!) schematic can be found here: http://www.ucapps.de/mbhp/mbhp_lcd_companion.pdf The "companion core" will be connected via Port J15 of the MIOS core module. The parallel bus interface works asynchronous (Request/Acknowledge line), will provide double data rate (8 bit during the request phase, 8 bit after the acknowledge phase), and will support read and write transactions. Up to 8 companions will be addressable in this way, and it depends on the implementation how much displays can be connected to a single companion. ;-) However, MIOS will provide a generic bus protocol for this interface, and a 2nd layer protocol for graphical as well as for character displays. In this way, low-cost displays based on the polular T6963C can be connected to the MIOS core without performance loss, but also any other display - the companion core just has to process the protocol. (Sidenote: not only displays can be connected in this way, but any device which requires fast data transfers) (Sidenote2: see this posting http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1067480170 for a solution provided by Duggle which will be perfect for slow data rate peripherals) Important: this is a concept, which I will possibly realize next year. I cannot guarantee that it will work yet! The purpose of this posting is just to inform you about a possible solution before you purchase overpriced KS0108 based displays at EBay or wherever. Best Regards, Thorsten.

I already wrote this in a PM, but it could be interesting for everybody: The 7219 gives you no advantage compared to the already existing solution (http://www.ucapps.de/mios/leddigits_16.pdf) which will be integrated into the MIDIbox LC sooner or later. The 7219 is something like a serial 16 bit register with command interface. Two of them allocate 32 bits in a serial chain, and this is exactly the same number which is allocated by the leddigits_16 module. But the driver for a 7219 is totally different - and thats an disadvantage. So, the use of a 7219 makes only sense if enough pins are free to drive this serial chain seperately. And this isn't the case for MIDIbox LC (assumed that a KS0108 display is connected). Btw.: the driver is similar to that used by mbhp_aout Best Regards, Thorsten.

You can be sure that I would signalise a major hardware change which would make the old hardware obsolete at least one year before such a step ;-) Best Regards, Thorsten.

fixed Best Regards, Thorsten.

Hi Iain, programming a PIC16F628 with JDM & ICprog fails. I guess that this is an imperfection at the software side, since other chips are working ok JDM under Linux: I would also be interested in a solution! Vectorboard: I made my first JDM on a vectorboard, it was easy and still works w/o problems. I don't have a picture of the bottom right here (just only the small picture which can be found at the MBHP_JDM page), but the placement & routing is just a 1:1 copy of the schematic. Best Regards, Thorsten.

uclaros: thanks for the feedback - good to know that this implementation is flexible enough! :) Nat: this cannot be explained with one sentence, you will find the answers in the source code ;-) Best Regards, Thorsten.

Cool!!! :) Best Regards, Thorsten.

Hallo Andy, einen Softwarefehler kann ich nahezu ausschliessen - von solch einen Effekt hat noch nie jemand berichtet (aber nunja, irgendwann ist immer das erste mal...). Wie verhaelt sich der Core eigentlich im UnMuxed betrieb - sprich: wenn die Multiplexer deaktiviert sind und MIOS die 8 analogen Kanaele direkt convertiert? Dazu muss das main.asm File der MB64 wie folgt geaendert werden: #define DEFAULT_NUMBER_POTS 8 #define DEFAULT_MUX_ENABLED 0 Idealerweise sollten in diesem Fall 8 Potis an J5 angeschlossen sein, aber um die Stabilitaet der Conversion Results zu ueberpruefen, kannst Du jetzigen Verbindungen auch erstmal so lassen wie sie sind. Falls das nicht hilft, AIN Module abklemmen und Potis direkt anschliessen. Falls das immer noch nicht hilft, dann muss einfach irgendwo etwas falsch angeschlossen sein (ueberpruefe vor allem die Vdd und Vss Pins am PIC - und zwar gegen Masse sowie gegen +5V) Gruss, Thorsten.

Yes - workaround: the strings could be outsourced into a BankStick. With MIOS V1.4 data can be uploaded to all 8 BankSticks like common program code, but I haven't found the time yet to change this in the application. (Btw.: I'm currently building some new powerful sound features into the MBSID, based on suggestions from a real SID expert - stay tuned ;-)) Best Regards, Thorsten.

I've planned to improve this in the future (do avoid more questions regarding this topic ;-) Best Regards, Thorsten.

You could ask SmashTV :-) Best Regards, Thorsten.

Hrmpf! I didn't know that the MIDI remote implementation of Cubase SX is so imperfect... BUT: It's funny, I just realized that I already took care for forwarding the received value to the common LED state register: btfsc MB64E_CFG0, MB64E_CFG0_MIDILEDS, BANKED; only if MIDILEDS flag set andwf INDF0, F ; (MB64E_BUTTON_VALUES_SR0) andwf INDF1, F ; (MB64E_MBUTTON_VALUES_SR0) this means: a) the "MIDI LEDs" flag has another function in the MIOS implementation compared to the PIC16F firmware which has to be documented a) don't change the LED map, just enable the "MIDI LEDs" flag with vmidibox or the mk_syx script and it will work :) Best Regards, Thorsten.