TK.

Bitte mit dem Basteln warten, bis die MIOS basierende MIDIbox SEQ released wurde - es gibt mehrere moegliche Hardware-Optionen, und diese werde ich erst nach der Release dokumentieren. Gruss, Thorsten.

Doch, das geht :) Man kann fuer jeden Track einzeln den sogenannten Controller-Modus aktivieren, damit wird die Poti-Reihe (MB64 based design), bzw. Encoder-reihe (neues design) vom Sequenzer ausgelassen, und man kann stattdessen CCs (oder was auch immer) direkt versenden. Auf diese Weise ist es also moeglich, einen oder mehrere Tracks fuer Realtime-Controls freizuhalten. Gruss, Thorsten.

Set the download rate of vmidibox to 150 bytes/s --- this info can be found in the MB64 changelog Best Regards, Thorsten.

This strange noise is caused by a ground loop, just ensure that neither the shield of MIDI In, nor the MIDI Out is connected to ground (although the ground connection can be seen in the core schematic, for synthesizers with Audio Outputs like for the MBSID it's better to remove it) Note Hangs: sometimes happens when using the PIC16F, thats a known problem and cannot be solved. The PIC16F is not powerfull enough to handle every MIDI event in realtime when the SID software engine is under full load (too much features). Solution: use a PIC18F MIDIbox crashes when fridge (or soldering iron...) starts to work: EMC problem, a metal case could help. Best Regards, Thorsten.

P.S.: we checked the AOUT module against a Doepfer MCV24, the output voltage of the AOUT is much more stable (accurate) compared to this commercial solution ;-) Means: in difference to the Doepfer solution a note or CC always leads to exactly the same voltage Best Regards, Thorsten.

The AOUT module works very stable, I tested it together with a guy who owns a lot of nice analog gear some days ago. Want to have an impression? ;D But the schematic is not final! I will possibly add some caps to the digital power supply, just to improve the s/n ratio (but it's already ok - just a prevention measure) And I will add a connector for the 8x8 AMUX extension, so that a single MB64 (later also a seperate application) can drive up to 64 CV outputs Best Regards, Thorsten.

A new release of the MIOS based MIDIbox64 is now available on the MIOS Download page: http://www.ucapps.de/mios_download.html A lot of new features have been integrated, especially for a minimum setup with 16 pots, for the AOUT module, an optional datawheel, MTC and MIDIclock/BPM display and different display sizes (dedicated layouts for 2x16, 2x20, 4x16, 4x20) - see the ChangeLog: http://www.ucapps.de/midibox64_changelog.html Thanks to Matthias Schreiber who implemented the page feature (16 pot variant) and the 2x16/2x20 layout, and PayC who improved the 4x16 and 4x20 layouts. Best Regards, Thorsten.

The MBSID sid_sr driver activates the write enable line for exactly 1.2 uS to avoid timing conflicts. It doesn't matter if a register is written once or twice in between this period, the effect is the same... Best Regards, Thorsten.

The cheapest embedded PC is maybe the X-Box... ;-) However, here some links: http://test.elektroniknet.de/topics/embeddedsystems/produkte/2003/0002/index.htm http://www.pcengines.ch http://www.controlled.com Best Regards, Thorsten.

The encoders are presents from Ian Hurlock and D2K :-) The middle ones are from the china deal (see http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=parts_q;action=display;num=1051948494;start=0#0) The resolution is poor (MIOS_ENC_MODE_DETENTED2), but on the other hand they are perfect for controlling note values. I'm using them with following speed settings: movlw 3 ; predefined speed movwf MIOS_PARAMETER2 movlw MIOS_ENC_SPEED_FAST ; fast mode movwf MIOS_PARAMETER1 movf TMP1, W ; encoder number call MIOS_ENC_SpeedSet so that values can be changed from 0 to 127 with a single fast turn (270°), and incremented by +/-18 per revolution with a slow turn The one at the right side is a panasonic encoder (see http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1060000023) Like Dan wrote: the response is excellent! Setup: MIOS_ENC_MODE_DETENTED and movlw 2 predefined speed value for datawheel movwf MIOS_PARAMETER2 movlw MIOS_ENC_SPEED_FAST ; fast mode movwf MIOS_PARAMETER1 movlw DEFAULT_ENC_DATAWHEEL ; encoder number call MIOS_ENC_SpeedSet Best Regards, Thorsten.

Kannst Du mir mal das geaenderte mios_clcd.inc zuschicken? Dann mache ich Dir ein app_lcd.inc daraus. Warum es kein USER_LCD_Data und USER_LCD_Cmd gibt? Weil die Bedeutung je nach Display-Typ voellig verschieden ist. Die x'en sind evtl. die Sonderzeichen, vielleicht auch der Cursor. Wie auch immer, das wuerde sich mit einem sauber programmierten Custom LCD Treiber aendern. Gruss, Thorsten.

Wow! It comes with a big spare area for a big LCD and a lot of rotary encoders :) Best Regards, Thorsten.

What is the maximum resistance value of the pot? Hopefully 10k - or higher? Best Regards, Thorsten.

What is the maximum resistance value of the pot? Hopefully 10k - or higher? Best Regards, Thorsten.

By using an external MIDI translator it's possibly easy to turn this device into a full LC, and the translator could also handle with the additional buttons and the jog wheel. But the costs... hm.... Best Regards, Thorsten.

Remind that the development and documentation of another hardware platform possibly requires more effort than you really want. During the last years I've read from a lot of people who planned something similar, but finally gave up due to unexpected problems. Don't think that bigger microcontrollers can do the IO handling much faster than a PIC18F, and keep in mind that once you are using external memories, good system knowledge and soldering skills are required. The setup of a new platform and operating system requires good debugging tools, mostly they are not free available (maybe ARM7 would be a good solution, but a useful IDE costs at least 2000 EUR!) So, from my experience I can give you following advice: if you plan to implement a much more powerfull, reproducible, standalone DIY sequencer with fast success and open possibilities, than use a cheap embedded PC board, use Embedded Linux as operating system, and use an external PIC18F452 (running under MIOS) to handle with the control elements (buttons, encoders, LCDs, LEDs, etc.) - connected via RS232 to the PC. The advantage of this approach would be, that everybody who owns a PC (from 386 upwards) can try your software, so there is no need for bying expensive hardware for the first tests. Best Regards, Thorsten.

The -force option doesn't help here, it forces the script to generate a .syx file without the MIOS address range, regardless if it's embedded in the .hex file or not. You have to use the "-os_upload" option instead. This is described in the README.txt of the binary release, but not in the source release - I will fix this. As Duggle already mentioned, the MIOS upload works only with the primary loader. The reason why I removed the hint of using "-os_upload" from the script is, that a common user may overwrite MIOS in this way - see also this posting http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1067609574;start=4#4 Best Regards, Thorsten.

The -force option doesn't help here, it forces the script to generate a .syx file without the MIOS address range, regardless if it's embedded in the .hex file or not. You have to use the "-os_upload" option instead. This is described in the README.txt of the binary release, but not in the source release - I will fix this. As Duggle already mentioned, the MIOS upload works only with the primary loader. The reason why I removed the hint of using "-os_upload" from the script is, that a common user may overwrite MIOS in this way - see also this posting http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1067609574;start=4#4 Best Regards, Thorsten.

Der Stromverbrauch von Deinem Display ist ziemlich hoch, nunja... musst Du mal ein wenig herumfrickeln. Vektoren: ersetze "EQU <MIOS-addresse>" einfach durch ein "EQU <USER_LCD-adresse>". Du musst die Adresse nicht als Zahl angeben, hier reicht auch das Label Hast Du das ", 1" hinter den call und return Befehlen mittlerweile entfernt? Mir ist eingefallen, warum ich diese Option aus meinem Hirn geloescht habe - weil man sie innerhalb einer MIOS Applikation niemals anwenden sollte ;-) MIOS verwendet bereits die Shadow-Register fuer den schnellen Kontextswitch bei Interrupts. Wenn Deine LCD Routine nun die Shadow-Register ueberschreibt, kracht es, sobald ein Interrupt die Displayroutine unterbricht. Weil ich Deinen Code nicht kenne, kann ich ansonsten nur noch raten - vielleicht verwendest Du TMP1? Sollte innerhalb eines Treibers aber niemals eingesetzt werden - nur die die im Header angegebenen Register sind erlaubt, es gibt spezielle temporaere Register fuer den Display Driver (MIOS_GLCD_TMPx) Gruss, Thorsten.

No, the data transfer rate would be much slower than reading from an IIC EEPROM. So long most pins are free, you could hook a 128k SRAM (like the 628128 ) to the core directly - here an example: data lines could be connected in parallel to the LCD port, 8 address lines could be multiplexed with the data lines like known from 8051 designs (by using a 74HC573 latch) 8 additional address lines could be connected to J5 the remaining address line to J7:RC the chip select to J7:SO the latch enable to J15:RS the R/W to J15:RW You need to implement a (simple) read and write routine for RAM accesses (RAM_Write, RAM_Read) and put it into your application. The resulting access time should be about 2 microseconds (ca. 20 instructions) - fast enough for large data structures. SRAMs can be buffered with a small 3V battery Best Regards, Thorsten.

Again a great work by PayC:

Again a great work by PayC:

Hallo Ferdi, lies Dir am besten mal die Informationen auf der MIDIbox SEQ Seite durch. In den News findet man nun zusaetzlich eine Menge Infos zu der neuen (auf MIOS basierenden) Implementierung. Diese laeuft selbstverstaendlich auch auf einer MB64 (Stichwort: "Vintage Design"), mit der neuen Hardware laesst sich jedoch wesentlich ergonomischer arbeiten. Gruss, Thorsten.

Hallo Ferdi, lies Dir am besten mal die Informationen auf der MIDIbox SEQ Seite durch. In den News findet man nun zusaetzlich eine Menge Infos zu der neuen (auf MIOS basierenden) Implementierung. Diese laeuft selbstverstaendlich auch auf einer MB64 (Stichwort: "Vintage Design"), mit der neuen Hardware laesst sich jedoch wesentlich ergonomischer arbeiten. Gruss, Thorsten.

Also irgendwie sieht das ganz seltsam aus, weder call noch return erlauben ein zweites Argument. Der Assembler scheint an dieser Stelle wohl etwas zu tolerant zu sein. Ich nehme an, dass diese Funktion alle Zeichen ab 0x40 nach 0x28 mappen soll. Das koennte man auch so schreiben: USER_LCD_CursorSet movlw 0x10 rcall USER_LCD_Cmd SET_BSR MIOS_LCD_CURSOR_POS movf MIOS_LCD_CURSOR_POS, W, BANKED BIFSET MIOS_LCD_CURSOR_POS, 6, BANKED, addlw -(0x40-0x28) rgoto USER_LCD_Data Der Trick: in der zweiten Zeile ist Bit 6 gesetzt - das BIFSET macro (dahinter steckt die btfsc Instruction) tested dieses Bit und zieht 0x18 (0x40-0x28 ) davon ab - so wird aus 0x40 eine 0x28 Sonderzeichen: Du koenntest in mios_vectors.inc "MIOS_CLCD_SpecialCharInit" und "MIOS_CLCD_SpecialCharsInit" auf Deine eigenen Funktionen umlenken Vermeiden der Stoerungen waehrend des Einschaltens: dazu kann ich nicht viel sagen, ich habe noch nie mit einem VFD gearbeitet, weiss nicht, wie das mit der Stromaufnahme ausschaut. Vielleicht ist auch einfach nur Dein Netzteil zu schwach, so dass es waehrend des Einschaltens zu einem kurzen Spannungseinbruch kommt. Gruss, Thorsten.