TK.

Hi Ilmenator, the connections are correct (you can compare it against the pin definitions in app_lcd.inc), but I've no idea, why the core should send these strange MIDI messages, there is no MIOS_MIDI_TxBufferPut command within the app. A lot of "FF", "F8" and "FA" indicate, that there could be spikes of 30..100 uS on the Tx line It could be related to your power supply - is the backlight already in use? Try it without first Best Regards, Thorsten.

Thanks Thomas, I like the idea! I would like to test this by myself first, if it runs successfull on all my MIDIboxes (with all the different pin configurations), I will copy the package to midibox.org/users/th0mas Best Regards, Thorsten.

This was a problem with the file format used in MIOS V1.8, MPASM cannot handle "unix style" linefeeds. However, this version is expired anyhow. An update to MIOS V1.9 is strongly recommented, and the source code compiles fine Please read the README.txt of the mios_update_v1_9 package carefully before uploading a modified MIOS V1.9 !!! Following update path is required in your case: follow the instructions described for case B), thereafter do the modifications in the source code and upload the modified MIOS version via 1st level bootloader Best Regards, Thorsten.

Hi, this could also be realted to the Java MIDI bug, are you using the workaround I've described at this page? -> http://www.ucapps.de/jsynthlib.html Best Regards, Thorsten.

The errata list continues: - when LFO synch is enabled, there is a short delay/popping sound which can be really annoying especially on low frequencies (this bug exists since v1.7a) - problems when using the modwheel to control certain CCs, and the WT sequencer is running - various UI imperfections These issues will hopefully be solved during my easter break. Thanks to Wilba for testing the firmware so intensively :) Best Regards, Thorsten.

I'm not sure about a maximum delay for the CS line, but there shouldn't be an issue. There was a major problem with the MBHP_SID module realted to asynchronous accesses (details see http://www.midibox.org/forum/index.php?topic=5748.0), with the effect, that the gate will be retriggered randomly under certain circumstances. But you should hear a sound, regardless if the SID is clocked synchronously or asynchronously to the microcontroller (if your firmware works with asynch. accesses, you can solve this later...) No digital background noise: especially on 8580 chips its really quiet (< -70dB). But: have you ever used the SID without the transistor at audio out? Buchi wrote at his website, that he fried a SID by not using it - I took this into account from the beginning - all of my SIDs are still working after more than 3 years usage, and the MBSID is running each day (nice ambient lights ;-)) I don't think that there are other voltages which could be important. Maybe you should doublecheck the caps. Also for trivial errors (e.g. wrong signal polarity). This reminds me, that the noise at the audio out should be very high during reset - maybe this helps you to check, if anything is comming out of the SID. Best Regards, Thorsten.

You should really read the answers carefully, because there is an explicit hint to the MIDI troubleshooting guide - it has helped 100tes of people to debug the MIDI interface, and I'm sure that it will also help you! Best Regards, Thorsten.

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.