Reverse engineering is just the time-reversed antiparticle of regular engineering, and when the two collide it usually results in a massive release of energy. Today that energy is being released through a soldering iron, adding some header pins to this DE-9 pass-thru adapter I got.
Like this.
Why do I need them? Well, I'm glad you asked.
This is my Roland S-760, connected to my Roland RC-100 by way of this convenient pass-thru DE-9 adapter, complete with a very convenient set of header pins. Header pins that I can attach scope probes to, in order to see signals like this.
The purple trace on top is the clock line, and the yellow trace is the data line. The S-760 sends out a long high-pulse on the clock line to initiate the data transfer, and then the RC-100 responds by toggling out the most significant bit of the 7-bit word. Each bit thereafter is put on the data line shortly before the next low-to-high or high-to-low clock pulse, to give us a double data rate signal at around 60kHz.
The initial clock pulse is about 45 microseconds long.
And the data is put on the bus about 5 microseconds before the clock transition.
The RC-100 asserts an ATTN signal by pulling it low in order to notify the S-760 that it wants to send a packet. It holds it low for the entire transfer, including when sending a 2-byte sequence for the dial motion: a zero followed by a signed 7-bit value for the relative rotation since the last transmission (positive is clockwise).
As you might imagine, there's no consistent timing between the ATTN signal and the start of transfer. The S-760 just gets around to it when it gets around to it.
And, hmm, these header pins are getting a little bit crowded.
Ok, using a ribbon cable makes things a lot easier to manage.
The S-760 will send LED updates using a sequence of 4 bytes. I've only observed the first two bytes being used, however, so I don't know what the function of the second two is.
Now you might think that this first block of 14 bits maps to the 14 LEDs on the device in an order that makes logical sense based on the logical pin ordering of the IC they're connected to. Or perhaps one based on the component designators.
But neither of those appears to be correct. It seems like the MCU in this device does some logical reordering to map the bits to the LEDs in an order that's roughly in line with the physical layout of the device. Here's a dump of the start-up chaser sequence it does after a reset:
And this corresponds to Play->Edit->Disk->MIDI->Func->Utility->F1->F2->F3 twice, then lighting up Edit-Disk-MIDI-Func-Utility all at once.
Poking around, it looks like Menu is 0x4000 and Command is 0x0100. I haven't managed to get Sub Menu, Execute or Rec to light up from interacting with the S-760, so I'll have to see if I can just inject some data to map out the remaining bits.
But how am I capturing this, and how am I planning to inject this data?
With a friendly little Arduino Nano, of course.
Anyway, how about the mapping in the other direction? Well the high bit is for key-down: 1 for down, 0 for up. From there, it goes like this:
0-9: 0x00-0x09, conveniently
Enter: 0x0A
Inc/Yes: 0x0B
Dec/No: 0x0C
Right, Left, Up, Down: 0x0D to 0x10
Del: 0x11
Ins: 0x12
Play, Edit, Disk, MIDI, Func, Utility: 0x13 to 0x18
Menu, Sub Menu, Command, Execute: 0x19 to 0x1C
F1, F2, F3: 0x1D, 0x1E, 0x1F
Start/Stop, Rec: 0x20, 0x21 (these are hard-wired to the pedal inputs, so the same values are used there)
Now one sneaky thing I should mention here is that while the RC-100 transmits to the S-760 at around 60kHz, the same is not true in the other direction: setting the LEDs is a much more leisurely data rate.
The bits are clocked at 33kHz, or 30 microseconds, and the initial pulse lasts a solid 85 microseconds.
And that tripped me up for a while. (Ignore the yellow trace in these pictures, I didn't have that probe connected)
Anyway, I only have a bit more work to do in order to map out the final three LEDs, and then I'll be ready for the next phase of the project. More to come then!
No comments:
Post a Comment