• Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by brianv

  1. There really isn't a lot to the hardware side of things, I don't think.  Check out this example:  All that's done is hook up the pot to +5, G and then to a GPIO.  The tough part is going to be updating the software to do what you want. 


    The easy way to do it without building anything is to use the onboard MIDI capability and get a control surface like the Kork nanoKONTROL or Behringer BCR and then map those controls to the functions you want to control.  


    There is also a new MIDI library for Android that looks pretty promising.  I have yet to try it out, but if you have USB OTG capability on your phone,it would be possible to create a control surface on the phone.  I am actually really interested in doing this for the Retrocade :)     

    • Like 1

  2. The sheet metal style case is good for low volume production, I think.  Nice too. The sheet approach could also be taken with acrylic or abs (heat bend), this might be more cost effective.  The acylic might even be the cheapest because it could be laser cut.  Then just get one of the guys that's making the wooden synth cheeks already to churn some out for you.

  3. I don't want to hijack a productive discussion, but I was talking to my buddy about this and he said "use the onboard DSP blocks".  


    The 3E doesn't have them, at least I am pretty sure it doesn't, so that begs the question: Are there any plans upgrade the Papilio to a Spartan-6 or something that has DSP onboard? The 3E is "not recommended" for new designs, and one of the things that's nice about a devboard is to use it as a proving ground for a design, then move it to a prototyping phase.

  4. Would it be hard to do one knob divided to six positions that selects which midi-channel is edited (SID-channels 1-3 or YM-channels 1-3)?  


    I have been headed down a similar route, but I am not going to be modifying my hardware just yet.  The RetroCade already has CCs mapped to the parameters, so if you already have a MIDI controller with some programmable controls, you could just map these to the RetroCade.  Then once you have it working the way you want it, you could add the knobs and buttons.  


    But yeah, to answer your original question, I think adding the extra controls you talk about should be pretty easy.  If you wanted a more compact control surface, you could have a push buttons (arrow keys) that cycle through the voices and then a set of controls to edit the selected YM/SID voice.





    Is it possible to detach the screen and joystick and resolder them again with some wiring if I would like to have everything in a neat box? It seems that joystick and screen are lower than midiports?


    The LCD is attached with a header to the PCB, so you should be able to just unscrew it and run a ribbon cable to where ever it needs to go. For the joystick, I wouldn't recommend desoldering it.  Just add another joystick and update the code to

  5. But are your "items" all the same size, meaning, do you want to allocate fixed size blocks (like always malloc(32)  ?)


    In case you want a simple Queue, you can try using the <cbuffer.h> I wrote, it supports any kind of structures (if they are constant in size).


    Here's some information regarding bitmap allocators:





    Thanks for the links. The CBuffer code you wrote is pretty slick, but I wanted a data structure that would allow to remove items from the middle of a list.  In the end I switched the Linked List/Stack over to used a fixed size buffer of ListNodes.  It's stable now, haven't seen any crashes since I made the update.



  6. I've been making some updates to the RetroCade codebase.  I pulled down a Queue class from the Arduino code gallery and made a few modifications to it. I am having some stability issues after a bunch of new/delete operations, I get a hard crash and the Papilo freezes.  I've done some troubleshooting, but as far as I can tell I don't have any memory leaks.


    To shed some light on what's going on, I added two global variables: one for allocations and one for de-allocations.  These are incremented and decremented with each operation.  I dump these values out to the console periodically and haven't detected any memory leaks.  In my particular case there are at most 3 dynamically allocated objects at a given time. The alloc/dealloc counts  are exactly what I am expecting: If I have 303 allocs then deallocs would be somewhere between 300-302.  




    Do I need to do anything other than call delete to ensure dynamically allocated memory is freed up?

    Is it preferable to use C-style allocation/deallocations for applications like this?

    Can anyone recommend any profiling tools I can run to help me track down memory issues?

    Since I know the maximum amount of memory I will ever need ahead of time, would it be better to create a statically allocated pool of objects and pull them out of the pool when needed instead of dynamically allocating memory?





  7. I just committed my enhancements to this fork:  The unison and poly modes are function the way that I think that they should, but I am having some stability issues with the dynamic memory allocation (new/delete).  


    Change Log:



    - Encapsulates the base functionality of voice (note, pitch, envelope, etc)



    -  Stores a list of voices and manages them based on the current mode



    - Wired up the MIDI program change to change programs.  When it gets the change notification, it jumps right to the menu so that if you're operating the RetroCade from an external keyboard, you'll see your updates on the LCD immediately.

    - The patch/program menu now displays Program #, voice mode, voices used, and the program name


    Build Config

    - Added a Config.h with some build-configuration #defines. I think it would be great to have one branch for RetroCade and RetroCade lite.  



    - This is working differently than before since Poly/Unison modes are only responding to notes on one channel.    


    From what I've seen, the standard way to have multiple voices playing simultaneously is to implement a split mode where each voice is assigned to a note range.  This way you could, for example have a drumkit and bass living inside one patch/program.    

  8. I have added some code implementing a unison and polyphonic mode.  


    The unison mode really sounds pretty fat with the 3 SID voices stacked together, I can't wait to hear what it sounds like once we have filters.  I also introduced the concept of a patch which manages the layering of the voices and handles parameter changes and "wired" it up to the MIDI program change event.  


    What would be the best way to share the code?

  9. Maybe someone can answer this for me.  


    When I installed the Windows installer package for Retrocade, I believe it installed TWO instances of the FTDI virtual COM port driver. The FTDI driver was likely installed before for other devices on my computer before installing the package.


    When I plug in the Papilio board, two COM ports show up, and the location field in the device manager days "on USB Serial Converter B" and "on USB Serial Converter A"



     > FTDIBUS\COMPORT&VID_0403&PID_6010
    Is this supposed to happen? When I tried programming the Papilio with the one COM port nothing happened. 



  10. Is there a "lite" bit file available for 1.02?  The one linked here still says 1.01.





    The RetroCade Lite Bit file linked above still has the bug.  I also tried the RetroCade Lite sketch from the GIT repository, that also has the NoteOff bug. 


    I went ahead and applied the patch manually, here is a modified RetroCade Lite sketch with the patch applied.  



    I am getting a bit of a click on the note off with "Accordian" and , but that may just be the decay settings on those patches.

  11. Good question, I was wondering about something similar myself.  


    About how many gates do the ZPU, SID and YM cores take up? If you were to say, add another SID core, would you be duplicating it in its entirety  or would it be possible to reuse some of the blocks within each core to reduce the number of gates used?