TK.

Good news! SDCC has reached a good stability again, so that that the use of the "latest and greatest" build (>20050123) is highly recommented. Because of some conceptional changes in the compiler a new wrapper is required: http://www.ucapps.de/tmp/mios_c_wrapper_beta2.zip You can migrate your existing C code by copying all files from the skeleton directory (and subdirectories) except for main.c into your project directoy. The only change in main.c: void ENC_NotifyChange(unsigned char encoder, unsigned char incrementer) has been changed to: void ENC_NotifyChange(unsigned char encoder, char incrementer) Best Regards, Thorsten.

Hi Robin, to the JUMPTABLE macro: this is the right syntax: JUMPTABLE_2BYTES 10 ; entries change "andlw 0x03" by "andlw 0x0f" before the macro Table: you want to store 5 bytes per table entry. It's important to know about this assembler bug: it's not possible to create table entries with an odd size - the assembler will fill it to an even number (so that a table entry will contain 6 bytes instead of 5). In order to make this more clear, I suggest the use of 6 bytes per entry. Or better: 3 16-bit words. Here an example: ;; -------------------------------------------------------------------------- ;; In: index (table entry number) in WREG ;; Out: BankStick Address in MIOS_PARAMETER[12], ;; Dump Size in TMP[12], ;; BankStick number in TMP3 ;; -------------------------------------------------------------------------- BANKSTICK_DUMP_Get mullw 6 ; each entry has a size of 6 bytes ;; result of multiplication in PROD[LH] ;; add offset to base address of table (16-bit addition) ;; copy result to TBLPTR[LH] movlw (BANKSTICK_DUMP_TABLE & 0xff) addwf PRODL, W movwf TBLPTRL movlw (BANKSTICK_DUMP_TABLE >> 8) & 0xff addwfc PRODH, W movwf TBLPTRH ;; first entry: bankstick number tblrd*+ movff TABLAT, TMP3 ;; second entry: dummy, not used tblrd*+ ;; next two entries: bankstick address to dump tblrd*+ movff TABLAT, MIOS_PARAMETER1 tblrd*+ movff TABLAT, MIOS_PARAMETER2 ;; last two entries: counter tblrd*+ movff TABLAT, TMP1 tblrd*+ movff TABLAT, TMP2 return ;; the table BANKSTICK_DUMP_TABLE ;; BS Nr Addr Offs dw 0x0000, 0x1000, 0x1000 dw 0x0000, 0x2000, 0x1000 dw 0x0001, 0x1000, 0x1000 dw 0x0001, 0x2000, 0x1000 [/code] (not tested!) Best Regards, Thorsten.

Hi, where to you live? Maybe somebody who reads this forum lives near you and can help Best Regards, Thorsten.

Hi, P&G has a quality problem, see also http://forum.keyboards.de, and search for Mackie Control --- unfortunately the text is in german, but http://babelfish.altavista.com should help Currently it's also not clear if the MBHP_MF + the MIOS_MF driver can handle with a P&G fader correctly. Somebody reported bad experiences in the Troubleshooting section. But who knows, maybe he also got some defective faders from P&G :-/ Best Regards, Thorsten.

Hi rasOfir, there won't be explicit steps - but of course, you can build the synth step by step in a similar manner like MIDIbox SID. It's only important to know about the strict hardware requirements. I won't support the same flexibility like for MIDIbox SID - the higher complexity requires a large display, 8 soft buttons, etc... MIDIbox FM will already run with a single MBHP_CORE and MBHP_OPL3 board + at least one BankStick. In this case all parameters have to be controlled via SysEx (-> JSynthLib). Most of them can also be controlled via CC "CS Step A": requires one DINX4, one DOUTX4, a 2x40 LCD, 8 "soft button", one ESC button, one shortcut button, 4 INSTR/OP buttons, one INSTR/OP select button, 10 LEDs and one detented rotary encoder "CS Step B": requires 10 selection matrix buttons + 24 LEDs + 4 rotary encoders and thats all, you will have a complete MIDIbox FM Best Regards, Thorsten. P.S.: all schematics and interconnection diagramms are already published

Thank you! I must say that those random patches really make fun, I will create the same for MIDIbox FM :) Best Regards, Thorsten.

Thanks :) app_defines.h is the right name, don't rename it, otherwise you are not able to build the project anymore Best Regards, Thorsten.

I've created a short but useful perl script which can be used to generate an unlimited number of random patches. This script and 32 example banks (-> 4096 Patches) are now part of the preset library. -> http://www.ucapps.de/midibox_sid/preset_patches_20050123.zip (400k) Here some randomly picked random patches from a randomly selected bank (20) -> http://69.56.171.55/~midibox/midibox_sid/mbsid_demo_random_patches.mp3 (7.1 MB) (mostly the note C-3 is played, only in one case I've played a short tune (couldn't resist)) The perl script can be found in the random/ directory, so that you can create even more patches. Experts should try to change the constraints in order to have some more directive results. 4 Patches of js are now also part of the library Have fun! :) Best Regards, Thorsten.

Just gone through the synth-diy mailings, now it's clear what you mean with "SynthDIY Soddy" - I mixed it with "shoddy" ;-) Best Regards, Thorsten.

*grin* just compare the number of code lines against the number of bugs ;-) The only thing which makes me worry each time is that now we will notice an increased number of postings where people assume software bugs before they start to check their hardware. From my experience it will take 3-4 months until MIOS applications have reached the known confidence level again ;-) There are too much favourite MBs in the different categories, but last year no MIDIbox reached the originality of PulseBox16 (for the guys who don't remember the best design ever, here the design: http://homepage.ntlworld.com/keith.williamson/pb16--ad.jpg and here what the press said: http://homepage.ntlworld.com/keith.williamson/ecobox/images/midibox_mag.jpg) Best Regards, Thorsten.

Hi, 1) setup_mbseq_v2.asm: change MIOS_ENC_MODE_DETENTED to MIOS_ENC_MODE_DETENTED2 (this will be the default setting in the next release) 2) there is a known problem with such artifacts (see the (short) buglist), but they don't happen like described. This could be related to a problem with the DINs 3) use the MIDIO128 application (buttons send one note event, encoders send two note events) 4) bad solderings 5) bad solderings Best Regards, Thorsten.

Hallo Stefan, Du hast das Speicherlimit erreicht. Mehr passt nicht mehr in den PIC (woher kenne ich das Problem nur... ;-)) Ich habe vor ein paar Wochen ein paar neue Funktionen in die MB64E Applikation eingebaut (u.a. den sogenannten Patch Mode), in dieser Version wird es nicht mehr moeglich sein, die Parameter-Labels im internen Memory zu speichern. Das funktioniert dann nur noch mit BankStick - dadurch konnte ich nochmal 8k freimachen, die wahrscheinlich auch Dir sehr hilfreich sein werden. Eine Beta Release gibt es via EMail-Request Gruss, Thorsten.

Hallo, hier ist alles beschrieben: http://69.56.171.55/~midibox/forum/index.php?topic=3693.0 die aeltere SDCC Version werde ich heute Abend noch auf den neuen Server aufladen. Die aktuelle SDCC release ist immer noch ziemlich buggy (sporatische Abstuerze unter Windows), aber die Entwickler arbeiten dran Gruss, Thorsten.

Hi Dominik, it is possible by writing an own display driver (-> app_lcd.inc) and connecting the chip select lines to some free pins. It requires ca. one day of programming work when you know where the changes have to be made. If you've never implemented a driver for a graphical display before, it can take much longer... Best Regards, Thorsten.

Hi Dominik, you can add this additional LED for each meter by changing the pattern table in lc_meters.inc. The anodes of these LEDs have to be connected to a free pin of the second shift register which is used by Meters/LEDrings. So long you don't want to change the DOUT pin for the overdrive LEDs (currently D4), you could change the pattern in the following way: ;; 16 entries for meter pattern (can be changed if more LEDs connected) ;; note: the 12th LED (overdrive) will be inserted automatically in LC_METERS_PatternSet dw b'0000000000000000' dw b'0000000000000001' dw b'0000000000000011' dw b'0000000000000111' dw b'0000000000001111' dw b'0000000000011111' dw b'0000000000111111' dw b'0000000001111111' dw b'0000000011111111' dw b'0000000111111111' dw b'0000001111111111' dw b'0000011111111111' dw b'0001011111111111' dw b'0001011111111111' dw b'0001011111111111' dw b'0001011111111111' [/code] In this case the 12th LED has to be connected to D3 of the second shift register Best Regards, Thorsten.

The resolution shouldn't be a problem, the timing conditions are very relaxed in your code. Maybe I will find some time tomorrow to try this out. Best Regards, Thorsten.

Hi mb944, what a fancy project! :) I just have tested MIDIO128 on my MIDIbox SEQ and noticed exactly the same behaviour. This shocked me a little, because I don't remember that this problem occured during the implementation of the last changes. After some debugging I finally found out that in app_defines.inc the "MB_STAT_FETCH_DIN_REQ" flag is assigned to the same bit like "MB_STAT_DISPLAY_UPDATE_REQ" (a totally unexpected error) and this causes the flickering. So, when you change this flag to 1 and recompile the code, it will work. It will also work when you set the "DEFAULT_FORWARD_IO" option to 0 in main.asm (you have to do this anyhow), thats possibly the reason why there were no complaints about this error in the past, because most people don't use the forwarding option, this is only for testing the DINs/DOUTs Ok, and I found out why I never saw this problem: it was one of the last changes which I've tested on my MIDIbox LC which has a graphical display. Since characters are printed out slower than on a common LCD, the possibility that the wrong bit assignment affects the DOUT is much lower Best Regards, Thorsten.

Hi Robin, the 4byte jumptable macro is only required if you are using 32-bit instructions like "goto". So long you are using "rgoto" (an instruction which allocates 16-bit=2 bytes), the JUMPTABLE_2BYTES macro is sufficient. Please use JUMPTABLE_2BYTES (number-of-entries) instead of JUMPTABLE_2BYTES_UNSECURE (like the the firmware), otherwise you have to take care that the jumptable index never exceeds the table In "midio_presets.inc" you will find the "MIDIO_Presets_DIN_MODES" label, thereafter some table entries for the modes. Note that the mode is encoded in a special form (to save memory). Each hex-digit stands for one DIN pin, this means that up to 16 modes (0..F) are possible Best Regards, Thorsten.

Hi oszilla, 1000 different things... it's time to test your modules step by step. First I would suggest the upload of another application which simplifies the debugging Start with the MIDImon to check the MIDI input Thereafter use MIDIO128 to check the DIN/DOUT Results? Best Regards, Thorsten.

Hi Twin-X (my hero!) maybe "random patches" sounds like a feature which is easy to implement. But in fact a real useful random generator requires a lot of programming effort - and - a sophisticated user interface. Because you don't really want to have everything random, this would lead in most (99%) cases to unusuable patches, and/or to settings where you don't hear anything. A good random generator allows to set constraints for each parameter (min/max values), an even better generator allows dependencies ("if LFO5 depth > 30 then LFO6 depth < 30"). I fear that there is not enough memory free for such a function, it's possibly better (and much much easier) to program this as an external program (for the PC, with a nice GUI, etc...) Best Regards, Thorsten.

You've checked the voltages long time ago, but are you sure that each connection is still in place? I mean: sometimes people don't solder all components/cables well enough, bad junctions can cause random effects. You wrote that you got the correct messages through MIDI during the MIOS/application upload. But now you don't get any MIDI message on startup anymore, is this correct? Could it be that the bad junctions are around the oscillator, or the MIDI Out Port? The MIDI troubleshooting guide helps you to analyze such problems: http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

Yes, the transistor should be sufficient (it's a similar circuit like in the original C64 design). I don't know why an OP amp should be better in this case, maybe it's better to contact Buchi directly in order to get an sufficient answer Best Regards, Thorsten.

This is exactly the way how I would do it :) Best Regards, Thorsten.

I'm also not completely satisfied with the layout and still searching for all the new switches and levers ;-) Best Regards, Thorsten.

Thanx to Twin-X we have the possibility to test a new server -- which is very fast! :) I've installed a temporary forum so that we can test the connection from different locations: --> http://forum_test.midibox.org I've also uploaded some .mp3's to test the bandwidth, the maximum download speed I've reached was 124 kb/s (this is the limit of my ADSL line) --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo1.mp3 --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo2.mp3 --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo4.mp3 --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo5.mp3 Please write down your impressions here. If the server is working ok, I will move the original forum to the new location this weekend. Best Regards, Thorsten.