Jump to content

Jegge

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by Jegge

  1. Indeed, I use the V-USB driver. But up to now I haven't encountered speed problems - I will update my test app so that I can measure the time it takes me to transfer large blocks, you made me curious :) As far as I understood reading their forums, the transfer speed they got with their tests was around 7000 bytes/second. The speed of my device is probably less. But midi only needs around 3900 bytes/second, so I suppose that is still covered.
  2. Hi, you're probably right about the smd fear :) But to me it deems so diy-unfriendly. I am totally able to fry full-size chips, but some day I will try smd's (they should be even easier to burn, shouldn't they?).
  3. Hi everybody, I've planned to build a sammichSID (thanks for the opportunity, Wilba :)), since I just couldn't get on with the modular Sid experience - I found it to tearsome and got lost in the chaos of wires. But a drawback I saw in the sammichSID is the missing midi through, which I've had in the modular version - frankly, I was in need of another midi interface. Since I've got an arduino recently, I've started experimenting with it and designed a Usb to Midi interface around the Atmel platform. The project started out on the breadboard, moved up to a prototype board and currently I am waiting for the real pcb prototypes to arrive. The design goals were: cheap, small, no smd, no drivers! Features: 1 Usb, 1 midi in, 1 midi out No SMD No drivers required (so far tested on Windows XP and Linux 2.6) Small: PCB is 68 x 46 mm (fits in the GEH KS 35 from Reichelt) 3 Leds: 1 Power / Error, 1 Midi in, 1 Midi out Powered by Atmega48 Cheap: parts and case about 6 EUR, PCB would be around 3 EUR (when ordered in quantities 150 and up) Open Source Cons: There are three variants already, who'd need one more? In system programming capability omitted due to size restrictions, a separate programmer would be needed if you want to modify the firmware Only 1 midi in, 1 midi out :) Does not fit in the mbhp, since it uses an atmel controller and completely different firmware If there is enough interest, I will try to make this available as a kit. The estimated price would be around 10 EUR (excluding packaging and shipping), and I'm cutting my own throat :) CU Jegge
  4. Hi, I also experienced something similiar: Never ending reboots and sysex messages (only with version V1.74685, I did not try out V2 up to now, V1.7303b worked more or less). The mistake I made was leaving out the 100N caps located on the bottom side of the LTC module. After having soldered these in, it suddenly worked. I suppose that, the more peripherials are connected, the more likely a missing cap will lead to errors (read: corrupt signals), so I guess this triggered some kind of watchdog... CU Jegge
  5. No, the MAX232 ist not present - as I said, I just wanted blinking lights and a midi through port. ;D @TK: You did a great job designing this plattform! I consider also using it to midifi a Roland Trident, but beforehand I'd like to earn some ucapps-xp and get my sid user interface to work. CU Jegge
  6. Thanks for help, I think I've got it now! I did the whole troubleshooting procedure before, and it seemed ok so far. But then I replaced the optocoupler because I was frustrated and I didn't know what else to do ;) . This improved the stability a lot - still without the LTC-module connected, which made the system unstable again. I found a second bug on the LTC - I just forgot to solder the capacitors on the bottom side. Now everything just runs smoothly, great :) @TK: I wish to use the LTC only for a MIDI-tru and blinking lights, not for connecting it to my pc. I will now try to get MidiBox SID 1.74685 running and to connect a user interface. CU Jegge
  7. Hi everybody, I am new to the whole midi&soldering business and have recently built a simple "step a" sid (1 CORE + 1 SID + 1 LTC (passive) + 1 512k-BANKSTICK + OPTIMISED_C64_PSU). I experience random midi glitches when playing the sid via keyboard or sequenting it from my computer, it seems that note off events go amiss and notes hang (they stop on midi reset or if I lay my hand on the keyboard and trigger lots of events at the same time). Also when sending patches via jsynthlib, data corruption can lead to "interesting noise" due to weirdly programmed patches. When having the LTC module (without MAX) plugged in, the situation worsens to the point that I cannot upload MIOS anymore - I get a lot of "MIDI IN OVERRUN" (or something similiar) messages in MiosStudio. I noticed, that in fact, each time a note hangs, the mbsid sends a midi message, that is, the midi out led lights up. What does this mean? I started out using a PIC18F4620, but now use a PIC18F4685 with MIOS 1.9e. I've tried MidiBox SID 1.74685 and 1.7303b on both and the problem persists. In fact, when using the 1.74685 release, the box keeps on rebooting endlessly, but this may be another problem. Anybody out there with an idea? CU Jegge
×
×
  • Create New...