TK.

I've contacted Mike Best Regards, Thorsten.

No idea, but it makes always sense to use the most current version of MIOS. It just takes 5 seconds to update the OS, so why not trying? ;-) I'm not sure, but so far as I know MBSID V1.5b uses some hooks which were not available in MIOS V1.3 Best Regards, Thorsten.

Hi, you can always add your modifications, the top-layer of the display output routines can mostly be found in cs_m_display.inc Check the current MB64 application where Duggle has added a new display mode for 20x4 displays - thats the way how you can do it also for your stuff Best Regards, Thorsten.

Ja, in allen drei Beispielen wurde ein Delay eingesetzt, und im dritten noch ein wenig Chorus hinzugefuegt. Bei einem analogen Delay sehe ich keinen wirklichen Vorteil, die Edel-Delays arbeiten ausschliesslich auf digitaler Basis. Die anderen Schaltungen sind da schon etwas interessanter (danke fuer den Link!). Gruss, Thorsten.

First you should check if this is a software configuration or a hardware problem. Just upload the MIDIO128 application, or MB64E (there is a special preconfigured binary for MBSID hardware called "setup_midibox_sid.syx"). Do they send any random MIDI events? Best Regards, Thorsten.

sure - just don't forget the 10k pull-up R9 if no DIN module is connected to the core. By default, the first 64 LEDs are assigned to Note 0x30-0x6f, the remaining 64 LEDs to CC 0x10-0x4f of the first MIDI channel, but you can change the MIDI events via SysEx by using the mk_midio128_syx script (or by changing the midio_presets.inc file) as often like you want. Best Regards, Thorsten.

thanks - I've changed the orderlist. Best Regards, Thorsten.

No, especially changing the volume register will produce a "plop" sound (it changes the DC offset). This effect has been used for playing samples in the C64 days... ;-) Best Regards, Thorsten.

Hi Jouni, by playing some simple SID files (like Ultima III ;-)) I finally found out the correct order - see sidplay.inc of the new SIDplayer application http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=mios_toy;action=display;num=1071925936 Thanks for your help! :) Best Regards, Thorsten.

SIDplayer V1 is now available in the MIOS download section: http://www.ucapps.de/mios_download.html ; This MIOS applications interprets the SIDstation "ASID" protocol and ; forwards the requested register changes to a MBHP_SID module ; ; compatible with the ASID player and SIDPLAY/Windows ; -> http://www.d.kth.se/~d93-alo/c64/spw/sidplayw.html ; -> http://www.sidstation.com/sidsupport.php ; ; based on http://sammal.ton.tut.fi/~paulus/asid_protocol.txt ; by Jouni Paulus (jobe(a)iki.fi) ; ; The biggest collection of SID files can be found here: ; http://www.hvsc.c64.org/ [/code] have fun! :) Best Regards, Thorsten.

There is no way to avoid this sound Best Regards, Thorsten.

yes/yes you can change the SID device ID via MIDI as much times as you want. It will be saved in EEPROM and therefore won't be deleted after power-off. Best Regards, Thorsten.

buy & sell

For those who like flash animations (wait at least for 1 minute ;-)) http://www.millan.net/funp/100/deerz2.swf

Sure, you can do this, just 5 lines of code - but the already available implementation which shows an arrow on the screen is much more useful in my eyes - with the arrow you know in which direction the pot has to be turned to reach the initial value. Best Regards, Thorsten.

Hi Domas, sure, it will work. You could connect it to the upcoming companion chip for best performance (search for the posting somewhere under Construction->Concepts), otherwise only uncritical applications like MB64 or MB64E can be used with it. Note that a MIDIbox LC requires a 240x64 display so that all characters can be displayed. There are also some really cheap T6963C GLCDs with this resolution available. Best Regards, Thorsten.

Some bad news: the counter values are jittering (independent from the frequency ), jitter stops with 4-bit resolution, so that w/o a sophisticated interpolation algorithm the d-beam implementation is useless for a musical application. The programming of such an algorithm isn't trivial and consumes a lot of time & effort. I also tried another IR-sensor and the output signal is completely different (it sends pulses with a constant frequency of 1kHz - very strange). This means that unfortunately not all types of IR sensors with integrated amplifier can be re-used, different ones have to be tried. This will be very difficult for peoeple who don't own a scope. So in fact this approach won't really help, I cannot give you any spec for the IR sensor (I only know that it's from a TV which I've canibalized ca. 20 years ago ;-)) and I've currently no motivation to search for a perfect algorithm for my own sensor (the advantage of a D-Beam isn't really so big, it would be a nice feature but nothing else...) So - thats all from my side ;-) Best Regards, Thorsten.

In theory you could patch this in the .hex file, but it's more safety when you just follow the instructions given here http://www.ucapps.de/midibox_sid_csB.html Means: just change the IDs via MIDI Best Regards, Thorsten.

Hi Jouni, thanks for this great input! :) I just wrote the appr. SysEx parser, but it seems that your re-engineered spec is not complete. The order of <data> is not clearly defined. Example: at the beginning, SIDPLAY sends following SysEx command: F0 2D 4E 7F 7F 7F 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 F7 I guess that this command should set all 25 registers to zero - except for the volume register (address 0x18 ) which should be set to 0x0f. The "featured" double-writes to the waveform registers 0x04, 0x0b, 0x12 (<mask4>, bit 7-5) are flagged to zero, which seems also to be ok. Assumed that the data is sent in ascending order (like your spec could be interpreted), the volume register (0x18 ) will be set to 0 Assumed that the data in this example is sent in following order of address offsets: 6, 5, 4, 3, 2, 1, 0, 13, 12, 11, 10, 9, 8, 7, ... it will be set to 0x0f, so this order seems to be correct - or not? WIth the first conversion rule the SID plays mostly nothing, with the second one I mostly hear some rhythmic sounds, but they are still incorrect (wrong parameters) So, I would like to know about which parts of the document you are 100% sure, and which parts are assumptions. Best Regards, Thorsten.

And again: no further discussion before somebody tells me how to transfer the old articles to a new forum... ;-) Best Regards, Thorsten.

See MIDIbox64 Tutorial -> Snap Mode (Soft-Overtake function) Best Regards, Thorsten.

Just use the MIDIO128 application, it provides up to 128 LEDs Best Regards, Thorsten.

You made a good analysis! :) Best Regards, Thorsten.

Hi Ryan, crystals with parallel cut are optimized for parallel resonance with the oscillator. If you would use a crystal with serial cut (which can mostly be found in radio modules), the PIC won't run with the correct frequency. It must run at 40 MHz (external: 10 MHz), otherwise the MIDI baudrate will be wrong. Unfortunately every distributor has it's own way on identicating the crystal type. I can only say: if the type is not declared, it's a parallel cut crystal with a probability of 99% Best Regards, Thorsten. FAQMARKER

Maybe the 2 remaining pins? You should definitely search for a datasheet before destroying the LCD. Best Regards, Thorsten.