TK.

If the application doesn't setup the merger by itself, just add following code to the USER_Init function: For cores which are acting as "MIDIbox Forwarding Point(s)" USER_Init movlw MIOS_MIDI_MERGER_MBLINK_FP call MIOS_MIDI_MergerSet For the core which is acting as "MIDIbox Endpoint" USER_Init movlw MIOS_MIDI_MERGER_MBLINK_EP call MIOS_MIDI_MergerSet Best Regards, Thorsten.

Hi, no - you could use one DOUT register to select 2-of-16 digits at once (two digits selected at the same time), and another DOUT register (which drives the two 7-segment decoders) to send the patterns. Sure - this would increase the max. number of digits even more! It only requires some (small) modifications in the driver. Just begin to work with the digits and you will notice how easy they can be handled. :) It would be nice if you could write a report (could be uploaded to the MIDIbox portal) which describes your variations and gives some programming examples so that other people can don't have to re-invent the wheel. Best Regards, Thorsten.

Maybe it's easier to start with http://www.ucapps.de/tmp/mb64seq_snapshot.zip Best Regards, Thorsten.

Hi Ian, http://www.ucapps.de/tmp/mb64seq_snapshot.zip includes the framework for a mb64 style menu, MIDI Learn etc. will be included later Best Regards, Thorsten.

Later! :) Best Regards, Thorsten.

Hallo, der Bootstrap Loader funktioniert zumindest, Du kannst den JDM also schonmal beiseite legen. am besten gehst Du mal in Ruhe die Setup-Tips unter Concepts->MIOS->Bootstrap Loader durch. Wichtig sind vor allem folgende Punkte: MIDI-Ox muss so konfiguriert werden, dass keine Rueckkopplung (Feedback Loop) auftritt - die eingehenden MIDI-Daten duerfen nicht zum MIDI Out weitergeleitet werden im SysEx Configurations Menue muss "Delay after F7" auf mind. 750 mS eingestellt sein Die Output buffer size kann auf 2048 vergroessert werden (um den Transfer zu beschleunigen) Gruss, Thorsten.

In the next days the midibox.org domain (where this forum is hosted) will be reconnected to midibox.org So, if you are not able to reach this forum via http://www.midibox.org/forum,'>http://www.midibox.org/forum, please try http://www.midibox.org/forum instead The final URL will be available next week: http://forum.midibox.org Best Regards, Thorsten.

No I don't know the new album yet, but I will check it on the next trip through the CD store - thanks for the hint :) Some words to the improved resolution: I haven't taken into account that storing so much characters per line also costs too much RAM. Another problem is the "tblrd" instruction which takes 2 cycles instead of one - very bad for "balanced code" (a requirement for proper graphics). So a compromise would be an alternative mode with 40x25 ROM characters, and maybe another alternative mode which allows to split the screen in two halfs for a big and a small font. Let's check it next weekend ;-) Best Regards, Thorsten.

You mean: reusing the VIC from an old C64 -> next year ;-) Best Regards, Thorsten.

The resolution isn't limited by speed, but by the available RAM. However, the next version will support a hires mode with quadrubled resolution which will only work with "ROM fonts" and with 1 pixel distance between the 8x8 characters. This will be nice as replacement for the MIDIbox LC display, since exactly 56 characters can be displayed per line in this way. Grayscales: not possible since two pins cannot be stimulated at the same time when the shifting method (for highest speed) is used. Best Regards, Thorsten.

Alle Projekte, die unter "MBHP Projects" aufgelistet sind - ausser "MIDIbox SID" - wurden noch nicht auf MIOS portiert. Sie laufen nur auf einem PIC16F877, die Umsetzung auf MIOS ist fuer mich ein "Low priority task", wird aber bald geschehen, um solche Unklarheiten gar nicht erst aufkommen zu lassen. Bitte nicht nach dem Release Datum fragen, dazu gebe ich keine Auskunft mehr. Sicher ist nur, dass die PIC16F Firmwares nicht mehr erweitert werden. Alle Projekte die unter Concepts->MIOS->Download zu finden sind, laufen ausschliesslich auf dem PIC18F. Einige MIOS Applikationen bieten bereits wesentlich mehr als das alte PIC16F Geraffel... Beispiele: MIDIbox64: 64 potis, 64 buttons, 64 LEDs MIOS ain64_din128_dout128_v1_3: 64 potis, 128 buttons, 128 LEDs MIDIbox16E: 16 encoder mit 16 LED-Kraenzen MIOS enc_example3_v1_3: 64 encoder mit 64 LED Kraenzen Und dies sind eigentlich nur die Programmierbeispiele... ;-) Wer noch ein komfortables Menue, Baenke, verschiedene MIDI Protokolle usw. haben moechte und sich diese nicht selbst "mal schnell" in die Applikation reinprogrammieren kann/moechte, muss halt auf die Umsetzung warten... Houston (MIDIbox HN) und Logic Control Emulation (MIDIbox LC) laufen nur unter MIOS (->PIC18F) Das Control Surface Feature (Step A/B und C) der MIDIbox SID laeuft ebenfalls nur unter MIOS. Hoffe alle Klarheiten beseitigt zu haben ;-) Gruss, Thorsten.

Hallo, yep - in main.asm den CS_MENU_DISPLAY_ITEMS parameter auf "4" setzen: Viel Spass beim Schrauben :) Gruss, Thorsten.

No idea - I don't own such a keyboard and therefore don't have experiences which performance is really required... Best Regards, Thorsten.

I made some snapshots from my scope for a better understanding: This snapshot shows the trigger signal (CORE:J14) in relation to the DIN input signal of the 74HC165 when the touch sensor is not pressed. Due to the low capacitance the voltage level raises fast. This shows the DIN input signal when the touch sensor is pressed. Your finger leads to a higher capacitance, therefore the voltage level doesn't increase so fast anymore. The MIOS_SRIO_TS_Sensitivity value variys the pulse width in 200 nS steps. A higher value will lead to a a higher sensitivity, since it increases the charging time. Now some words to the sample point. The RC signal of the shift register in relation to the touch sensor trigger: the DIN value will be loaded with the rising edge of RC RC in relation to the DIN signal --- MIOS will sample a logic-1 when the voltage level of the DIN signal was higher than ca. 3.5V at the rising edge of RC The same when the touch sensor is pressed. The voltage is lower than 3.5V, therefore MIOS will scan a logic-0 To your questions: Yes, it will increase the danger of crosstalks. The DIN registers should be as near by the fingertips as possible (this means: shorter than 1m (meter)) Keyword: heuristic analysis ;-) I used a trimmer to determine the best value. Higher values will lead to (the damned) crosstalk effects, lower values lead to a poor sensitivity. It's the same for the sensitivity value (-> pulse width) offered by MIOS. I've no experiences with such modifications (I'm no analog expert). I guess that it won't make a difference, because the PIC already contains strong output drivers (up to 20 mA). If you run into problems with your very special touch sensors (I'm using this simple circuit for motorfaders), you could add Schmitt Triggers to improve the logic level "detection". They could possibly also help to eliminate the crosstalk problem (if it occurs...) Best Regards, Thorsten. P.S.: these pictures have been made with the touch sensors of my MIDIbox LC - 16 shift registers (=128 inputs) are connected in a chain, the touch sensors are the last in the chain, this explains the transients on the high-frequency RC signal

Hallo Matthias, MIOS laeuft ausschliesslich auf dem PIC18F452. Es ist eigentlich schon seit einem halben Jahr fertig, wird aber hin und wieder mit zusaetzlichen Features angereichert - also nicht verunsichern lassen ;-) Gruss, Thorsten.

Hi Dan, these are warning messages. "BUILD SUCCEEDED" means that the file has been assembled successfully. Message[302] can be disabled with following line in the assembler code: ERRORLEVEL -302 The IC-Prog message "The file does not contain any configuration information!" can be ignored, just disable this check somewhere in the options menu Best Regards, Thorsten.

Dan: you've to use the scart socket (A/V input of your TV) Btw.: the next MIOS version will support a new display type #6 which redirects all print commands directly to the MIDI Out based on the new MBHP_TV protocol. By changing the device ID up to 128 "MLCDs" can be addressed in this way - not only the MBHP_TV itself, but also other "slaves" which support this protocol (example driver for a character LCD as slave will follow). I also plan to include a "soft font" feature into the MBHP_TV which allows to create special characters dynamically like known from character LCDs - hold the line ;-) Best Regards, Thorsten.

1A! :-) Did you know that Phil aka pkstone is working on a similar instrument? http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=mios;action=display;num=1046457465 Maybe you could collaborate together. Best Regards, Thorsten.

Man benoetigt fuer dieses Feature auf alle Faelle eine neue Firmware, die zwei Parameter-Sets gleichzeitig im RAM haelt. Zum ersten Mal ist mir diese wirklich brauchbare Funktion beim AN1x aufgefallen, auch Reaktor bietet sie mittlerweile, es wird also Zeit, dass auch die MIDIbox so etwas unterstuetzt. Wegen des doppelten RAM-Verbrauchs wird sich das aber nicht mit dem PIC16F realisieren lassen (es sei denn, man reduziert die Anzahl der Potis, aber ich moechte mir den PIC16F wirklich nicht mehr antun...)... ich werde es bei den PIC18F Versionen der MB64 und MB16E beruecksichtigen. Gruss, Thorsten.

Hallo Pearl, "app_lcd.inc" fehlt im Archiv, das wird bei der naechsten Version nachgeholt. Quickfix: dieses File befindet sich auch in der MIOS Release, kopiere es einfach in das midibox_lc* Verzeichnis Gruss, Thorsten.

Thanks! :) I started the MBHP_TV as a new challenge to learn something new (e.g. to find a solution for an isochronous system which never gets out-of-sync), it's another topic if a display with such a low resolution is usefull or not. But it awakes some vintage feeling - if MIOS would support a keyboard and a mass storage device (PRESS PLAY ON TAPE...), you would have a complete homecomputer ;-) The fascinating thing on this project is that you can see the execution time of a routine directly on screen. Every pixel "consists" of 4 PIC instructions executed within 400 nS - I could also display a pixel with one instruction only, but the PIC18F452 doesn't offer enough memory to store so much data. However, the code is now released and can be found in the MIOS download section (still PAL only), the resolution is 128x64, only one character set is supported yet (but additional fonts could be included) - character size 8x8 (16x8 display) Following SysEx commands are available: ; o Clear Screen: ; f0 00 00 7e 3f 00 00 f7 ; o Set Cursor Pos and Print Characters: ; f0 00 00 7e 3f 00 01 <pos> <char_1> <char_2> ... <char_n> f7 ; o Print Characters (don't set cursor): ; f0 00 00 7e 3f 00 02 <char_1> <char_2> ... <char_n> f7 The MBHP_TV module will be supported by the next MIDIbox LC version :) Best Regards, Thorsten.

How about a big MTC display a nice meter bridge a CC parameter screen a MIOS status display on your TV? is coming soon :-) Based on the Video HowTo from Rickard Gunee http://www.rickard.gunee.com/projects/ Schematic: http://www.ucapps.de/mbhp/mbhp_tv.pdf (you can just re-use your existing MBHP_CORE module and add the two resistors for the Video Out) Preview firmware: http://www.ucapps.de/tmp/mbhp_tv_preview.syx.zip (only prints this intro on screen) Specs: standalone application, display accessible via MIDI, resolution: 128x64, black-white only, currently PAL only, NTSC planned. Best Regards, Thorsten.

Hallo, Die Anzahl der Digits, die von der Applikation angesteuert werden koennen, ist nahezu unbegrenzt :) Siehe auch: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1061838266 Nein, MIOS hat schon immer die Ansteuerung von LED Digits unterstuetzt, lediglich das Programmierbeispiel fehlte... es ist nun unter MIOS->Downloads zu finden. Gruss, Thorsten.

You have to use a temporary register like TMP1 or (better) MIOS_PARAMETER1 ..2 or ..3 (which should be prefered for low-level function) to compare the value by using a xor instruction. Btw: a 8 bit value can also be divided / 16 by using the swapf instruction And you can write 0xff to a register by using the setf instruction And you can left out the return by using "goto" instead of "call" (since the function behind the call will execute the return instruction anyhow) Example: swapf INDF0, W andlw 0x07 movwf MIOS_PARAMETER1 xorlw 0x07 ;; result: zero if value matches skpnz setf MIOS_PARAMETER1 movf MIOS_PARAMETER1, W goto MIOS_LCD_PrintChar Have fun :) Best Regards, Thorsten.

Hi Wilba, your assumptions in a) and b) are correct. USER_SR_Service_Finish gets called directly after the DIN registers have been updated. By using the MIOS_DIN_SRGet function (WREG=0) you will get a pointer to the first register and you can iterate over all 16 registers by incrementing the pointer. Before USER_SR_Service_Finish will be called, also another usefull array will be updated: SR_DIN_CHANGED which notifies a transition for every single bit. You just only have to add 0x10 to FSR1. Btw.: if you want to prevent that USER_DIN_NotifyToggle will be triggered, since your own handler already takes care for some pins, just delete the appr. flags which are related to the appr. DIN. Example: USER_SR_Service_Finish ;; get pointer to first DIN register call MIOS_DIN_SRGet ;; add 0x10 to pointer in order to address the DIN_CHANGED register movlw 0x10 addwf FSR1L, F ;; check for transition on input #3, if not, exit IFCLR INDF1, 3, return ;; prevent that USER_DIN_NotifyToggle will be triggered bcf INDF1, 3 ;; switch back to DIN register movlw -0x10 addwf FSR1L, F ;; branch depending on pin state IFCLR INDF1, 3, rgoto XXX_0 rgoto XXX_1 On the other hand: it would be interesting why you don't plan to use the standard handler --- example for USER_DIN_NotifyToggle ;; branch depending on state of "shift" button (connected to pin #0) movlw 0x00 call MIOS_DIN_PinGet bz USER_DIN_NotifyToggle_SendCC rgoto USER_DIN_NotifyToggle_SendNote ;; ... Assignments of the pins: bit #0 corresponds to D0 of a shift register, etc. Best Regards, Thorsten.