Dear Teenage Engineering: I love your company, I love the OP-1. Your design work is incredible and you seem like one of the nicest companies I know. So please understand that I do not in any way, shape or form want to harm you. I simply like to tinker and play with my hardware and I love reversing stuff and finding out how things work. Since this research may very well lead to custom firmware with your IP in it, I will not release it without your blessing. If you want to get in touch, send me an email to tabascoeye AT gmail DOT com.
Now that this is out of the way, let's get into it.
I stumbled into all this after getting my OP-1 about 2 years ago. Looking at firmwares is kind of a hobby, so naturally when a filetype ".op1" comes along, I'm interested in taking it apart.
1) OP-1 update file contents
The update files that you can download from teenage engineering actually are just a compressed file containing more files. The format is called LZMA and is a compression algorithm. To make sure that the file arrived on the OP-1 when you transferred it, a 4Byte checksum (CRC32) is added infront of the compressed file. That is usual practice with files in embedded systems.
So if you strip those 4 Bytes, you can just decompress the contents. (Since I am a lazy bastard, I usually just let 'binwalk' do its thing on files I don't know)
One of the oddest things about the OP-1 when I read about it first was the marketing notion of the "vector based display" since the OP-1 clearly has a pixel based OLED display.
So in essence probably someone heard from the developers that they use "scalable vector graphics" (SVG) to create all the graphics.
The fun part about SVG is that it is an XML based format that has concepts like "display=none", ids and groups. So they could likely split into the programmer group, writing the animations by using ids and switching "display=none" to "display=inline", and a designer/graphics group that could change the actual graphics without the need of re-programming anything.
Btw: Most of the graphics were done with Adobe Illustrator CS4, some with CS3 and in the beta, there are files done with "17.1.0" which is probably Illustrator Creative Cloud.
The OP-1 works with a BF-524 as main CPU. That is a “BlackFin” DSP chip made by Analog Devices. It is also used in digital storage oscilloscopes because of its DSP capabilities.
The blackfin uses a weird format for files and documentation isn’t that easy to find. Essentially, the LDR (or “loader”) format is what the CPU expects as download format. It consists of “blocks” of data, each with a header and there is a bit of “compression” involved (namely there are headers which say “the following X Bytes are all 0”) thus when loading that file, the CPU fills its memory according to the instructions in the loader file.
According to AD documents, the file that is represented by all the blocks in the LDR file is a “DXE” file. I found some mentions about DXE being a lot like ELF, which says a lot and nothing at the same time.
So essentially, to really run your own code on the OP-1 you would have to:
write a decoder software to turn the LDR file back into DXE
find out the format of DXE
write a disassembler for blackfin (or hope that e.g. radare works with it)
analyze the codeflow and delete/insert parts where needed
turn the DXE file into LDR again
re-package the whole OP-1 firmware update package
upload! \o/
and yes. That is about as much pain as it sounds. At first I thought that the OP-1 would run ucLinux on there because there are some tools and eval kits for the BlackFin running that. But there is no reference whatsoever to Linux in there, so the theory of it using VDK (the kernel from VisualDSP) is much more likely
The firmware uses quite some known opensource software:
yaffs2 - a file system for flash chips (the memory of the OP-1, noted as "grandmaster flash" on the PCB)
libaiff-5.0 - a library to mess with the aiff files used for audio
sqlite 3 - a relational database
box2d - a physics engine (most likely for things like tombola and the chopper game)
libjson - a helper library to parse the JSON format
probably more...
I found out most of this by just getting every readable character (ASCII) from the .ldr file. In Linux there is the "strings" command for that.
The usage of SQLite databases and SVGs is pretty ingenous as I mentioned because they could change large parts of the OP-1 without the need of recompiling all the C++ code and run it through the whole toolchain. Instead, they could just exchange SVG files or write other values in the SQLite DBs to change the behavior of the synths etc.
maybe the funniest moment was when I checked the database files which are in the update package in a SQLite browser.
There is "kerntable.db" which consist of the columns "a","b" and "kerning". You can be sure you are dealing with designers when there is a database that controls the kerning between each symbol on there :o)) Did I mention I love that company?
so apart from this fun file, there is "op1_factory.db" which seems to be the key file in doing a "factory reset". And that contains this very interesting table:
notice the "id" column. So there are some values missing: 1, 2 and 6....
trying out the correct values of the fx_type database table
which type fits which id (is the order even important? it seems so based on my experiments)
which default_params are needed for the missing fx? (this is a major pain in the butt to figure out because of the time it takes to create an FW, download it, try, fail, factory reset, back to square one)
find out if the fx even works with the current firmware. maybe its broken or barely usable? Theres probably a good reason for taking them out...
trying to find out the workings of the SVG files to create some nice custom graphics (as indicated in my other post.. but.... wait for it ....)
and finally:
the cown jewels: creating all the tools necessary to crack the actual firmware open, figure out how it works and mess with it until something new comes out (usually the "hello world" of custom firmware on devices is getting "DOOM" to run..... ... .....)
So thats the current state and I'll continue to work on it when I have some spare time. In the mean time I will give you a teaser of what I have in mind when talking about "custom graphics" :o)
<span style=“color: rgb(37, 38, 30); font-family: “lucida grande”, “Lucida Sans Unicode”, tahoma, sans-serif; font-size: 13px; line-height: 22.1px; background-color: rgb(252, 252, 255);”>Hope you manage to get the equivalent sonicwise, that would be awesome
And that filter fossile?