Yeah it’d be really interesting to develop an alternate graphics pack 
The blackfin uses a weird format for files and documentation isn’t that easy to find.
ftp.analog.com and maybe pub/dsp/blackfin and then there’s more stuff in pub/dsp/tools and some juicy stuff in e.g.pub/dsp/210xx/code_examples/65l-ezlab or apps_handbook, admittedly for a different chip but , additionally you can find VisualDSP on the Analog Devices site, as well as a library of software modules and more software and tools for the blackfin. i’m sure some of the binary output of these will give you recognisable patterns to munch on… the official dev kit is $$$
Just so nobody gets their hopes up in this thread: I will not post any complete firmware here as that would contain Teenage Engineerings intellectual property and I would be redistributing it, which is copyright infringement (see cyanogen mod for android).
What I can do however is post instructions on how you can create your own firmware.
We can probably share mod instructions and maybe even modified/new SVG files and .db files, but full firmwares will be a no-no.
1 Like
@tabascoeye dang… This tech stuff is waaay beyond me to even follow instructions! Hopefully if some cool custom stuff gets made by users it will find its way to TE/official OS at some point. Guess you guys could maybe even earn a little £ potentially if were able to hand TE something ‘finished’ for possible OS inclusion that they liked, they’d probably be way more excited to check that out than read all our feature requests 
1 Like
At this point, it would make more sense to earn some other currency instead ;o))
1 Like
Hahaha true 
I’ve no idea on details/complications around redistribution of intellectual property law etc but (unless I’m missing some huge downside?) if I was TE I’d dig the principle of people messing with what’s already there/adding to/trading online etc, so long as everything stayed ‘op-1’ and no one was hijacking part/all of TE’s work as a basis or element in making new hardware/software for profit etc. I’d imagine it being a ‘good’ thing for Op sales if people were publicly sharing mods etc? Might be worth speaking to TE about it if it someone ends up making a sweet custom OS/additions etc? See how they feel about the idea…
I've no idea on the details/complications around laws concerning the redistribution of intellectual property etc but (unless I'm missing some huge downside?) if I was TE I'd dig the principle of people messing with what's already there/adding to/trading online etc so long as everything stayed 'op-1' and no one was hijacking part/all of their work as a basis or element in making new hardware/software for profit etc. I'd imagine it being a 'good' thing for Op sales if people were publicly sharing mods etc? Might be worth speaking to TE about it if it turns out that anyone digs deep enough for it to be potentially worthwhile sharing a custom OS.. See how they feel about it...
Like some sort of a JJOS situation with Akai. Although JJ took the opportunity to develop the MPC 1/2.5k OS where Akai clearly gave up ages ago. Pretty sure MPC sales did benefit from it, so did JJ and the users obviously.
@lefilou yeah that kind of situation except I guess it would need to be more of a ‘community’ vibe as I’m pretty sure TE wouldn’t be down with people selling stuff whilst TE are still developing/selling OP-1…so there’d have to be some pretty generous dudes out there with a labour of love for the Op OS…
Edit - feel like I’ve slightly derailed the thread, sorry, I’ll bail and leave you tech guys to get on with it
Just so nobody gets their hopes up in this thread: I will not post any complete firmware here as that would contain Teenage Engineerings intellectual property and I would be redistributing it, which is copyright infringement (see cyanogen mod for android).
That’s understood from the get go, @TabascoEye. There’s a lot of necessary research missing anyway, and any custom firmware would of course need its own graphics and code. As I mentioned, there are multiple stops like SDK cost, copyright, or lack of documentation, but I know the DIY community never gives up on researching, this is good stuff you’re posting.
@TabascoEye
Any idea why the unpacked tar has weird permissions set on it (on unix)? I can’t acces them on the same user that extracted the files (permission denied), but as root the permissions look totally normal. Just realized they are stored as a different user in the original tar.
Also did you need to use some special way to repackage the tar? I’m not getting the same file size when comparing my tar and the original tar
Edit: got the same size with no compression, but the contents look totally different in a hex editor 
I see that at least the file owner and/or permissions are different ofcourse in the new tar. It works on my desktop fine though. Wondering if it’ll work in the OP…There’s no reason why we couldn’t create and distribute updated SVG files for the OS as long as it wasn’t using any of the original graphics.
You’d have to post (idiot proof) guidelines on how to extract these SVG’s though. That’d be awesome - so that us who are more artistically minded than tech minded can get to work
I just love what’s going on here.
1 Like
I wanna draw my own styles too! And everyone can upload his new designs and at the same time choose a new image for his OP-1!
@wavi yes normally, the user permissions need execute to change into a directory in Linux. I guess the OP-1 OS in combination with yaffs2 doesn’t care about that. And also ownership doesn’t matter.
I changed the owner on all directories to myself and changed all permissions to 755 so I could easily navigate.
Also, that doesn’t matter to the OP-1 when repackaging. It doesn’t care about any of that ;o)
As for the compression: there are 10 compression levels (0…9) and I don’t know which one TE uses for the original FW. But it also doesn’t matter since the decompression on the OP-1 knows (probably) all of them.
The comand I use to recompress the FW is:
tar cf - content/ OP1_vdk.ldr te-boot.ldr | xz --format=lzma -C crc32 > op1_14203.op1
Then you need the crc:
crc32 op1_14203.op1
And you need to pre-prend the CRC in reverse order (Little Endian). I use “hexer” manually for that but in a script you’d probably use dd or something.
As for the fear of bricking the OP-1: I think as long as you leave the boot loader alone, there is little chance of actaully breaking it beyond repair, so you can always hit the COM button during boot and format the drive, download another FW and re-try.
I’ll add all those commands and the first steps into another post here later as a step-by-step instruction.
In the long run, we’ll probably need some space to share the SVGs and .dbs…
can all just use dropbox or something to host our individual designs and just create a thread on here where we can post preview shots of screens etc.
would LOVE to be able to create custom screens for the OP1!
please share the wisdom!
(but share it in idiot-proof instructions)
(but share it in idiot-proof instructions)
What I don’t get is, why isn’t the firmware open source when TE themselves are using several open source programmer languages ? Or is this something different ?
Thanks man! I’m blessed with that info! I’ve been very nervous about bricking my OP with this. Good thing that it doesn’t care about the compression algos etc. I was initially trying to make sure I get everything right by getting the exact bit-to-bit copy from the original firmware. Won’t bother now
I’m writing a Python tool that does all the work for me. It already does the entire unpack/repack thing, but I haven’t added the CRC yet. I’ll do that next and see how my OP likes it. Did you get any of the error messages like “Decode failed, aborting!” or “No firmware found” at any point when doing this?
I’m writing a Python tool that does all the work for me. It already does the entire unpack/repack thing, but I haven’t added the CRC yet. I’ll do that next and see how my OP likes it. Did you get any of the error messages like “Decode failed, aborting!” or “No firmware found” at any point when doing this?
Edit: also what about creating a GitHub organization/repo for this?
@wavi no, I mis-typed the CRC one time and that’s exactly what the OP-1 update told me “CRC wrong” or something.
So I would call it pretty safe. But hey. No gurantees :o)
@wavi I’m thinking about a Tool in Java to decompress and recompress the FW. That way it could run on Win/Linux/MacOS…
I guess python works on all of them too if you do it right. Would be a good start. github?