Jump to content

jbartee

Members
  • Posts

    88
  • Joined

  • Last visited

Everything posted by jbartee

  1. Hey guys. So I know it's been like a year, but I finally got around to doing some better video documentation. There's three new videos up on my youtube channel. Hopefully they'll generate some more traffic for ucapps.
  2. Heavy Rain is not fail, is awesome.

  3. I know this doesn't have anything to do with anything, but your avatar is killer. Boulder Dash is one of my all time favorite c64 games ever..
  4. Hi Jordan, In order to use the LFO's they must first be assigned to a parameter using the modulation matrix. Similarly, the ARP must be turned on before it will do anything. These kinds of patch editing capabilities are not available via CC's. There are a few different ways to do this: Easy options: 1. Download the MidiBox Sid V2 SysEx Editor ( http://www.ucapps.de/midibox_sid_manual_ed.html ). This is a java based patch editor that allows you to create patches and upload them to your MBSID. 2. Build a minimal control surface. 1 encoder and a few buttons will give you complete access to all the editing functions. This is really what I'd recommend. Some more hardcore options: 3. Bust out the SysEx implementation chart ( http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_sysex_implementation.txt ) and use something like Max/MSP etc. to send your own SysEx strings for enabling and patching the stuff you want 4. Build a full control surface, because it's awesome and you'll be happy you did it when it's finally done. :smile: I'd say check out the SysEx editor for now, aim to a build a minimal control surface soon, and expand it to a full control surface later. As for option 3, there's no real reason to futz around with building your own SysEx front end unless there's some specific custom implementation you want to do.
  5. Holy crap: I must have this.
  6. I agree it would be best to integrate into mios studio, but sadly my knowledge of C++ is extremely noobish. I'm trying to learn more but I doubt I haz the skillz currently to pull this off with "real code." I've already started building the max implementation however, and if someone with more chops wanted to adapt the architecture, it would probably be pretty straightforward.
  7. It occurs to me that what we really need is a calibration tool that will let you visually remove segments of an envelope, hear the resulting change in realtime on your mbsid, and then automatically determine precisely which regions should be omitted from the table. I think I can do this in max 5 by modulating cutoff using an nrpn, and then using a simple algorithim to convert from the current 14-bit step to the correct 12-bit step for use in the table. This way you could calibrate the filter in realtime, and only edit / upload the hex file once. If I get anywhere I'll post the patch here, as well as build a mac (and maybe windows if there's any interest) executable. I have a little time off in a couple days, so watch this space :smile:
  8. No details missing! I posted "blind" before noticing that it had already made its way to the repository / official rc36 release.
  9. Wow Thorsten, you're fast. Thank you once again for the awesomeness! Also lol @ NMFP. I wonder if you can walk me through the process here a little bit, since I'd rather not wait till the rc36 release to get this calibrated. The table can be compiled as a seperate hex file, or does the entire firmware need to be recompiled? EDIT: Oh, my bad, I just saw that RC36 is now available. Sweet.
  10. Great news! I don't want to rain on the parade, but I'm still a little concerned because we don't know why attaching the LCD has spontaneously fixed the problem. If it works it works, I guess, but it would still be good to figure out what's going on. I wonder, when you removed the LCD originally, did you also remove the 1k pull up resistor on pin d3 of core j15 (shown here: http://ucapps.de/mbhp/mbhp_lcd_4bit_mios8.pdf ). Not having that resistor stuffed has been known to cause BOR style reset patterns similar to what (I think) was going on with your core. Anyway, the patch can be changed by sending a midi program change message. Most keyboard style midi controllers have this hard wired to generic + and - buttons. If you want to change a bank, send CC#0. Glad you got it working!
  11. I'm just out the door to go to class, but tentatively I'd say it sounds like your core is constantly rebooting. My MB makes that popping sound immediately when I first turn it on. This would explain the delay also... every time the core resets, the SID modules and midi i/o must be reinitialized, during which time they will be inaccessible. You could confirm this by hooking your lcd back up (try without the backlight first) and see if you are getting the mios boot screen over and over again. Not 100% sure about this one, but start by checking behavior with the LCD. I wouldn't stick your other SID chip in just yet until we can figure out what's going on.
  12. And here it is, commented in filter.cc in the latest resid source: "The function mapping FC to cutoff frequency has the shape of the tanh function, with a discontinuity at FCHI = 0x80. In contrast, the MOS8580 almost perfectly corresponds with the specification of a linear mapping from 30Hz to 12kHz."
  13. Sigh. It's such a dilemma for me with 8580's. I vastly prefer the timbre of the 6581 filters... there's a certain warm distortion in the lower registers of the LP filter that just makes me incredibly happy, and it's the sound I remember from my old breadbox as a kid. But on the other hand the reduced bugginess of the 8580 is incredibly appealing. This latest discovery just makes it even worse - a beautiful filter that has a seriously messed up bug, or a functionally correct filter that sounds (to me) clinical and dry. Since it looks like this is the natural behavior of the 6581's (it's kind of hilarious that sidplay attempts to emulate it!) maybe it's not worth Thorsten's time and effort to build a workaround, especially since I seem to be the only one who's really noticed/cares about the issue. Unless TK is just feeling incredibly generous of course. :tongue: Otherwise I suppose I'll begin my quest for the 6581 "holy grail," since there are clearly some that fall on the good end of the bell curve with little to no jumps in the filter curve.
  14. You're very welcome! :) That's great you got the testone working... the first step to a working box! It's odd that using the testone app produces a loud, clear tone but the mbsid app produces quiet notes. I'll have to give that one some thought ( = Tomorrow, it's bed time for me now I think). When you say lag time, do you mean between sending a note-on message and hearing a tone? Also, the "clicks between notes"... is this like a DC offset type sound, or something else? Some mp3's might help.
  15. I suppose for a quick a test it would be okay, but not really recommended. The 7805 is going to get extremely hot since it will be burning up the difference between 17-5 volts = 12v! :frantics: Perhaps better would be to continue powering the core from your 12v supply and run SID j1 off of the new psu; this should have the same effect of reducing the load on the old psu while avoiding the thermal problems withe the 7805. It was for exactly this reason that I actually have two seperate transformers in my custom psu- a 15v supply regulated to 12v to drive the sids, and a 9v supply regulated to 5v to power everything else. This way the 7805 stays nice and (comparatively!) cool.
  16. Yikes! Don't plug that in directly to the SID (via pin 2 and 3 of the 7812)! If you're going to use a 17 volt supply, make sure you connect it to J1 so that it will be filtered and regulated down to 12v.
  17. Also, perhaps we should start refering to this issue as " The Non-Monotonic Filter Problem," or NMFP for short, as this seems to be the technical term. :smile: EDIT: I just found this graph in the resid page you linked: http://www.bel.fi/~alankila/c64-sw/fc-curves/curves.png The majority of these display some pretty hardcore spikes around 1024, so I guess this could be a fairly common issue with 6581's. I've bought some matched R4AR's that should get here in a week or so, it will be interesting to see if the issue persists with later rev 6581's. That is assuming they don't end up being remarked Chinese garbage and the filters work enough to allow testing!
  18. Yes, this definitely should not be happening. It's hard to tell exactly what would cause this behavior without being able to closely inspect your setup, but it could simply be that your PSU is sagging when under load, in which case swapping it out for a higher rated supply is the way to go. There's a couple things that make me think this might not be the issue however, one of which being the upload request - which means the pic is getting power. However, since you'r getting errors trying to upload hex files, perhaps the voltage is just fluctuating all over the place and the core is sporadically rebooting. :ermm:
  19. It's possible. I'm not sure how much current the SId is sinking but it's probably between 50 and 100 ma. Smash recommends supplying the core with a 500ma supply, though this is with a backlit LCD attached. It certainly couldn't hurt to try a higher rated supply. If you're planning on building a full control surface later, you'll need something in excess of 1A anyway, so it might make sense to just invest in that now. I'm using a 2A supply with my midibox sid.
  20. Not unless you remove the voltage regulator and the bridge rectifier. Supplying power at j1 will feed into the inputs of the 7812 through the rectifier, which won't work using your 12v PSU (voltage regulators require a few volts above their regulation to work, and the rectifier causes an additional voltage drop, meaning you would be supplying the 7812 with something like 11 volts when it wants 14-15 volts). Connecting your psu to j1 won't hurt anything, but no power will make it to the sids.
  21. Okay, it seems there's a problem with your interconnection between j10 and j2. It should be wired like this: J10 J2 MD -> SC MU -> MU CLK -> CLK VD -> VC Vs -> Vs SO -> SO RC -> RC SC-> Nothing! (it's not used by the SID module) You can use these two images as a guide, as I've said the connection should be 1-to-1 (physically, pin one should go to pin one, 2 to 2, etc, the labeling doesn't necessarily line up!) Using a separate power supply for the SID can help reduce noise, but isn't strictly necessary.
  22. No problem man, I hope we get you closer to a working MB. looking at mbhp_sid_c64_psu.pdf (which I never looked at before!) I see now where this j2 business comes from. If you wanted, you could continue to supply sid j2 with core j2, so long as you're powering the core through j1 with regulator stuffed. This all leaves the question open however as to what caused your explosion to begin with, if you had everything wired according to the schematic and used a c64 PSU. Perhaps someone smarter than me could chime in here.
  23. Good work! 1980's tolerances strike again. The wikipedia article is super informative. I think the calibration table is a great idea... at least for me it would be no problem at all to edit and rebuild, and it would be great to kill those bad steps for good. I'd much rather do it this way then try to track down 6581's without the screwed up r-2r dacs, or worse yet "upgrade" to the 8580's (which are not my bag at all). Edit: ouch, 4k. Here's hoping there's enough available space!
×
×
  • Create New...