Tascam MM-RC Conversion to Midibox

[Narwhal]

So back in March I caught a post in the ebay thread about a Tascam MM-RC remote tape control.  I thought, damn that looks like it might make something cool so I bought one for dirt cheap.  It has a ton of nice buttons, led’s, a hefty encoder wheel, and an LCD display.

This past weekend I put in some time reverse engineering it and I thought I’d share what I’ve found.  I’ve built a schematic for the upper control surface so far and I think it’s going to be quite easy to make it do whatever I can dream up.  I’m thinking either some sort of logic control, or perhaps even a sequencer.

I’ll post the schematic when I get home later.

So lets start with the tear down pictures I’ve posted on flickr.

Next step is going to be using a DIN module to read the buttons, and some code to talk to the MAX7219 LED controller.  At that point I’ll have full control over the upper control surface.

[stryd_one]

Sweet score!!

some code to talk to the MAX7219 LED controller.

Read me you’ll like it.

[Narwhal]

Woot!  That’s good news stryd.  Apparently that was done for the stribe controller eh… This is going off topic, but look what I scored from ebay that will be my stribe-like project.  I think I paid around $10 for it!

Anyway, back on subject… I’ve attached a few files.  First is zip file that contains a replacement maxim component library for eagle that has the missing MAX7219,  and the schematic file I created.

EDIT:  note the left MAX7219 is not connected to any LED’s because I’m seriously considering chopping it off.  I don’t want all those LED’s where my sequencer panel is going.

[TascamMMRC_Upper.zip](< base_url >/applications/core/interface/file/attachment.php?id=4206)

[Narwhal]

Progress report:

1. built an adapter on protoboard so I could plug the control surface cable into a breadboard.. someone really should make something for this problem!  There is no place on breadboards to plug in cables.

[Narwhal]

2. spent a day debugging why 3 different core modules would only start up 10% of the time.  I suspect a wiring issue with the LCD, but point to point continuity tests all showed that everything was fine each time I tested it.  I still have no idea what was going wrong, but it’s now working 100%.

[Narwhal]

3)  a) connected smashtv CORE to DIN to DOUT

     b) cabled DIN and DOUT to a ZIF connector on a breadboard.

     c) cabled ZIF to control surface cable adapter on a breadboard

4. searched around through the code repository for code that makes a button scan matrix work.. finally Stryd tipped me off that it was named sm_example.  Can’t we use long filenames!?!  At least name the directory “Scan Matrix”

5. in main.c of sm_c_example1 I changed MIOS_SRIO_NumberSet(16) to MIOS_SRIO_NumberSet(1) because I only want to use one shift register right now.

6. I typed ‘make’ and let it build my project.hex file.   A split second later uploaded project.hex to my core and walla!  Hot button action.

[Narwhal]

So today I decided to tackle control of the Max7219 LED controller.

After much futzing around trying to figure out where the pins for Port C.0, C.1, and C.2 actually physically present themselves, I wired up power and the 3 control lines (LOAD/CS, Clk, DataIn) from the core to the MAX7219.  Noting too fancy.  I still routed all the wires through my ZIF socket and protoboard for simplicity.

When I fired it up the first time.. NO LIGHTS!  Doh.  Continuity all test out fine.  Frustrating.  At a loss I decided to see if anything in code could be causing it.  My first attempt I decided to move the location where I called MAX72XX_Init().  BINGO!  That worked.  Perhaps I can get an explanation for why the MAX72XX_Init() must be before the SM_Init() call for the scan matrix?

One “problem”.. with all the LED’s lit, my LCD display became almost impossible to read.  I had to turn up the brightness to max so I could read it.  Seems like the LED driver may like to have it’s own power regulator.  Maybe I’ll steal the regulator setup that was in the tascam originally.

Hey this Midibox stuff is a piece of cake, I’m lovin it!!  Thanks TK and everyone for all the work that’s been done to get this system to the place it’s at today.  Hopefully I can contribute something useful for everyone soon.  I have some ideas for improvements to the 72xx driver that I’m going to need for my next steps.

[stryd_one]

Yep your LEDs are using too much power. It’ll brown out soon if you don’t find a way around that.

As for the init calls… looking at them quickly I don’t understand why they should ‘clash’ or not work if not in the right order… Perhaps it’s something else you had inbetween them?

Have you disabled the AIN mux? The max72xx uses the AIN mux pins…

[Narwhal]

The only difference was that I had SM_Init() before MAX72XX_Init().

[stryd_one]

Had a closer look at it this morning, and still can’t see any reason why that would happen…

You didn’t mention, did you disable the AIN mux? The default pins for the max72xx driver use those pins, and the mux is not disabled in the driver’s init, so you should put that before the max72xx init…

[Narwhal]

would that be a call to MIOS_AIN_UnMuxed() ?

[Narwhal]

I’m taking a stab that these three lines should sufficiently say that I don’t want to use AIN features at all:

  MIOS_AIN_UnMuxed();

  MIOS_AIN_DynamicPrioSet(0);

  MIOS_AIN_NumberSet(0);

[stryd_one]

Yes indeed. Are those calls made prior to the init for max72xx?

So this works fine:

void Init(void) __wparam {

  MIOS_AIN_UnMuxed();

  MIOS_AIN_DynamicPrioSet(0);

  MIOS_AIN_NumberSet(0);

  MAX72XX_Init();

  SM_Init();

…

But this is no good:

void Init(void) __wparam {

  MIOS_AIN_UnMuxed();

  MIOS_AIN_DynamicPrioSet(0);

  MIOS_AIN_NumberSet(0);

  SM_Init();

  MAX72XX_Init();

?

[Narwhal]

Hmm seems to work both ways now.  Perhaps it’s my power gremlins playing tricks on me.  Seems like power is the next big thing I have to deal with.

Today I began attempting to get the hi-res optical encoder working.  I have it wired up and it looks like it’s putting out the correct pulses.  Unfortunately before I did that I chose to switch over to the sm_fast version of the button scan matrix code.  The sm_fast version main.c Init() function contains the following lines:

  // initialize the shift registers

  MIOS_SRIO_NumberSet(0);            // DONT USE THE MIOS SRIO DRIVER!!!

Does this mean I can’t use the MIOS SRIO driver at all??  Or can I tweak some pin values to move around the fact that another driver is dealing with a few of the DIN and DOUT shift registers?

[stryd_one]

Dammit I lost my post, I hate when that happens!

Hmm seems to work both ways now. 

Heh. Heheheheh. I’m so childish… It’s still funny.

Perhaps it’s my power gremlins playing tricks on me.  Seems like power is the next big thing I have to deal with.

Ah of course! That makes a lot of sense… the LEDs aren’t eating juice until after the init… This should definitely be top of your list. before the encoder, as it is likely to cause problems with those (logic levels being screwed with)

// DONT USE THE MIOS SRIO DRIVER!!!

Does this mean I can’t use the MIOS SRIO driver at all??

LOL take a guess!

…no, i jest…

Or can I tweak some pin values to move around the fact that another driver is dealing with a few of the DIN and DOUT shift registers?

Well actually now that you mention it… yeh …

; pins of SRIO shift registers

#define SM_SRIO_LAT_SCLK LATD ; Pin D.3

#define SM_SRIO_PIN_SCLK 3

#define SM_SRIO_LAT_RCLK LATD ; Pin D.2

#define SM_SRIO_PIN_RCLK 2

#define SM_SRIO_PORT_DIN PORTD ; Pin D.1

#define SM_SRIO_PIN_DIN 1

#define SM_SRIO_LAT_DOUT LATD ; Pin D.0

#define SM_SRIO_PIN_DOUT 0

;

I guess if you change those pins, you can run a second chain of DOUT/DIN modules for the scan matrix. Anyone see any problems there?

Seems to me that these two scan matrix drivers could be easily made into modules… what do you think, TK? Should we do it?

[DrBunsen]

Hey great Narwhal!  I’m happy to see it’s getting put to good use.

We are the MIDIbox.  You will be assimilated.  Resistance is futile.

[bugfight]

coolness, i gots one o those too.

haven’t even cracked it open yet… ahhh the muted beauty of the infinitely majestic queue…

did you realize it was from mark pauline of srl fame?

http://www.srl.org/

i actually shook his hand at the dallas video festival years back…

[Narwhal]

Mine came from a company called Digital Dream Sound Studios in Burbank via eBay.

I haven’t yet made it to an SRL show, but I’ve known about them for many years.  That’s really cool if yours came from him.  You should have had him burn the $#!t out of it before mailing it to ya :-)  I guess the $50 optical encoder that’s in there might not have survived in that case, so it’s probably better that you didn’t.

[Narwhal]

This weekend I did a lot of work on this project.   Follow along if you will..

I have been having power problems trying to supply the LED drivers from the core.  Perhaps its because of some other wiring problem, or perhaps it’s because all those LED on full brightness were sucking too much power.  Either way, the main board in the Tascam contains a very compact 3A switching power supply and that’s just what I need to make all of my power woes go away for sure.  So I desoldered all the part and moved them to a vero board.

Cheese eagle board file is available on request, but it’s nothing special.  I only made it so that I’d have a circuit reference once I desoldered everything.

[Narwhal]

In the Tascam, the ribbon cables from each of the control surface boards all connect up to the main controller board.  I desoldered all of the connectors on the main board and soldered them onto a vero board that I drilled so that is would mount on the center screw posts.