TK.

Hi KD, when I read your comments concerning my skills I come to the conclusion that for you hardware design is only related to the physical layer, means mainly PCB layout, circuit definition and component selection. This seems to be your area of expertise, and I'm happy that you are helping to improve and enhance this part of the project. This was never the work that I liked to do, for me it is just a job which need to be done to realize ideas. I was always very lucky once I got this part behind me as fast as possible (quick schematic, quick layout, without thinking that much about more adequate components or design rules) in order to start with the more enjoyable work. I'm a little bit displeased about the general statement '"not" a hardware designer', but I know how to get it (I can live with such comments, and nobody needs to praise me or give credits before doing this). Maybe I should mention here in defence that I'm involved in hardware design for a big company in germany - but when I'm speaking about hardware here, I mean HDL design for system on chips (silicons). A completely different area, more abstract work, and I'm happy that this job has not that much to do with layout, electromacnetical effects or all that stuff which doesn't make fun - this is the area of other experts (the big advantage when working in a team). For myself the purpose of programming software is just to stimulate the system. When you are amused about those software guys who are driving such a DSP patchwork out-of-spec, I'm lauging about the same guys who are not able to reach a better performance at lower speed and less power consumption + a higher reliability by understanding the relations in the system completely, programming adequate algorithms, defining and creating peripherals which relieve the CPUs. However, I also make such errors, but I'm doing the projects privately to improve my skills in such areas. Ok, so much about my personal focus. Back to the topic: I think that you mainly want to make clear that the circuits have some room for improvements; this is understood and accepted. You are absolutely right when saying that we can run into trouble with the platform today if we don't take care about even such simple rules, and that some modules could especially not work properly anymore when they are not used in the same way like at the moment (e.g. once they are partly driven by a FPGA - the way I want to go in future). These are also bad examples for people who are starting with electronic design and thinking (unreflected) "if TK is doing it in this way, it must be ok" (I whish this only for copycat companies who are cloning the designs ;-) So, better to correct this "smoothly" in the next months than doing it later under pressure. Am I right in the assumption that as "first aid" adding caps at the bottom of the PCBs (I'm asking the experts: are 10 nF better for future higher speed designs?), and 10 uF near to the power input (100 uF for the DOUTX4) are adequate enough for most modules? This would only cost me a little documentation effort. Or is this no real help, since the routing of the power rails also has to be changed? (no further comment on this to hide my incompetence in this area) Best Regards, Thorsten. P.S.: long ago a wise man wrote: "Experience is something you don't get until just after you need it"...

Hi Tom, the schematics are always the reference (I will change the value in the eagle file) Best Regards, Thorsten.

Hallo, eigentlich koenntest Du jede beliebige Referenzspannungsquelle hernehmen, die eine Spannung <= 3.6V liefert. Leider weiss ich gerade keine alternative Loesung (die ich schonmal selbst ausprobiert haette), aber vielleicht hat ja jemand anderes einen Tip parat Gruss, Thorsten.

Hi Robin, you cannot specify such variations in an .ini file which is fixed to the application specs... How to use pots: this is described in the ain* examples (read the comments in main.asm and do some experiments with this application before integrating the required code into the midio128) Toggling buttons via MIDI: do you really want to implement this in this way? It would mean that the remote side would never know if the button state is "on" or "off" - it's normaly better if the MIDI transmitter toggles the state (0x00 -> 0x01 -> 0x00) Best Regards, Thorsten.

Hi, I can only say that it should work (even with the default sensibility setting) without toggling, just like with a normal button. How does your touchsensor look like? Best Regards, Thorsten.

Hi Yaiy, could it be that you are trying to upload MIOS after the 2 second power-on phase? This won't work, you have to start the upload immediately after the upload request message like described in the MIOS bootloader page Best Regards, Thorsten.

I see! :-) The tables in midio_presets.inc are limited to 128 entries due to the static sysex structure, but you can always create new tables at different places (e.g. directly in midio_meta.inc) Best Regards, Thorsten.

Yes, you can (nice one!) Best Regards, Thorsten.

See this posting http://69.56.171.55/~midibox/forum/index.php?topic=3414.0 Andrew, what is the status of this project? Best Regards, Thorsten.

The schematic can be downloaded from this location: http://www.midibox.org/users/kd/kd_fmsid.pdf It shouldn't be a problem to forward an envelope output to the shift register (ca. 1.5 uS execution time), is there somebody who wants to try this out? Best Regards, Thorsten.

This soundchip has so much registers, that they should be accessed with a parallel interface to reduce transfer time (see OPL3 module - the bus can be driven with the same pins like the LCD). You can use a 8-bit latch like the 74HC373 to multiplex the data and address bus. I'm not sure if the PIC is the right chip to control so much oscillators, maybe a 16bit chip is better due to the larger address range and faster processing of 16bit maths. Why not using an old Atari ST to drive the chip? Best Regards, Thorsten.

Hi, there are very obvious reasons why I left out the bypass caps on most modules: I was forced to limit the PCB area so that it fits with a euro size board. This was due to Eagle freeware license limitations (e.g., it isn't possible to create a board which is larger than 100 mm), and due to the yield (number of modules which can be made from one euroboard) which was a requirement from Mike to keep the costs low. I think that SmashTV has the same requirements - please correct me if I'm wrong! So, my idea was, if additional caps are really required, then they could be mounted at the bottom of the PCB. Since MBHP will never go into a professional production, where manual effort counts, I thought that this would be an adequate solution. But then I did some experiments with chained DINX4 and DOUTX4 modules and noticed no problems even without caps - also no "beta tester" reported problems - so I left them out from the schematics (my general worldly wisdom: so long nobody proves the converse, I don't believe it ;-) I learned in university that bypass caps are required to store and release energy on high current peaks. Leaving out the caps can lead to EMI issue, e.g. short low-voltage bursts at neighboured gates which affect the functional behaviour, or emitted signal noise on analog circuits. That impedances/resonance frequencies between the gates and wires can also play a role, was new to me - it sounds disastrous, but I have to read some literature before I can give a statement on this. Are you sure that this is not an issue of HF logic and/or high power designs only? Ok, I also have to say that at the beginning where I defined the MBHP my focus was on digital data processing, where signal noise doesn't hurt so much like on mixed signal designs, so long frequencies are relatively low (< 50 MHz) and the TTL levels are stable. Using analog circuits (like the SID, AOUT, OPL3) was a new field which came later, and which was not taken into account from the beginning. Not sure how the MBHP would look today if it would be designed from scratch. As Duggle mentioned: it makes sense to consider such things on future designs. However, if somebody thinks that he can reduce jitter on the analog inputs or background noise on the SID by following this suggestion, then add 10nF or 100nF caps at the Vss/Vdd pins of each IC from the bottom + one 10 uF per module (or 100 uF for modules with high current consumption like mentioned above), but from my experience it won't solve the problems. Perhaps you will notice absolutely no difference - bypass caps cannot reduce glitches and spikes, and they also don't help to eliminate ground loops and all those disturbing factors. Maybe I should also mention that I don't hear any additional noise frm the SID when all 99 LEDs of the control surface are toggled with different frequencies. Why? Because the SID power lines are wired starlike from the PSU. Seems that this was sufficient. However... Karl, I must say that I'm happy about your posting. It's an important reminder (I swear that the next MBHP modules will be littered with bypass caps in future ;-) and contains some interesting informations about pot wiring, 4051 muxing, sockets too Sidenote: the jitter monitor application from the MIOS download page demonstrates that caps against ground or shielded cables won't improve the signal quality here - maybe because of the reduced ADC resolution of 10bit. The jitter is normaly 1 bit, and this is caused by the 1/2 LSB error which can be found on any ADC. Sometimes I think that people are just too afraid that they are doing something wrong when they are "violating" such rules which are common in other design areas. This comment should not decrade your input! Best Regards, Thorsten.

Hi Stefan, here an excerpt from the midibox64 application: ;; -------------------------------------------------------------------------- ;; This function scales a 7bit value depending on a min and max value ;; If the min value is greater than the max value, they will be ;; automatically converted to realise a reversed scaling ;; Input: ;; o 7bit value in WREG ;; o min value in MB64_POT_MIN_VALUE ;; o max value in MB64_POT_MAX_VALUE ;; Output: ;; o scaled value in WREG and MIOS_PARAMETER1 ;; USES: MIOS_PARAMETER1 and MIOS_PARAMETER2 ;; -------------------------------------------------------------------------- MB64_POT_ScaleValue ;; save pot value in MIOS_PARAMETER1 movwf MIOS_PARAMETER1 SET_BSR MB64_BASE ;; send min value if min == max movf MB64_POT_MIN_VALUE, W, BANKED IFNEQ MB64_POT_MAX_VALUE, BANKED, rgoto MB64_POT_ScaleValueDo movwf MIOS_PARAMETER1 rgoto MB64_POT_ScaleValue_End MB64_POT_ScaleValueDo ;; set MIOS_PARAMETER2[0] if min > max bcf MIOS_PARAMETER2, 0 movf MB64_POT_MAX_VALUE, W, BANKED IFLEQ MB64_POT_MIN_VALUE, BANKED, rgoto MB64_POT_ScaleValue_NoConv bsf MIOS_PARAMETER2, 0 MB64_POT_ScaleValue_NoConv ;; scaled value-1 = ((current value+1) * (max-min+1)) / 128 ;; swap max/min if MIOS_PARAMETER2[0] set ;; multiply current value * (max-min+1) IFSET MIOS_PARAMETER2, 0, rgoto MB64_POT_ScaleValue_Inv MB64_POT_ScaleValue_NoInv movf MB64_POT_MIN_VALUE, W, BANKED subwf MB64_POT_MAX_VALUE, W, BANKED rgoto MB64_POT_ScaleValue_Cont1 MB64_POT_ScaleValue_Inv movf MB64_POT_MAX_VALUE, W, BANKED subwf MB64_POT_MIN_VALUE, W, BANKED ;; rgoto MB64_POT_ScaleValue_Cont1 MB64_POT_ScaleValue_Cont1 addlw 1 mulwf MIOS_PARAMETER1, ACCESS ; multiply with current value ;; divide result by 128 (result >> 7) ;; good trick: just shift the upper bit of the low byte into the high byte rlf PRODL, W rlf PRODH, W andlw 0x7f ;; add min or max value depending on MIOS_PARAMETER2[0] btfss MIOS_PARAMETER2, 0 addwf MB64_POT_MIN_VALUE, W, BANKED btfsc MIOS_PARAMETER2, 0 addwf MB64_POT_MAX_VALUE, W, BANKED ;; store result in MIOS_PARAMETER1 movwf MIOS_PARAMETER1 MB64_POT_ScaleValue_End movf MIOS_PARAMETER1, W ;; return immediately if inversion bit not set IFCLR MIOS_PARAMETER2, 0, return ;; else inverse the result subwf MB64_POT_MIN_VALUE, W, BANKED addwf MB64_POT_MAX_VALUE, W, BANKED movwf MIOS_PARAMETER1 return [/code] Note: MB64_BASE is the base pointer to the page where MB64_POT_MIN_VALUE and MB64_POT_MAX_VALUE are located. Best Regards, Thorsten.

Hi Rob, it looks like a nice text adventure ;-) "dmusuart" could contain all informations which are required to create a MIDI device, if this can be linked to the MPUSAPI DLL, then an adaption should be easy - everything is there, it only has to be combined correctly. Does Microsoft allow the re-use of examples if somebody hasn't purchased the DDK, or is this prohibited by the license? Alternative possibilities: we could ask for help from Hubert Winkler (he made "Hubis Loopback Device" and published the source code, unfortunately it's written in Pascal: http://members.nextra.at/hubwin//midi.html), or Jamie O'Connell who made MIDI-Yoke (http://www.midiox.com/index.htm?http://www.midiox.com/myoke.htm). Both drivers are multiclient capable Best Regards, Thorsten.

Hi Rob, just send me your code and I can have a look whats going wrong. I haven't started with my own USB firmware yet (planned for easter holidays), but if your project is doing the same, then there is no need for reinventing the wheel and I can concentrate on other things. :) Priority: the USART receiver should have the highest priority, since MIDI doesn't provide a handshaking mechanism. Thereafter the MIDI transmitter to prevent MIDI Out buffer overruns. USB can get the lowest priority Best Regards, Thorsten.

Hi, it is possible, but very very hard (especially for somebody who never trained this on some cheap SMD chips before). The risk for damage is very high. -> see the MBFM prototype board: Best Regards, Thorsten.

can you give me a link to an example? Best Regards, Thorsten.

Hi, to the touch sensors: you have to adjust the touch sensor sensitivity, this can be done in the editor or in the mk_syx script (see also http://www.ucapps.de/howto_tools/vmb64_2.gif) DIN programming: no time, but maybe somebody else? Tip: learn how the DIN hook is working by reading the example programs (can be found in the MIOS download section) - they include a lot of useful comments. Thereafter just start to include your extensions into the MB64 application. You only need to increment/descrement the MB_BANK variable, thereafter brahch to MB64_BANK_Change, and thats all Best Regards, Thorsten.

Hi Robin, I wouldn't use this configuration area for such extensions, the implementation is too difficult for that what you are doing, and I don't think that you are planning to enhance the perl script (mk_midio128_syx) in order to edit the modes. It's easier to define special MIDI events for radio groups, and to handle them in a similar way like program change events. You could use "0xf0"-"0xff" for such extensions, such "Meta Events" are automatically forwarded to midio_meta.inc (read the comments in this file) Best Regards, Thorsten.

Great! I will add this hint for the COM interface to the Bootloader page :) Best Regards, Thorsten.

See also this posting http://69.56.171.55/~midibox/forum/index.php?topic=4047.0 you can save a lot of money with a batch order Best Regards, Thorsten.

Hi Mikael, can you please inform Mike and Claudia about this mistake? Schematic and layout are matching, but the values in the eagle file are not up-to-date due to different requirements (I don't think that it makes sense to release different eagle files for different SIDs where the routing is identical). Your SID will work without C4, but it's better to stuff it sooner or later in order to improve the signal/noise ratio. C6 is only required when the Audio In is used. C9 can be 1000 uF if your are using a good PSU, 2200 uF if an AC transformer is connected to J1 Best Regards, Thorsten.

Hi, Doug: good hint, I will add a SPI port. It's just a 2-pin header at RB0 and RB1 The firmware will give enough room for such extensions. I guess that it will onl takes ca. 1-2k (if written in assembler), the bootloader takes 2k, so 28k are still free for experiments. Performance isn't an issue (the core is clocked with 48 MHz) Andrew: the P18 software itself is in english - it provides a hardware debugging window which allows you to check if the PIC programming pins (MCLR, Vdd, RB6, RB7) can be controlled in the right polarity. If it doesn't work, then you can possibly fix this by changing some pins at the parallel port (do you need more details? Best Regards, Thorsten.

Hi, great to hear that I'm not the only one who is working on a PIC based USB-MIDI solution - do you plan to publish the source code to the public domain? It would be a big help for people who want to do extensions (like USB-Audio, IO control, etc) To the descriptors: the old MBHP_USB firmware package contains the source code (-> http://www.ucapps.de/mbhp_usb.html), the descriptors can be found in "dscr.a51". Small changes can bring your windows installation to a blue screen. E.g., WinME and Win2k are crashing when you are defining an empty Audio Control device (like suggested in the USB-MIDI spec), therefore it is left out And now the fun begins: the released version doesn't work on all WinXP systems, some installations require a modified one which will be regognized correctly, but causes a crash under Win2k - due to this mess I'm thinking about a selfwritten Windows driver based on the Microchip framework - does anybody have experiences with Win driver programming? Best Regards, Thorsten.

Some time ago I made a SID remix of "No Birthday" from JCH, which is now available at http://remix.kwed.org Best Regards, Thorsten.