TK.

P.S.: this won't fix the initial problem btw - you haven't mentioned what you mean with "malfunction" yet, but trying to upload MIOS again was propably not the right thing. If there is a problem with your MIDI interface, or the power supply, you should try solve this first Please also answer the questions above, each detail is important, otherwise nobody can really help you, just only repeat what has been repeated several times in this troubleshooting section. Best Regards, Thorsten.

Does it get feedback, when you are uploading the application with the 1st level bootloader (within 2 seconds after power-on)? In this case, upload MIOS again, ensure that all checksums are displayed (no upload request during upload), and post the content of the log window here Best Regards, Thorsten.

You could use the 8 pins of J5 as digital inputs (see j5_din example), and the 8 data pins of the LCD port as digital outputs Best Regards, Thorsten.

this is an imperfection in MIOS Studio, which I just have fixed last weekend :) (Adam will release a new version soon) The scenario can happen on a bad MIDI connection. You are right, the checksum should be doublechecked. Best Regards, Thorsten.

Maybe your power supply is not strong enough, so that the PIC reboots once the voltage drops below 4.5V? Or one of your pots is not connected correctly, and causes a short circuit. What happened exactly when you saw the "malfunctions"? Which tool are you using to upload the application - hopefully MIOS Studio? Best Regards, Thorsten.

Hi Tom, I haven't selected this chip, since the FIFOs are much too small - 2*8 byte are not enough for heavy MIDI routing compared to 2*96 bytes provided by a MBHP_IIC_MIDI interface. Also the price is much higher than a PIC16F88. A single MAX3100 at NewArk: $6.40 A single PIC16F88 at NewArk: $2.66 So - there was no question which chip is the better solution. Although the firmware development wasn't that easy than expected (there are many corner cases in IIC which had to be taken into account) - but at the end it works stable :) SpeakJet: now where you mention this, I think it's time that I should also do some experiments with this chip, it's a great companion for MBSID/MBFM I just have ordered two from the donations I got in the last weeks (thank to all you guys! :) Best Regards, Thorsten.

It would be interesting if this works - it should! Best Regards, Thorsten.

Yes, there is a workaround which is already working very nice - don't use the internal EUSART for MIDI Out, but external USARTs instead :) Preview: The firmware is currently only available for "known people", but I will release it sooner or later to the public. Best Regards, Thorsten.

Hi Karl, your initialisation sequence is correct. The voltage at the Audio out depends on the SID revision, on my 6581 from CW25/84 it's ca. 5.18 on maximum volume, and 5.25 on minimum volume. Btw.: this is a good check to ensure that register accesses are working - just set the volume to different values between 0x0f and 0x00 and check if the DC offset changes. I'm not sure if a ground loop could be a problem, normaly they only add AC offset Best Regards, Thorsten.

The Volume and Brightness messages are generated from the analog inputs for the second AIN module (which you unusued in your case) Really all remaining pins? Please compare it with http://www.ucapps.de/mbhp/auaimbctg.pdf Best Regards, Thorsten.

It could be, that the FGND pin has to be connected in order to get the internal DC converter running. I would try a direct connection between FGND and Vs (both are ground in your case). If this doesn't help, just start with two 9V batteries in order to get -18V. A DC converter chip can be ordered later... Do you still own the other LCDs? Something which is not explicitely mentioned in my schematic are the connections to chip select and reset line. Even if the negative voltage is available, the display has to be initialized before you will see anything on the screen. Reset must be deactivated (for Wintek: RES=0), and the bus must be selected (Wintek: CE=1). (I don't know good tutorials on the web) Best Regards, Thorsten.

Hi Ilmenator, in general you can use the IIC functions in order to access the display, it's very simple - but - I just read in the spec of the LCD you mentioned, that the interface should either be accessed with 100 kHz (MIOS uses 400 kHz), or with 400 kHz and 100 uS delay between the commands --- this is extremely slow for a graphical display - I wouldn't buy it, and would try hard to get the other display running instead (I will give you an answer to the other posting afterwards). Best Regards, Thorsten.

After a lot of beta testing (which was hopefully enough) I just have released MIOS V1.9 See the ChangeLog for details: http://www.ucapps.de/mios_changelog.html The biggest benefit of the changes: more memory free for applications -> more features! :-) An update to the new MIOS and Bootloader version is strongly recommented, since newer releases of MIDIbox SID/SEQ/FM/64/64E won't be compatible to MIOS V1.8 and lower!!! They will get use of the upper 1k block, which was allocated by bootloader V1.1b before In addition, following programs have been updated: skeleton_v1_9: contains new copyright message sdcc_skeleton_v1_9: contains new copyright message, function declaration for MIOS_IIC_SendByte changed change_id_v1_9: allows to change the MBHP_IIC_MIDI ID in the ID header midi_router_v1_0: the MIDI router project, which is unfortunately not documented yet, but which runs stable since weeks. :) It could also be interesting as example, how to combine C and assembly code Best Regards, Thorsten.

As mentioned somewhere else, it makes sense to start with C, and to optimize small routines in assembler later. If arrays are used heavily, it isn't said that this will slow down the overall performance significantly, because this depends on how often the appr. routines are called. You will be able to test this once the C routines are working, and a translation (of time criticial parts) to ASM will be easier afterwards, because you should already have a working algorithm at this point. So: don't use the time to search in the forum for statements which are not 100% matching with your project, but just start programming and make your own experiences! ;-) Best Regards, Thorsten.

Some days ago I wrote in the german part of this forum, that it would be great if the community would develop a third AOUT module as alternative solution to AOUT and AOUT_LC (http://www.midibox.org/forum/index.php?topic=6333.msg39275#msg39275). The MAX525 was selected after some discussions in the forum because of the best price/quality ratio. The focus was on the number of channels, interface type, latency, cascadability and last not least linearity (important for controlling OSC frequencies, not so important for controlling volume or cut off...) It really depends on the usecase. If the cut off frequency of a filter should be controlled over a large range, 8bit resolution would lead to some unwanted steppiness. If the range would be reduced (e.g. by using a gain and offset pot), you are maybe happy with 8bit, but the reduced range means less flexibility. It should also be considered, that once the resonance is set to a point, where the filter tends to self oscillation, you definietly want to finetune, and this just requires a high resolution. 12bit for CV is enough in my eyes, higher resolutions are difficult to handle without special layout and PSU measures. With v_max = 5V, each step adds only 1.2 mV to the output voltage, now add the background noise of your PSU and the digital circurity, and you see that it doesn't make much sense to increase the resolution (this statement is not true for audio signals). Another point which should be considered is the use of S&H in order to multiplex DAC outputs. You could use a cheap single channel DAC and a cheap S&H chip in order to get 8 channels. S&H requires special software measures (timer driven DAC output), which loads the CPU more than a multichannel DAC, but for applications like MBCV or MB64, where the CPU is mostly idle, S&H is a good alternative. Sidenote: if MBCV currently doesn't support S&H, this doesn't mean, that it's difficult to implement this! A last general tip when searching for an alternative DAC: search for samples at different vendor webpages (Maxim is not the only one), prefer chips, which are easily available, check with www.findchips.com, if the IC is available in low quantities. Best Regards, Thorsten.

This just remembers me on a tool I used years ago to change the boot screen of windows 95. It was a cheap possibility to impress friends. Don't know, if Bill Gates hates me for that ;-) Best Regards, Thorsten.

Yes - a real "skip step" feature which allows to overjump any step could be built into MBSEQ V3 (hardware compatible version with new firmware), where I'm redefining the data structures and therefore will be free to consider such features. Currently you can set the track length, so it's at least possible to skip the last steps of a track Best Regards, Thorsten.

Hi George, sorry, with the "no benefit at all" I didn't want to say, that I don't respect your efforts! It's a nice project, and it's great to see how it develops. I've also a Spartan III board laying around here and thought about a synth project, but in my eyes (again: this is not to disrate your project!) a SID replacement is a nice start, but with FPGA you can do even more powerful things, which are hard to emulate with DSPs or other CPUs. The fun begins, once you have a lot of parallel processes for oscillators, modulators and digital filters. Analog filters sound great, but they are not so flexible... :-/ There is a high potential in your project, if you would go beyond of the SID feature set. E.g., how about FM? :) It would be interesting for me, what is the current utilization? Is it possible to instanciate multiple SID cores, or is spartan III too small for this? I think that - lets say - 8 SID instances, slightly detuned, 4 assigned to the left, 4 to the right audio channel, would give a really fat unisono sound :) Best Regards, Thorsten.

Have fun! ;-) I just have added some programming specifics to the webpage in the hope that they don't confuse newbies that much. This module is just a nice toy and has a lot of potential for future enhancements :) Best Regards, Thorsten.

A FPGA cannot beat the real SID, because the original chip contains some analog circurity which cannot be emulated with digital logic. The FPGA project can be compared with software emulators like the SIDPLAY library - no benefit at all, just a nice alternative solution... Best Regards, Thorsten.

It's described here: http://www.ucapps.de/midibox_seq_options.html Best Regards, Thorsten.

Hi, the firmware controls this particular LED in the following way: (1) LFO6->Filter off: J5:D0=0V and J6:D1=0V (LED off because both pins are at the same level) (2) LFO6->Filter on: J5:D0=5V and J6:D1=0V (LED on because of right direction -> anode connected to J5:D0) But: all LED lines are time multiplexed. J6:D1 is only 0V for a short moment, in 6/7 of the multiplex cycle J6:D1 is held to 5V This means: so long the LED line is not selected, we have: (3) LFO6->Filter off: J5:D0=0V and J6:D1=5V (LED off because of wrong polarity) (4) LFO6->Filter on: J5:D0=5V and J6:D1=5V (LED off because of same level at both pins) If you connect the LED in the wrong direction (cathode connected to J5:D0), it will light in 6/7 of the update period because of case (3). You can doublecheck this by turning on the modulation for LFO6->Filter in the MOD menu - the LED should turn off. If you've connected the LED in the right direction, it should turn on. Hope that this answers your question... Best Regards, Thorsten.

no further update - the firmware is running stable, but there is no more documentation available yet than this forum article and this tutorial http://www.ucapps.de/howto_sid_wavetables_1.html Best Regards, Thorsten.

This is a really beautiful synth/sequencer combination made by Alex :) He wrote: check also his website for more details: http://enmusic.by.ru/

The files (>700k, very good picture quality) can now be downloaded here: http://www.midibox.org/users/freaksomnia/PICT0002.JPG http://www.midibox.org/users/freaksomnia/PICT0003.JPG http://www.midibox.org/users/freaksomnia/PICT0005.JPG http://www.midibox.org/users/freaksomnia/PICT0010.JPG Here some smaller versions with remarks: 1: the core module has some bad solderings (loose connections), which could lead to failures. There are also missing solderings (e.g. 33pF cap below crystal). I would propose to solder each pad again, the soldering guide in the Wiki gives some useful tips 2: the legs of the caps should be cutted, otherwise they can cause a short circuit which can damage the PIC! 3: this seems to be a bad ground connection directly at the 78xx - it can lead to the wrong voltage. Here the same: just solder the pads again, it will help And also cut the long cap legs, the danger for shorts is too high Best Regards, Thorsten. P.S.: I don't want to bother you, but do you allow me to bring the two pictures into the wiki in order to explain other newbies, for what they have to take care about?