TK.

Wenn ihr auf Nummer sicher gehen wollt, dann schickt mir vorher ein Sample! Gruss, Thorsten.

Hi Stefan, yes, you have to scale back the value from 0-100 to 0-127 Best Regards, Thorsten.

Hi gb, 1) in main.asm 2) in main.asm (outside a subroutine) 3) forwarding the value in WREG to J5_DOUT_Set is ok Did you call "J5_DOUT_Init" in the USER_Init hook? This is important to initialize the digital outputs Best Regards, Thorsten.

Hi Martin, looks bad for the SID - its very unlikely that it is still working (if you've luck only the 74HC595 are affected) LCD: you can check this by connecting only ground, +5V and V0 (the contrast input) to the LCD. If you can see the black bars at the top (like after startup so long the display is not initialized), then it could be ok Best Regards, Thorsten.

Hi Yaiy, I will change the comment in "Creates the configuration dumps for MIDIO128" in order to avoid that somebody is misleaded in the same way. No, I don't have any pet ;-) Best Regards, Thorsten.

Hi George, The LCD port can be left open - the RBx pins of the PIC have internal pull-ups which ensure that MIOS will regognize that no LCD is connected properly (the LCD driver will be switched off after Time-Out). To the jumpers: most pins are output pins, don't clamp them - Just left them open! R2, R9 and R10 should be stuffed to avoid latch-up. The pins at J5 of the core module should either be clamped (if you are sure) or stuffed with the pull-ups to select the options. The 16F874 code is very bad concerning MTC, it was not processed correctly in all cases Best Regards, Thorsten.

Hi William there is no MIOS driver for this chip available, but it looks very interesting! Because it seems that it supports the "vertical orientation" of a byte - an important requirement for fast display output ("horizontal orientation" leads to a poor performance which is insufficient for an application which should receive and process MIDI and drive graphics at the same time) Where are such LCDs available? Best Regards, Thorsten.

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.