TK.

Hi, yes the order is correct, but of course it's not ok that the BankSticks are reformatted on every restart. Two questions for my own understanding: is your MIDIbox running with MIOS V1.8? (it provides the important brown-out reset fix) - and how does your MIDIbox behave if only one BankStick is connected? At how many BankSticks do you notice the problem? Best Regards, Thorsten.

Maybe choosing the GPL wasn't a clever idea - my main intention was, that I wanted to give back something to the GNU community as a tribute for the great GNU software I'm using for myself. Of course, it was very clear to me, that this also opened the possibility for everybody to run my software on commercial designs, but at the time I made the decision, it wasn't predictable that the project could ever get such a big acceptance, that even those salesmen become interested. However, you might find reasons to call me a naive guy, but I want to give you following considerations: At any time I can switch to another license like the Creative Commons (see http://creativecommons.org/licenses/by-nc-sa/2.5/) in order to protect my designs against people who are trying to use it in a direction which I don't like. Of course, this means that old software versions released under GPL are still free in the terms of this license. You can make variations and alterations, you could even develop something wonderful based on the old stuff. But such a step would also mean, that you will be prevented from keeping your "products" up-to-date to the main branch - all tries will either lead to a lot of effort at your side, or they will be illegal. Worst case for your venture: if I would switch to another hardware platform. An easy step for DIY people, a financial risk for yourself. Also your reputation won't be the best if the press or your feedback on EBay says "nice product, but sold against the will of the originator, and therefore not supported" I definietly don't want to say, that nobody else but me could realize such projects (far from it - experts should know, that there are flaws which are hard to change without a major redesign - I've learned from it, you not), but I think that I'm allowed to say, that all people who follow the "MIDIbox spirit" will have a big advantage: a great community which is giving a lot of inspirations, which helps to debug and improve the projects, which motivates to continue and to realize things which are just different from commercial stuff you can find on the market. Best Regards, Thorsten.

hm... don't remember - Smash? Best Regards, Thorsten.

Alright! I don't think that you need a new AIN board, just debug the current one. There are some bridges, are they all soldered properly? Note especially the flexible cable connections (yellow thin wires in the mbhp_ainx4.gif file) - You could also add some more solder to the pins of sockets and connectors, maybe this already helps! Best Regards, Thorsten.

Ich vermute, dass sich die SID Daten sogar in Echtzeit berechnen lassen - unter Echtzeit verstehe ich hier bis zum naechsten Timer Tick, der alle 20 mS stattfindet. Die 6502/6510 CPU selbst ist ja ziemlich lahm verglichen zum PIC (die meisten Befehle benoetigten mehrere Zyklen), und die Soundroutinen sind meistens so ausgelegt, dass sie innerhalb weniger "Rasterzeilen" (so hat man damals auf dem C64 Performance gemessen) abgearbeitet werden, so dass noch genuegend "Raster" fuer das eigentliche Spiel uebrigbleiben. Problematisch wird es lediglich bei den Digitunes, deren Sampleausgabe per NMI gesteuert ist. Die verlangen nach wesentlich mehr Performance... aber es gibt vergleichsweise nur wenige .sid Files (zu erkennen an dem _PSID), die mit 4bit Samples arbeiten. Im Grunde ist das nur etwas fuer Galway Fetischisten ;-) Nachdem mir das damals klar wurde, wollte ich Dir eigentlich nochmal eine Mail schreiben, habe es aber irgendwie verpennt. Nunja, so weisst Du nun ueber diesen Weg bescheid :) Gruss, Thorsten.

Hallo Michael, wenn sich der Wert nur nach unten einstellen laesst, hast Du evtl. die Encoder falsch angeschlossen. Das Pinning kann unterschiedlich sein, im Zweifelsfall (sprich: kein Datenblatt verfuegbar), probiere einfach alle drei Kombinationen aus. Die gewuenschten "Defaultwerte" kannst Du dann spaeter abspeichern, indem Du den "Snapshot Button" laenger als 2 Sekunden haelst - geht wie bei einem Autoradio ;-) Zum Code von Jeroen: frage ihn einfach direkt, ob er Dir seine Aenderung zuschicken kann. Soviel ich mitbekommen habe, hat er sie mittlerweile noch optimiert Gruss, Thorsten.

Ich habe 200k Zyklen angegeben (fuer 40 MHz, weil fuer mich das Rechnen mit 48 MHz noch zu ungewohnt ist ;-)) Ja, siddump ist schon ein feines Prograemmchen, und die Sourcen sind ebenfalls verfuegbar. Du musst also kein neues VB Programm aufsetzen, sondern kannst das Format einfach so rausschreiben, wie Du es brauchst (vielleicht laesst es sich ein wenig komprimieren). Oder optional den .c Code assembleroptimiert auf den PIC umsetzen, das sollte auch nicht zu schwierig sein. :) Gruss, Thorsten.

Good news on this topic: it turned out, that the USBD- and +5V line was swapped (in Matthias version, the USB socket is monted on a panel, five cables are wired to MBHP_USB module. This especially explains the strange effect, why windows temporary regognized an unknown USB device when the jumper was disconnected - swapping data with power lines isn't a good idea ;-) However, the cypress chip has survived this torture, the 100 nF cap is doing his job well, MIDI is up&running :) Best Regards, Thorsten.

Some explanations can be found here: http://www.midibox.org/forum/index.php?topic=5758.0, but also in the requests which have already been denied. Note especially the requirement for innovations. Saying "changes to MIOS" already points out, that you don't know how MIOS is working. Based on your descriptions, I don't expect much innovations from your side. I see your point, but I can tell you, that your intention is in contradiction with my goals. Please let me some days to think about an extension of the Rules to make the requirements more clear. Best Regards, Thorsten.

But if your sequencer doesn't send Note Off's, then the notes -> are <- hanging. Thats just the MIDI protocol. If this strange behaviour works with another synth (like the Virus), then it just means, that it works with an algorithm which drops long-hanging notes. MBFM has the same algorithm, but 1) this is not possible with the SID (e.g. due to the envelope bug), and 2) we are talking about a misbehaviour of your sequencer anyhow. In my oppinion there might be a configuration error or something like this in your MPC - you are saying that you do vary the length, and this *must* definitely mean, that once a Note On has been played, there must also be a Note Off after the specified length. Best Regards, Thorsten.

But I've explained my reasons very clearly several times in the forum, I'm just tired of explaining it again and again! The facts that you don't know me, that you don't know the community, that the community doesn't know you, is enough to reject your request. Please tell me a reason, why I should accept your request? Best Regards, Thorsten.

Wagst Du Dich also nun doch an den .sid Player? Ich habe Dir ja mal geschrieben, dass ich das nicht fuer moeglich halte, doch mittlerweile (bzw. nachdem ich mit "siddump" herumgespielt habe), habe ich gelernt, dass die meisten Tunes mit einem Update Cycle von 20 mS - oder auch 200k PIC Zyklen - auskommen. Da ist was drin, und nebenher klappt dann auch noch der Zugriff auf ein MMC Device. Egal ob 6n8 oder 2n2, die meisten Tunes werden nicht akkurat erklingen, da sie fuer den 6581 geschrieben wurden. Gruss, Thorsten.

Moment - does MBSID really crash (boot screen), or does it just skip short notes, or changes the pitch or something like that? Then check the envelope settings! ;-) Best Regards, Thorsten.

No, because if I would explain the reasons, the next unknown guy could take this as inspiration for a better try Best Regards, Thorsten.

Hallo Michael, ja, das funktioniert. Schau mal in das midibox64e.ini File rein (-> mk_syx Script), dort kann man die min- und maxwerte einstellen Gruss, Thorsten.

DENIED

Great work! :) Best Regards, Thorsten.

I cannot believe this - could this be related to your MIDI interface (I remember that there was a problem some time ago... I'm very sure that MIOS based applications don't have MIDI bandwidth problems, even back-to-back Note On/Off won't cause a problem. Just open the SysEx monitor of MIDI-Ox, write "90 30 7f 30 00 31 7f 31 00 32 7f 32 00" in order to send 3 Note On/Off events with maximum speed to MBSID. If the MIDI-Ox trace doesn't show any Note Off event, then it must be a general hardware or driver problem. Pwx: please upload the MIDImon application, which events are displayed? (Unfortunately I still haven't released a new version with prepared setup for 2x20 LCD yet, you need to set the DEFAULT_NUMBER_OF_LINES constant to 2, thereafter recompile the code with MPASM) Best Regards, Thorsten.

You don't know the good 4051 yet, therefore just swap two of them in the hope to see any differences The jitter monitor allows you to select the analog input which should be measured with two buttons. One button, which increments the number, another which decrements the number. See the main.asm file, on which digital inputs they are expected (you could also change the digital pins if required) Best Regards, Thorsten.

Thanks! Yes, I meant seconds (statement corrected for forum search function) I just had another idea: an even more secure way to upload new code is the following: 1) send a "bad" block and wait for error response 2a) if MIOS is uploaded (code starts at 0x0000), upload a dummy block which contains two "reset" instructions, located at 0x0000 2b) if the .hex file contains some code which is located in between 0x100-0xffff (0xffff because of PIC18F4620), upload a dummy block which contains one "reset", located at 0x3300 2c) in all other cases (no code between 0x0000-0xffff) just upload the data and ignore this algorithm 3) don't continue if this dummy block hasn't been uploaded correctly, because it should ensure, that no code is executed until the complete .hex file has been uploaded successfully 4) upload all blocks execept for the block which contains the "reset" instruction(s) 5) at the end, overwrite the block which contains the "reset" instruction(s) This algorithm ensures, that uncomplete code will never be executed, if something unexpected happened during the upload phase (e.g. low power, disconnected MIDI cables, MIDI interface driver crash or whatever) If required, I could try to implement this into MIOS Studio by myself (in this case, please send me the most recent source code) Best Regards, Thorsten.

Zum Poly/Legato Problem - ich kann mich daran erinnern, dass mir das auch mal passiert ist. Die Ursache war, dass ich den MIDI Stecker abgestoepselt hatte, waehrend noch ein paar Noten gehalten wurden. Dadurch war der Notestack belegt, und Legato funktionierte nicht mehr. Der Polymode sollte in diesem Fall nur noch Noten fuer nicht belegte Stack Eintraege spielen. Es handelt sich hierbei um ein generelles Problem mit Synthesizern, deshalb bieten manche einen "All Notes Off" CC, doch dieser ist bei der MBSID ja bereits fuer eine andere Funktion belegt. Eine weitere moeglichkeit waere, dass man saemtliche Noten, die in Frage kommen, anspielt und wieder loslaesst - ist aber auch nicht gerade bequem. Mir ist gerade eingefallen, dass ich den Stack auch einfach beim Umschalten des Patches loeschen koennte - werde ich wohl in die naechste Version einbauen, Zu den IDs: verschiedene IDs machen vor allem dann Sinn, wenn mehrere MIDIboxen an einem einzigen MIDI Out angeschlossen sind, denn nur so kann man gezielt Code in eine Box einladen. Doch selbst wenn jede Box ihren eigenen MIDI Port hat, macht es u.U Sinn. Bei mir kam es z.B mal vor, dass ich in der Eile die MIDIbox SID Firmware in meine MIDIbox FM eingeladen habe. Dadurch wurde der BankStick neu formatiert, dabei wurden die selbstgemachten FM Patches unwiederuflich ueberschrieben. Seitdem hat bei mir jede MIDIbox ihre eigene ID, um die Wahrscheinlichkeit fuer solch eine Panne zu minimieren. Gruss, Thorsten.

The "sid_random" application gets use of an external "real random" generator In C, the "software random generator" in SEQ_CORE_GenRandomNumber function would look similar to this: [code] unsigned char random_seed_l; unsigned char random_seed_h; void gen_random_number(void) { unsigned int tmp = random_seed_l * random_seed_h; random_seed_l = TMR0L + (unsigned char)(tmp & 0xff); random_seed_h = 0x69 + (unsigned char)(tmp >> 8); } [/code] Maybe with some additional XOR operations the random value distribution could be improved, but I'm not an expert on this topic... Best Regards, Thorsten. [/code]

Hi John, this is a bug, the variable should be declared as "unsigned int". Propably the measure will restart at 0 once 256 has been reached (at 140 BPM this takes 7.3 minutes, therefore I never noticed this ;-) Best Regards, Thorsten.

Hi John, yes. And you would have to overwork some parts of the j5_din source, since it uses macros, which are not compatible with gpasm (this reminds me, that I wanted to search for a solution for this compatibility problem) I guess, that the code in J5_DIN_Update wouldn't run much longer if written in C, because there isn't that much data handling. It should look similar to this: unsigned char j5_din_status, j5_din_status_changed; void j5_din_update(void) { unsigned char tmp = (PORTA & 0x0f) | ((PORTA & 0x20)>>1) | (PORTE << 5); j5_din_status_changed |= j5_din_status ^ tmp; j5_din_status = tmp; } [/code] Best Regards, Thorsten.

Hi Adam, reg. features, here is one I would like to see. :) Somebody had problems with the program upload directly after power-on. The core already sent out an upload request, but the voltage hasn't reached the required range before MIOS Studio started to upload the first block. For some reasons, something went wrong and the core crashed (ramp-up phase is always mysterious) The upload procedure could be made more stable - either o by adding a < 2s delay after an upload request, before the first block will be sent o or (this is what I would prefer) by sending a known "bad" block (e.g. a write block with 0 bytes content), and to wait for the expected error response. This would reset the timeout value, so that the core is ready for receiving again under relaxed conditions (MIOS Studio has 3 seconds to send the first "good" block) Best Regards, Thorsten. /Edit: mS replaced by s