seppoman

Hi, here´s a nice little project (record and play MIDI files from a MMC/SD card): http://www.mikrocontroller.net/articles/Projekt_Mr.MIDI_-_Midi_Rekorder_mit_MMC/SD-Karte Description is in German and it uses an AVR controller, but perhaps it gives you some inspiration. Seppoman

Hi, sorry for the long delay - I was on vacation... But today I finished an updated version of the driver with small bugfixes, more documentation and a workaround for the missing "custom character" capability of the display. Here we go: http://www.seppoman.de/vfd/ Actually the "slow" response is not visible, it does only slightly affect the timing of the SID (my VFD introduces an additional latency/jitter of around 2 ms). You probably won´t notice this at all. All information about pinning is in the header of the source code. If you use the voltage regulator on the core you should probably power the VFD separately. It takes about 700 mA, you would need a large heatsink. If you´ve built the MBSID PSU optimized cirquit, you can use the normal 5V supply - the C64 PSU is rated 1.5 A at 5 V. As compensation for your long wait I´ve made a "starting point" version of the driver for you. It *could* work for the Noritake as is. Noritake doesn´t give out detailed data sheets, so there´s no exact description e.g. about cursor position count. here is the download: http://www.seppoman.de/vfd/app_lcd_noritake.zip Kind regards, Seppoman

C547B ist ein BC547B - die Gehäuse sind so klein, daß gern mal was von der Beschriftung weggelassen wird. Das B danach ist hier unwichtig - Transistoren gibt es meistens mit A,B,C dahinter. Die sind in den wesentlichen Eigenschaften identisch, nur halten sie verschieden hohe Spannungen etc. aus. Für Audiosignale reichts aber immer. Seppoman

that´s not generally true. The big VFD makers (Noritake and Futaba) do build Hitachi compatible displays, but they also have old-skool parralel/serial interface displays that are cheaper than the Hitachi ones, so I suppose there are still more VFDs in action and on sale that are not compatible. The one from Massimiliano is one of these. Seppoman

Hi, the driver should work with this display. Just a few commands have to be changed - these parallel interfaces dont have a really standardized command set. But there´s no magic about it. I´ll put a few more comments in the source code and publish it in the next few days. Of course if Thorsten wants to put the driver on the uCApps site that would be great - I just hesitated publishing it so far because I think it would be better if someone besides me manages to get the driver to work before doing that. A few people got the driver from me in the past, but I never got any comments about the success up to now... Seppoman P.S. modern VFDs are mostly dot matrix displays and there are even graphical ones

Hi Massimiliano, from the pin names I´d say this display is not Hitachi compatible. Looks a lot like the old-skool parallel interface my Futaba VFD has. For the Futaba, I have written a MIOS driver. It works quite well - the only problem with my vfd is that it is quite slow. On my MBSID, using the vfd introduces an additional latency of around 2-3 ms (only for the master). I can live with it on the SID, but e.g. using it for a MBFM might or might not be possible at all. To find out if your display has the same interface as mine, please state the exact type/manufacturer and, if you´ve found one, post a link to the data sheet. If you PM me your eMail adress, I´ll send my driver to you :) Seppoman

Solenoids ARE magnetic :) Just follow the link from moebius - this guy even wound his electric magnets himself. But ready-made parts are probably stronger and more reliable. Seppoman

It´s probably better to leave out the resistor because of the high impedance issue Thorsten pointed out. Impedance consists of "real" resistance and a complex reactance, so adding a resistor in series also makes the total impedance higher. The parallel capacitor acts as kind of a lowpass filter on its own, just don´t use too large values and it will smoothen the output without making things too slow. Just don´t expect the potentiometer to react linear and in the same value range, because you´ll have to have this AIN pin adjusted to the GP behaviour. Another solution to lock the value would be to build a simple voltage divider from two resistors to set the value e.g. to 2.5 V. Normally there shouldn´t be ultrasonic sounds in the air. Usual us. receivers work at 40 kHz and have a quite narrow band they can pick up. At 40 kHz, most microphones don´t pick up very much, and even a playback from a 96k sound card doesn´t contain 40 kHz signals. The generated 40kHz pulses from the transmitter are quite loud (can go up to 120dB), so the receiver sensitivity doesn´t need to be very high if you only want to measure short distances. Scaling just means the routine gets in some values and calculates or looks up some corresponding other value. If you want full 0..127 output from the GP, this is neccessary anyway (because of the GP not going down to 0V). So it doesn´t make much difference if you convert the 255..40 value range (after the first two steps) to 0..127 with or without linearizing the curve. It´s just another conversion table. The conversion has to be done in the application - MIOS is just used to get the raw 10bit A/D values. Although the GPs were not suitable for the sofa, I´m still interested to make use of them in a normal MB configuration, so I´ll probably try to write a "driver" for them. So if you get stuck and it´s not too urgent for you, just wait :) It could take several weeks although. Seppoman

Hi Stef, No, it´s not logic... You DON´T programm the OPL3 itself. The OPL3 has no own intelligence, it is just USED BY the core module. Saying that you have to get off a opl3 from a soundblaster means you have to get a chip that is not mounted on a SB (anymore). What Smash probably told you means he doesn´t sell OPL3 chips, so you have to get one from somewhere else (e.g. from an old SB card). Perhaps if you compare the elements of a normal computer to a MidiBox, the basic concept is easier to understand: Computer MidiBox Motherboard = Core Module Sound Card = OPL Module Windows XP = MIOS Cubase = MidiBox FM Software So the whole MidiBox system is like a new "computer" system only used to make the OPL put out sounds. Build the Core and OPL module, "install" MIOS and the FM software and just use it. You don´t need to program (write new software) yourself, the software is already there.You just need to "install" the software onto the Core module (the PIC controller). "Installing" software on a PIC is called "Programming the PIC", but this doesn´t mean writing e.g. C or Assembly code yourself! Saying "I want to program the OPL3" is like saying "I want to install software on a Soundblaster". You just install software on the computer (not on the Soundblaster). Seppoman P.S. Please don´t take this personal, but I´m not sure if there´s a language problem keeping you from understanding the concept - so perhaps it would be a good idea to also ask your questions in the french section of the forum.

"Fast enough" depends on what you want to control with it - not on the power of your computer ;) All Sharp sensors have around 50 ms latency, just look at the timing diagram. I also used the short distance version. Ultrasonic is not necessarily better. I searched for different ready-made solutions quite a long time. The problem is that all affordable ultrasonic range finders are targeted at the DIY robotics market, so they want to achive a maximum sensor range. Usual types have about 4-5 m max. distance, so with the speed of sound you can easily calculate they´ll have to wait quite a long time whether there´s a far away echo coming. Normally they also do multiple measurements to get better readings before putting out a value. In (hobby) robotics, latency is not really important. Typical robots don´t move fast enough that it would make a difference if they detect an obstacle 50 ms earlier or later. There are ultrasonic (or laser-based) distance sensors with good timing in the industry automation market, but I really didn´t want to sell my car to buy six of them for the sofa ;) But back to your problem: getting good values from the GP has different problems - the output curve is (kind of) negative logarithmic, starts at around 3V and goes only down to around 0.4V. A major problem is that in the second half of measurable distance, the curve is so flat that you´d need a really good analog and A/D cirquit design to still get a good resolution. I took the pure software approach to get usable values: 1. Look at the data sheet figure - a minimum distance of about 4 cm gives 2.5V output. The sensor can only measure down to 3 cm, so I sacrificed this one cm to get an easy solution. The PIC does 10 bit conversion. 2.5V is half of the maximum value (5V), so I just stripped the highest bit - a 9-bit value remains. 2. Especially with the jitter problems of the GP, the lowest bit is only meaningless crap anyway, so just right-shift the 9-bit value one bit. Now we´ve got an 8 bit value that still contains (most of) the relevant information, but is way easier to deal with. 3. Now comes the tricky part. You need to linearize this distance information. There is some division involved, but divisions consume a lot of processor time on a microcontroller, so the best way is to calculate the result for all possible values and use a lookup table. If the precision has to be really good, you can afterwards setup a measuring experiment, e.g. a ruler lying on the floor in front of a wall. So you can move the GP above the ruler and compare the output value with the real distance and make some corrections to your table. The programming part was not too hard in my case because the GPs were the only analog controllers. So you can just jump in at the point where MB64 acquires the A/D values and change everything to your needs. If you want to have both GPs and "normal" potentiometers/faders in one box, it gets a bit complicated... Seppoman

While the imendance thing might add a bit to your problem, the main issue is probably about the supply voltages: I tried the GP sensors for a new version of my "Midibox Sofa", connected the sensors directly to J5. I noticed that with one sensor this works quite well, but the more sensors were connected the more unstable the readings get. So I searched for the reason. The data sheet from your link is a compact version, on the Sharp website there´s also a more extensive one that suggests putting an electrolytic cap of around 1000uF directly across the supply pins of the sensor. The GP apparently draws supply current in short bursts every time it sends out a IR light burst. The "average current" is around 50 mA, that means these bursts probably go up much further. They can either stray in on the data lines of the AIN->Core connections or make the supply voltage of the whole system unstable. The capacitor is kind of a "local"power supply that can provide the current for the short bursts. Higher frequency interference on the power line can be suppressed if you add a normal bypass cap to the electrolytic one, e.g. 100nF or 1uF ceramic. If the readings are still not stable enough, there are also notes on the net that suggest adding another capacitor that acts as a low pass filter: If you put a ceramic cap between the value output and ground that smoothens out very fast changes. Remember a capacitor is non-conductive for DC voltage and gets more conductive the highter the frequency gets. The lower the cap value, the higher the suppressed frequency gets. So you can experiment with different values there to find a value that makes the output stable enough for your application without making values change too slow. Hope this helps :) Seppoman BTW: I found the GP sensor is a bit slow for musical applications - the measurement takes about 50ms, and that is in fact a really high latency if you e.g. control a pitch value with it. So at the moment I´m developing an ultrasonic range finder solution (AVR based). For short distances one measurement takes no longer than 1-2 ms, so even if you do 5 measurements and do a median filtering over them to smoothen out the values, the latency is still 5 times better than with the Sharp sensors.

Hi Julian, I built a similar PSU and also had this problem. The transformer was getting hot and was also vibrating a bit. My transformer is from Conrad and they have only "2x15 V" transformers, that means it doesn´t have a real center tap but two parallel windings each giving 15 V. The problem disappeared when I changed the wiring to the transformer. You have to choose the right two of the four secondary pins to connect together to the virtual Ground. I made myself up an explanation - no idea if this is correct: As the windings lie parallel for the whole distance, the electrons have to be "pushed" through the transformer from -15V to +15V in the same direction to not work against each other, so it is essential that you connect the end of one winding to the START of the other one. Seppoman

That mustn´t happen regardless of any grounding issues. Ground loops don´t have enough current to cause this, so there must be an error in your power supply cirquit that causes a short from audio ground to the wall wart. did you build the cirquit from http://www.ucapps.de/mbhp/mbhp_core_power_fix.pdf? BTW do you really use a 9V AC supply??? Even if you have an 8580 (and the photo looks more like 6581) you need more voltage. About ground loops: I had a hum problem because I use the housing as a cooler, so I found out I had 3 different ground connections to the case that were: 1. the back of the 7809 2. Also the outside of the Alps encoders are connected with ground, so when they´re mounted on a metal front panel, there´s a connection. 3. the outer rim of the DC connector was in contact with one of the power leads. My fix was to use a rubber "cable lead-thru" (don´t know the english word) to isolate the DC connector from the housing. But I think you should first check the power cirquit again. Seppoman

Hallo Michael, erstmal wegen MIDI-Lautstärke ändern: das wäre theoretisch machbar, dafür mußt Du aber Einiges programmieren, speziell wenn Du noch ein sinnvolles Bedienkonzept haben willst, also ein ziemlich fortgeschrittenes Projekt. Basis wäre entweder http://www.ucapps.de/midifilter.html (Assembler) oder das MIOS C-Interface. Ansonsten hat es schon seine Gründe, warum Midi-Merger selten mehr als zwei Eingänge haben. Die Übertragungsgeschwindigkeit von MIDI ist für heutige Verhältnisse ziemlich lahm, und erhöht sich natürlich durch den Merger nicht. D.h. selbst bei einem 2-fach-Merger kann es schon zu Datenverlusten kommen, wenn beide Geräte gleichzeitig größere Mengen an Midi-Events senden. Pro Zeiteinheit kann der gemergete Ausgang nur halb so viel Daten transportieren als zwei Eingänge empfangen kommen. Es kann also zu einem Stau oder besser gesagt zu einer Massenkarambolage kommen. Je mehr Eingänge auf einen Ausgang kommen, desto größer (und wahrscheinlicher) wird das Problem. Um mehrere Keyboards mit mehreren Expandern zu verbinden, gibt es relativ günstige Geräte zu kaufen. Ich habe z.B. einen Kawai MAV-8, das ist eine Midi-Patchbay mit 4 Ein- und 8 Ausgängen. Gibt es immer wieder mal auf eBay für um die 50 Euro zu kaufen. Dieses Gerät hat 8 Schiebeschalter, mit denen man für jeden der 8 Ausgänge einen der 4 Eingänge als Quelle wählen kann. Man kann also mit einem Keyboard mehrere Expander gleichzeitig ansteuern, nur mehrere Keyboards auf ein Ziel geht nicht, dafür müßte man einen Midi-Merger haben. Allerdings brauche ich zumindest diese Möglichkeit nie. Wenn man sowieso mehrere Keyboards hat: Ich habe nur zwei Hände, also spielt man eben einen Sound/einen Expander mit dem einen Keyboard, und den anderen mit dem anderen Keyboard. Die Patchbay hat mir bisher alle für mich sinnvollen/notwendigen Verbindungen ermöglicht. Viele Grüße, Seppoman

Hi, I own both an old Ultrasound and an Ultrasound PnP card. To be honest, I don´t see too much sense in hacking old soundcard chipsets like SoundCanvas or Yamaha XG series - If you want the sound of these boring preset ROMplers, there´s a load of different GM or XG compatible modules from Roland and Yamaha with similar soundset and ready-to-use user interface. The GUS (Gravis UltraSound) on the other hand had it´s main fascination not in emulating SCC / GM. The GF1 chip on the GUS can make use of up to 1 MB of sample RAM and playback up to 32 voices without CPU consuming software mixing. In the early 90ies it was THE card in the Demo scene and widely used and supported by all popular programs of the MOD/S3M/XM(...) tracker scene. These programs were the first affordable way to produce your own music on old 386/486 machines without using expensive MIDI hardware samplers, so this scene was quite big back then. On these slow machines it was possible to do MOD tracking also with Soundblaster cards, but the sound quality was really terrible as the processing power was a bit short for quality software mixing of the voices. The AWE32 was mostly unsupported by the programs (and also more than twice the price) so everybody being serious about tracking bought a GUS. The normal GUS had 16 Bit DA converters but only 8 Bit AD converters in the "normal sound card department" of the card. So a lot of early demo/MOD music uses 8 Bit samples. The GUS MAX corrects this flaw and features 16 Bit conversion both ways. BTW, there was also a low-cost version called GUS ACE that had no AD converters at all and was meant as an add-on for people already owning another sound card. The GUS PnP was the next generation card from Gravis. It had better quality converters and a new chipset that could emulate the GF1 but also access up to 8 MB in native mode. When the PnP was launched, the time of the DOS-based trackers was nearly at an end. Windows 95 and the Pentium era brought more processing power and new companies produced affordable normal sound cards with better specs than the still crappy SoundBlasters. Furthermore Gravis never managed to release a bug free Win95 driver for the card. So the success was limited and Gravis decided to go out of the sound card business. About the Turtle Beach Maui: I owned a TB Tropez card which is quite similar to the Maui. The Tropez featured up to 32 MB of RAM and high class converters. Back then it was about 300 Euros, so it was quite similar to the AWE32 but more expensive and more professional sounding. You could use the RAM only under Windows and sadly, the patch and sample edit software was quite crappy. If somebody´s interested in developing a simple DIY sampler with fat, a bit LoFi sound, the GF1 chip of the old GUS might be of interest. The chip comes in a non-SMD package - don´t know if you can get an extensive data sheet. The PnP and Maui (and also the AWE32) are IMHO too HiFi for a new design - you can buy e.g. an E-MU ESI 32 sampler that has 32 voices, variuos good-sounding filter modes, SCSI interface etc. for under 200 Euros these days, so there´s no sense in new developments. This information is brought to you by Dr. Greyhairs Seppoman who suddenly feels a bit old talking about long-gone times ;)

Hi, everything´s on uCapps. As it is to be expected, connections to a DIN board are explained on http://www.ucapps.de/mbhp_din.html - just look under "Additional information". Even if you have an encoder type not mentioned on this page, there are only 3 pins coming from an encoder and you can swap them as you like until it works as intended. You can´t damage anything. Merry Christmas, Seppoman

Hi, a short notice for the folks who got the Der Brat firmware from me: Now I´ve finally ported the necessary modifications for a "Der Brat"-Style MBSID to the 1.7303 beta10 firmware. Also the remaining small bug in my modifications was sorted out and the comments in the code are now in English. For the new menu functions I´ve made two-button shortcuts like Thorsten used for the note/sequence Play function. This Play function is activated by holding "Return" and pressing "O". The 303 menu is activated by holding "Return" and pressing "W". So anybody who wants the firmware just drop me a note via PM. Seppoman

Hi Thorsten, thanks for your response :) Today I found the time to try this out: Inserting your code doesn´t help with the 512s yet. The box doesn´t recognize or format the second bank and I can´t save to it. Your other trick did work, all EEPROMs good as new now :) Kind regards, Seppoman

Hi, I´m in the process of (finally) updating my "Der Brat 1000" to 1.7303b10 and want to put more memory into the box. Now I have the following problems: 1. when I put a 24LC512 EEPROM in the socket, there´s still only one bank. I was under the impression that MIOS can make use of double-size EEPROMS? 2. I have two 24LC256 chips that were formatted on the MB FM. When I put one into the MBSID, the box starts formatting it until patch 13 is reached, then hangs, resets and starts the formatting again. Is there a way to get these chips working with the MBSID again? Thanks, Seppoman

This is what I meant by "confusion"... ;)

did you see the "New Device ID" message on the display yet? because if your cores still show "Ready", they don´t have any (also not the change_id) application running. So are you really sure the cores have the correct IDs set? If an upload is ignored, this mostly means the device ids still don´t match. About the SID app: If you didn´t do any modifications to the software, you don´t need to compile it yourself. The existing setup files take care about everything that is needed for slaves. Just choose 6581 or 8580 and the correct slave# files.

Hi Leelinn, I just answered in the "Parts Questions" section of the forum. Now I saw you posted the same questions here. Please try not to do double posts as it can bring confusion to the forum. Seppoman

don´t know this part - if it´s another diode rectifier, probably yes. Yes, you can always use higher voltage caps - it´s just the voltage they can endure without going bad or blowing up :) see above The ground plane is e.g. the big copper area surrounding the boards. If you have a multimeter, take e.g. the negative leg of the big caps or the middle one of the 7805/09 and check which traces have direct connection to there. Just put the caps one leg to the IC pin specified and the other one to a nearby ground trace. But you could also leave these out - I never put these caps onto my boards and never encountered any problem. I´d say they´re ok. What connections exactly? Just build the boards using the .gif files - the only connections not taken into consideration on the boards are the ones with the bypass caps (100n). All other ground connections are there on the boards. Yes. I think the main reason Thorsten chose Styroflex is they have more precise values. Before he changed this they were normal ceramic caps. I´ve tried both and didn´t notice a really big difference between Styroflex and ceramic (they´re responsible for the SID filter). Just ignore it. Before MIOS 1.7 the extra connection under the board from J4 was to pin 22 instead of 28, so this was to solder the wire onto. Which file do you mean? Which resistor do you mean? Which programmer do you use? Seppoman

Hi Tarzan, I´m not sure if I understood correctly, but do you try to change the ID by just using hex2syx -device_id on the change_id main file? If yes, this is the problem. by the device_id option you only specify the target of the upload, so if the core has x00 ID and you send a file with a slave id, it will ignore the upload. This is how it works: the change_id application is uploaded on application level, that means first you have to have MIOS on all 4 cores. Then the best way to make sure the upload reaches the correct slave is to connect one slave core after the other directly to midi - not over the link cable. Put an optocoupler on the slave core and use the normal midi connector (J13). Connect the LCD to the respective core. Make sure MIOS is running. Then you have to compile 3 different versions of the change_id app. Change the device ID in the source code of main.asm and compile it using MPLAB. then use hex2syx WITHOUT specifying a -device_id. So you have compiled an application to change e.g. a core with ID 00 to ID 01. Upload this file while MIOS is running (after the READY. shows in the display). The core should do a reset (if not, power down and up one time) and show a message "New Device ID: 0000000001". Now that the ID is set, you can upload the SID application again, this time using the "setup_8580_slave1.syx" file. Do this for all three slaves and then connect everything in the normal way again. Hope this helps :) Seppoman

Hi, teste doch erstmal den SID auf einer der drei funktionierenden Platinen. Wenn er auf ner anderen geht, nimm erstmal die anderen beiden chips auf der fraglichen Platine auch noch aus dem Sockel und miß die Spannungen wie auf der "SID-Modul-Seite" unten neben den Fotos beschrieben. Falls die OK sind, muß man rausfinden obs an der Datenverbindung oder am Audioausgang liegt. Seppoman