SEGGER Blog

This continues the journey of analysing how the Akai Fire is controlled over MIDI and deals with the OLED display.

The OLED is a challenge!

Looking at the OLED, it’s small at 128×64 pixels, with each pixel being taller than it is wide. But here’s the proof that you can write to the OLED!

As an embedded engineer, it’s much easier to keep your firmware simple and offload as much as you can to something that is easily changed. Burdening users with continual firmware updates that have the possibility to fail, or even brick the device, is something that you want to do only if you’re superconfident. Best would be to buy the technology from SEGGER, an unashamed plug for our emLoad product!

The OLED is small, so my spidey senses tell me that the host will be constructing what it wants to display. It will then sending that bitmap wrapped in a SysEx to the Fire because this is the only way to transport large amounts of data with MIDI. It also makes sense—why fix displays in your firmware where it’s difficult to modify when you can do everything on the PC where program changes are easy?

And that is exactly how it pans out.

Replaying messages

Having cracked the pad RGB SysEx, it’s time to tackle the other SysEx messages that I found. And this is where it comes down to observation and experimentation.

How do you figure out what a long SysEx message does? Easy. You capture it and you send it to its destination and see what happens! For the OLED, this is exactly what I did, capture the SysEx messages and replay them under my control and observe their effect.

Playing them back, you can sometimes see what they do and indeed, I can write to the OLED display by sending it specific messages that FL Studio sent in the past, and I can alter the entire display.

Mutating messages

Experimentation is straightforward as well. There are lots of zeros in the candidate message, and I equate zero with “no pixel” for the OLED. If I change one of the zero bytes to 7F, thinking “seven pixels set” what do I see? I see seven pixels set, but in some weird non-intuitive pattern. The pattern is not entirely random, but not entirely regular either. Well, save that for another day.

If I set most zero bytes to 7F, leaving a few zero bytes at the beginning as zero just in case they are important controls, and I get a mainly white display.

Stepping back in the message byte by byte, setting each to 7F in turn, I can get the entire display to turn white. Result! There are a few bytes at the start of the message, but that’s OK, I don’t need to understand what they mean, I just need to accept that they are there and always send them. (In fact, I do now understand what they mean!)

The warped pixel arrangement

Back to the pixel arrangement. To understand how things are mapped to the OLED, I send messages where each successive message has a single additional bit set. When the message is sent, I expect to see one pixel on the display change. Using a magnifying glass, I write down the mapping of pixels on display to bits in the SysEx message.

What I see is that strange pattern repeat itself over and over, regularly.

The display is divided into eight bands of 8×128 pixels.  Each band in this arrangement is written in a block of 8×7 pixels, where the bit position in the MIDI SysEx message bears no linear relationship with a pixel on display.

Mapping this 8×7 block to MIDI messages looks like this:

    MIDI Message bytes (msb always 0)                  Display positions
   7    6    5    4    3    2    1    0           0    1    2    3    4    5    6
+----+----+----+----+----+----+----+----+      +----+----+----+----+----+----+----+
|  - |  6 |  5 |  4 |  3 |  2 |  1 |  0 |   0  | 13 | 19 | 25 | 31 | 37 | 43 | 49 |
|  - | 13 | 12 | 11 | 10 |  9 |  8 |  7 |   1  |  0 | 20 | 26 | 32 | 38 | 44 | 50 |
|  - | 20 | 19 | 18 | 17 | 16 | 15 | 14 |   2  |  1 |  7 | 27 | 33 | 39 | 45 | 51 |
|  - | 27 | 26 | 25 | 24 | 23 | 22 | 21 |   3  |  2 |  8 | 14 | 34 | 40 | 46 | 52 |
|  - | 34 | 33 | 32 | 31 | 30 | 29 | 28 |   4  |  3 |  9 | 15 | 21 | 41 | 47 | 53 |
|  - | 41 | 40 | 39 | 38 | 37 | 36 | 35 |   5  |  4 | 10 | 16 | 22 | 28 | 48 | 54 |
|  - | 48 | 47 | 46 | 45 | 44 | 43 | 42 |   6  |  5 | 11 | 17 | 23 | 29 | 35 | 55 |
|  - | 55 | 54 | 53 | 52 | 51 | 50 | 49 |   7  |  6 | 12 | 18 | 24 | 30 | 36 | 42 |
+----+----+----+----+----+----+----+----+      +----+----+----+----+----+----+----+

The left-hand side shows the MIDI message bytes in transmission order, 0 through 7, and a reference bit number, 0 through 56. The most-significant bit of each MIDI byte must be zero by the MIDI specification.

The right-hand side shows how each of those reference bits controls a pixel on the display. No, there is no obvious logic to the mapping. For instance, follow column 1 of the display, from 7 to 12 going down, then see where 13 lies, and then 14. Bizarre.

With this understood, I put together a display function that plots a pixel using regular coordinates using the warped pixel mapping:

The OLED “write display” SysEx

The SysEx that writes the OLED display is as follows:

F0 – System Exclusive
47 – Akai Manufacturer ID
7F – The All-Call address
43 – “Fire” product
0E – “Write OLED” command
hh – Bits 7-13 of payload length
ll – Bits 0-6 of payload length
00 – Start 8-pixel band of update
07 – End 8-pixel band of update (here, 8 bands of 8 pixels, i.e. the whole display)
00 – Start colum of update
7F – End column of update
xx – Bitmap data formatted as in _PlotPixel()
F7 – End of Exclusive

This is all wrapped up in some code that you can deploy using Embedded Studio and the SEGGER emPower-USB-Host board. But if you want to run it on another controller, or convert it to something else like Python, go for it!

Bonus material

Here’s two tidbits that I found playing with the Fire.

Bet you didn’t know that there’s a color-balance mode in the Fire?  Well, you do now! To access this:

• Remove the USB cable
• Hold down the four buttons at the bottom right of the device (pattern, play, stop, rec) and keep them pressed
• Plug in the USB cable

You get this:

I guess you could really screw up your Fire if you wanted to, so be careful!

And what else can we uncover?  Same deal:

• Remove the USB cable
• Hold down the four buttons at the bottom left of the device (step, note, drum, perform) and keep them pressed
• Plug in the USB cable

You are now in STM32 bootloader mode… I’m not familiar with the operation of the STM32 bootloader because I always debug using a J-Link and trace using a J-Trace. But for the curious, maybe you can figure out firmware replacement if you want to.  Perhaps you can crack open the case and see if it has a 10-pin Cortex connector for debug.

Unfinished business

There is some unfinished engineering here. I know, for instance, there are more MIDI messages that control the OLED operation, and I know what they do from seeing when they are sent. I also know how to make the single OLED message described above more flexible by changing its first set of parameters, but I don’t need to use that right now, so haven’t documented it.

What irritates me the most is that I know that each of the buttons (not the pads) and the bank LEDs can be fully controlled debecause the Fire has a built-in demo mode. That means the buttons are capable of more than just dull and high intensity levels. If you plug the Fire into a USB power outlet rather than a computer, you get to see that all buttons and LEDs have smooth dimming.

I tried a few things to see if this was exposed, but there wasn’t anything I could find that would set arbitrary levels on any of the controls. I tried using pad indexes from 0x40 up, additional SysEx messages with single color controls, and scanning SysEx command from 0x00 through 0xFF. Nothing. Some even crashed the Fire. But hey, you might be able to explore, poke about, and see if you can find some and, if you do, I would be very interested to hear about it!

Final thoughts

I wrapped all of this knowledge into an application that demonstrates my Fire reverse engineering journey so far. I’m now off to make my ideal step sequencer for myself using this knowledge, and I’ve ordered more Akai equipment to control. So life is good, and I hope this helps somebody else put their Fire to new uses!

Example System Exclusive files!

As promised, here is a Zip file that contains an assortment of animations and things that may help you with programming the Fire using MIDI.

Akai Fire Sysex Examples

The code

Here is the code ready to use on any device that has emUSB-Host running.