TK.

Hi Roger, thank you for turing this out (one year after the release ;-) everything but the photo is renamed now (I've to create a new one) Best Regards, Thorsten.

Martin: each general purpose NPN which can drive ca. 20-50 mA should be ok Tom: a tested PCB layout sounds good - I don't think that I will use it 1:1, but it will be helpful :) I just have noticed that the base of T1 is more or less floating when D2 is closed, therefore I've added a 10k pull-down resistor (R14) between D2/R3 and ground to avoid trouble Best Regards, Thorsten.

This schematic for the successor of the MBHP_JDM module is now available: http://www.ucapps.de/mbhp_burner.html I hope that this programmer works more reliable with all PCs - please report issues here Best Regards, Thorsten.

Hallo Johannes, Da Du nicht schreibst, was Deine Anforderungen nun genau sind, hier ein paar allgemeine Aussagen: bei der MB64 entsteht durch das Multiplexing eine Latenz von 8 mS pro Ausgang, wenn das fuer Deine Anwendung akzeptabel ist, dann spricht wenig dagegen. Irgendwann einmal (vielleicht im Sommer) werde ich die SHX8 Option auch in die MBCV einbauen, die auf Performance und nicht auf moeglichst viele Features getrimmt ist, und bei der sich die Latenz sicherlich unter 1 mS druecken laesst. Weniger als 1 mS sind nicht moeglich, da dies die Zeit ist, in der ein MIDI Event bspw. von einem PC uebertragen wird (Baudraten-Limitiert) Ansonsten muesstest Du noch angeben, ob sich die Parameter des Synths wirklich mit Spannungen steuern lassen, oder ob teilweise Widerstaende/Potis benoetigt werden - in diesem Fall wird es schwierig. Potis muessten durch einen digitalen Widerstand ersetzt werden, und den entspr. Treiber muesstest Du selbst programmieren. LCD und vier Taster reichen aus - so waere die Hardware auch Kompatibel zur MIDIbox CV Das SID Modul kann man nicht parallel zur MB64 betreiben, hierzu benoetigst Du ein separates Core Modul Gruss, Thorsten.

Hi, which CCs would you like to use for controlling the LEDs? Does this matter or not? If not, the appr. ASM code will look easy and can write it down quickly. If you need a configuration table, then I can only suggest to work through all examples. Best Regards, Thorsten.

a "must have"!!! :-) Best Regards, Thorsten.

Thanks - I've added the link to the MBHP_LCD page Best Regards, Thorsten.

Hi Tom, could it be that you forgot the 22k feedback resistors at IC6 (R6/R9/R12/R15). If this isn't the reason, check the audio signal before the output amplifier (e.g., at pin 8 and 14 of IC3) - just connect it directly with your soundcard/mixer input (don't forget the ground connection) Best Regards, Thorsten.

It seems that this flamewar was mainly caused by a big misunderstanding on KDs side. I haven't wrote arguments against bypass caps, I only tried to explain why I haven't taken this issue into account yet. However, the missing bypass caps will be added to the documentation next weekend (don't have that much time next week), KDs initial suggestion (stuffing 100nF SMDs close to the Vdd inputs of each IC) seems to be the best one - it especially doesn't require a layout change. 10/100 uF caps can also be easily added. All the other suggestions should normaly go into the Wiki, so that the infos can easily be enhanced in futuer. Any volunteer who creates a new page? Best Regards, Thorsten.

Are you checking my homepage periodically? ;-) Yes, I made a quick release after I ensured that the programmer runs also on my laptop. 74LS14 should be ok. Best Regards, Thorsten.

Hi, some experiences I made: the audio ground and the J2:Vs/Vd inputs should be directly connected to J2. I just have noticed that this change was not part of the http://www.ucapps.de/mbhp/mbhp_sid_c64_psu.pdf diagram yet (corrected) Best results can be achieved with the optimized circuit for the original C64 PSU - see also http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf As already mentioned another possible issue is the ground of your MIDI cable. Just unplug the cables and check if the buzz is still there. If this helps, remove the ground connection at J12 of the core module. This ground connection is according to the MIDI spec, but if the MIDI In of your MIDI interface is also connected to ground (which violates the spec), then you will have a ground loop Best Regards, Thorsten.

The windows based driver doesn't work under win98/se and win95, and sometimes not under win2k and win XP. For WinXP I've an alternative descriptor table which is 100% spec compliant, but which crashes win2k and winME Another drawback: it isn't multiclient capable. I'm not the only one who noticed this problems, the lack of support from Microsoft has been complained in the usb.org forum many times, and companies were forced to develop their own drivers (last example: Behringer - they offer a selfwritten driver in the meantime) Best Regards, Thorsten.

perfectly! Yes, please! Best Regards, Thorsten.

Hi Jidis, I refer to the MBHP_CORE schematic for the PIC18F452, yes, your assumptions are correct. the 99bar limit does only exist in the old firmware. It also cannot handle with the song position pointer sent by some MIDI programs Best Regards, Thorsten.

Hi William, the size of a 2x40? Sounds even more interesting! Could you send me one sample - then I will implement the driver Best Regards, Thorsten.

Hi Tobias, sounds interesting! Due to lack of drivers I never thought of this - from the uC side the implementation isn't that difficult. Microchip provides the source code for a TCP/IP stack (-> application note AN833) and the schematics for adapting a RTL8019 to the PIC18F452 (-> PICdem.net user guide). On the other hand: when I look at my ToDo list, I know that I won't have the time for such experiements till end of this year ;-) Since you've knowledge in writing drivers: are you interested in writing a reliable MIDI-USB driver for Windows? I can give you all the details (also a USB driver framework) and I would send you one prebuild MBHP_USB_PIC module for free! :) Best Regards, Thorsten.

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.