TK.

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.

Some short comments to the Panasonics: Steven C sent me three of his faders a week ago for testing. I will do this in one of the next days/weeks after I've finished some other stuff. I wrote to Steve: -> MIOS V1.4 will provide a special option for Panasonic faders Best Regards, Thorsten.

You could manually trigger MIDI events by using a cable, connected to ground, and tapping it to the DIN chain input. However, if the Tx firmware doesn't work, the MB16E won't work, too -> Hardware issue Best Regards, Thorsten.

Hi, you possibly have to disable the CBM8580_FILTER_FIX switch in main.asm Have fun! :) Best Regards, Thorsten.

For the records: the SID's which I own: 1 * MOS 6581 CBM / 3183 (perfect sound, warm filters) 1* MOS 6581 CBM / 2584 (perfect sound, low signal-noise ratio, warm filters) 1* MOS 6581 CBM / 4084 (distorted sound, but nice for fat leads, used in mbsid_demo8.mp3) 1* MOS 8580R5 / 3389 25 (see below) 1* CSG 8580R5 / 4388 25 (see below) 4* CSG 8580R5 / 5092 25 (perfect sound, very high signal-noise ratio, fat filters, see mbsid_v1_5_filter.mp3) Best Regards, Thorsten.

These are driver examples, the possibilities are unlimited, if you plan to use it with other configurations, you are able to change the code in order to adapt it to your hardware. If you want to connect more than 64 LED digits (512 LEDs by the way...), just time-multiplex 16 digits (makes 3 shift registers for 16 digits -> 80 digits = 640 LEDs) --- they won't be so bright like with the 8x8 configuration, but you shouldn't notice flickering. Another solution would be the use of an additional 7-segment decoder (idea by Pilo), so that one DOUT register can drive 2 patterns instead of 1. This would allow to drive 2*16 = 32 digits with 3 DOUT registers, makes 160 digits with a single core, makes 1280 LEDs As I wrote: feel free to change the driver for your needs ;-) Best Regards, Thorsten.

I will use the MAX525, a 4 channel DAC with 12 bit resolution. Latency is no issue (only limited by the transfer time, less than 5 uS (microseconds)). These DACs can be cascaded in a chain like the DOUT registers for a nearly unlimited number of channels. The driver will be embedded into the application and will be written in a way which allows to reuse the code for other DACs from other manufacturers - the adaption will be your job... Best Regards, Thorsten.

yes Best Regards, Thorsten.

Everything ok, but you should add the 4 10k pull-up resistors to RC0-RC3, otherwise the box will generate random events due to open inputs Best Regards, Thorsten.

Metering is supported by the Logic Control protocol, when you take a look into the source code you will already find the handler which converts the appr. MIDI events to bars which are displayed at the LCD The resolution (LEDs) is limited by the protocol, it's 8 channel Mono. It doesn't require an additional core. If you would like to realize a meter bridge for audio signals: this would be a seperate project, and this would require an additional core. Best Regards, Thorsten.

ok, Du verwendest also die unmodifizierte PIC18F firmware. Per default ist sie fuer den 8580 konfiguriert: ;; set this to '1' to enable the filter software workaround for the 8580 SID #define CBM8580_FILTER_FIX 1 demnach fuer 6581 -> ;; set this to '1' to enable the filter software workaround for the 8580 SID #define CBM8580_FILTER_FIX 0 also einfach das main.asm editieren, assemblieren, konvertieren und schliesslich das neue .syx file aufspielen. Gruss, Thorsten.

Hallo, der SID ist (zum groessten teil) ein analoger Chip, es ist voellig normal, dass er warm wird. Die aelteren Revisionen werden wesentlich waermer als die neueren (speziell 8580), aber das passt schon. Dass das Filter sofort sperrt ist allerdings seltsam. Welche Chip-Revision verwendest Du genau (komplette Typenbezeichnung), welche Firmware, und welche Kondensatoren sind an Pin 1/2 und 3/4 angeschlossen? Gruss, Thorsten.

daraus sind mittlerweile 16 digits pro DOUTX4 modul geworden :) nein - das LCD wird einfach direkt an J15 angeschlossen Gruss, Thorsten.

Yes, the bootstrap loader sends an upload request which is also a "sign of live" Please read the bootloader page carefully, there are a lot of things which have to be taken into account (I hope that I didn't miss anything...) Best Regards, Thorsten.

Did you read the new troubleshooting section in the MBHP_JDM page? The new mods are valid for every burner which are connected to the COM port... Best Regards, Thorsten.

Hallo Wolfgang, zum einen handelt es sich hier um eine kommerzielle Loesung ("muvium sells...") die mit Sicherheit nicht billig ist, zum anderen bezweifle ich, dass MIOS mit dem ganzen Java overhead noch performant laufen wuerde... MIOS muesste auf alle Faelle an den Compiler angepasst werden - eine sehr aufwaendige Angelegenheit, die unter Umstaenden sogar zu Abstrichen in der Funktionalitaet fuehren koennte. Deshalb werde ich auch damit nicht anfangen, bis ein wirklich brauchbarer (und vor allem fehlerfreier) C compiler verfuegbar sein wird, der frei erhaeltlich ist. Neue MIOS Release: in 1-2 Wochen Mit 2 DOUTX4 Modulen kann man sogar bis zu 24 Digits ansteuern, wenn man den Driver dementsprechend anpasst. :) Gruss, Thorsten.

Ich habe die Unstimmigkeiten nun geradegezogen: 1) egal, beide Gleichrichter sind ok 2) 470pF bzw. 6.8nF (siehe Beschreibung auf der MBHP_SID Seite) 3) egal, beide Kondensatoren sind ok 4) nein, keine verwechslung 7812: nimm den Spannungsregler, der Dir am besten gefaellt, der 78L12 ist kleiner, aber im Ausland schwer erhaeltlich, deshalb wurde das Board so designed, dass beide Regler passen Als Referenz dient grundsaetzlich immer der Schaltplan: http://www.ucapps.de/mbhp/mbhp_sid.pdf Gruss, Thorsten.

The MIDIbox64 of Pay_c - noble design, fits nice beside of a Virus! :-)

...and in this way all the spelling mistakes are well documented for the next centuries... ;-) Btw.: also the first location is available http://web.archive.org/web/*/http://mabuse.phil.uni-passau.de/~klose Best Regards, Thorsten.

Hi Steve, thanks a lot for this "kickstart" :-) I hope that others who already built the MIDIbox LC will add some tips&tricks&photos to make this project as transparent as possible for people who haven't followed the progress in the last months. The final document could be published in the new MIDIbox Portal (?) Best Regards, Thorsten.

The oscillators on the SID module are mounted for historical reasons - at the time where I started with this project I didn't know if the clock out pin (RC1 of the PIC) will still be free in the final version or allocated by the control surface. Fortunately the PIC18F is powerful enough, so that the pin is still available for clocking the SID. Using pots or other analog sensors: possible (see MIOS board). Assignments are not supported yet, but could be integrated in the future (also for rotary encoders) Best Regards, Thorsten.

Thanks Steve! The MIOS based version will be perfect for your case design, because it will allow to map the three parameters of one track to the three available pot rows :) Dan: the encoders are optional extensions and will be used: to control the BPM directly to select a patch directly as general purpose data wheel which replaces the cursor left/right buttons Best Regards, Thorsten.