Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Magic Lantern Is Back

magiclantern.fm

Post reply on HN
Print view View original

51–60 of 170 posts

Re: Magic Lantern Is Back

#51

Post by names_r_hard »

GranPC wrote: post #48
names_r_hard wrote: post #29

Thanks to all who are sharing their appreciation for this niche but cool project. I'm the current lead dev, so please ask questions. Got a Canon DSLR or mirrorless and like a bit of software reverse engineering? Consider joining in; it's quite an approachable hardware target. No code obfuscation, just classic reversing. You can pick up a well supported cam for a little less than $100. Cams range from ARMv5te up to AA…

What's the situation re: running on actual hardware these days? I was experimenting around with my 4000D but when it came to trying to actually run my code on the camera rather than the emulator, a1ex told me I needed some sort of key or similar. He told me he'd sign it for me or something but he got busy and I never heard back. Is this situation still the same? (Apologies for the hazy details -- this was 5 years ago…

That must have been a few years back. I think you're talking about enabling "camera bootflag". We provide an automated way to do this for new installs on release builds, but don't like to make this too easy before we have stable builds ready. People do the weirdest stuff, including trying to flash firmware that's not for their cam, in order to run an ML build for that different cam...

Anyway, I can happily talk you through how to do it. Our discord is probably easiest, or you can ask on the forum. Discord is linked from the forum: https://www.magiclantern.fm/forum/

Whatever code you had back then won't build without some updates. 4000D is a good target for ML, lots of features that could be added.

Re: Magic Lantern Is Back

#53

Post by GranPC »

names_r_hard wrote: post #51
GranPC wrote: post #48

Earlier quoted context omitted.

What's the situation re: running on actual hardware these days? I was experimenting around with my 4000D but when it came to trying to actually run my code on the camera rather than the emulator, a1ex told me I needed some sort of key or similar. He told me he'd sign it for me or something but he got busy and I never heard back. Is this situation still the same? (Apologies for the hazy details -- this was 5 years ago…

That must have been a few years back. I think you're talking about enabling "camera bootflag". We provide an automated way to do this for new installs on release builds, but don't like to make this too easy before we have stable builds ready. People do the weirdest stuff, including trying to flash firmware that's not for their cam, in order to run an ML build for that different cam... Anyway, I can happily talk you t…

Yes, this was in September 2020 according to my records. All I remember is that I could run the ROM dumper just fine, then I could run my firmware in QEMU, and then I just had to locate a bunch of function pointers to make it do anything useful. Worked in QEMU but that's where I got stuck - no way to run it on hardware.

I'll definitely keep this in mind and hit you up whenever I have a buncha hours to spare. :)

Re: Magic Lantern Is Back

#55

Post by hypercube33 »

joatmon-snoo wrote: post #9

For folks who don't know what Magic Lantern is: > Magic Lantern is a free software add-on that runs from the SD/CF card and adds a host of new features to Canon EOS cameras that weren't included from the factory by Canon. It also backports new features to old Canon cameras that aren't supported anymore, and is generally just a really impressive feat of both (1) reverse engineering and (2) keeping old hardware relevan…

it also has a scripting system and is damn fun to mess with.

Re: Magic Lantern Is Back

#56

Post by ASlave2Gravity »

names_r_hard wrote: post #29

Thanks to all who are sharing their appreciation for this niche but cool project. I'm the current lead dev, so please ask questions. Got a Canon DSLR or mirrorless and like a bit of software reverse engineering? Consider joining in; it's quite an approachable hardware target. No code obfuscation, just classic reversing. You can pick up a well supported cam for a little less than $100. Cams range from ARMv5te up to AA…

Hey just want to say a massive thank you for everything you've done with this project. I've shot so much (short films, music videos, even a TV pilot!) on my pair of 600Ds and ML has given these cams such an extended life.

It’s been a huge blessing!

Re: Magic Lantern Is Back

#58

Post by can16358p »

andy_ppp wrote: post #28

Would love it if camera manufacturers were forced to open source their firmware after say 5 years of a camera’s release. The longevity of devices would be vastly improved. In fact make this all devices with firmware, printers, streamers etc.

I don't think forcing a company to open source their IP is a good move, but perhaps there might be some encouragement implemented for opening up their bootloader so the device is more hackable.

But forcing is never a right thing.

Re: Magic Lantern Is Back

#59

Post by ptero »

Etheryte wrote: post #50
names_r_hard wrote: post #43

Earlier quoted context omitted.

I stand by my statement! Compare the length of the C standard to JS / ECMAScript, or C++! :) Maaaaybe I'm hiding a tradeoff around complexity vs built-in features, but volunteers can work that out themselves later on. You honestly don't need much knowledge of C to get started in some areas. The ML GUI is easy to modify if you stay within the lines. Other areas, e.g., porting a complex feature to a new camera, are muc…

Conversely, the terseness of the C standard also means there's many more footguns and undefined behaviors. There are many things C is, but being easy to pick up is not one of them. I loved C all the way up until I graduated uni, but it would be a very hard sell to get me to pick it for a project these days. To me, working with C is akin to working with assembly, you just feel that you're doing real programming, but r…

Undefined behaviors -- yes. But being able to trigger undefined behavior is not a huge foot gun by itself. Starting with good code examples means you are much less likely to trigger it.

Having a good, logical description of supported features, with a warning that if you do unsupported stuff things may break, is much more important than trying to define every possible action in a predictable way.

The latter approach often leads to explosion of spec volume and gives way more opportunities for writing bad code: predictable in execution, but instead with problems in design and logic which are harder to understand, maintain and fix. My 2c.

Post reply on HN