Magic Lantern by Tramm Hudson getting close
 

"Wizard" Tramm Hudson posted update on status tonight. He's working on "err70 problems that I've read about were mirror problems or CF issues. This is definitely software..."

He goes on to say:

"It's my major project for the weekend. This is the last major hurdle before a public release of the Magic Lantern firmware since the other big-ticket items have been knocked out:
* AGC disabled
* Selectable gains and filters
* Onscreen meters
* Zebra stripes
* Button remapping
* Audio monitoring on A/V jack
* Framework for new extensions"

What an amazing job--.

A lot of stuff covered already... wow do we owe you a lot man...

Sounds really AWESOME!!!

And last night I stumbled on the left/right audio levels in the DIGIC IV rather than the mono one, so it now has dual audio meters. I'm still not happy with the ballistics and the sampling time for the meters, but we'll get to that eventually.

I might have also found a work-around for the err70 problem. Writing 32-bit word at a time and writing monotonic addresses in the lvram rather than randomly jumping around seems to prevent it from showing up. I have re-written the meter drawing code to do a scanline at a time, and the printf() code to write the font by entire words rather than pixels. Since making that change I have not had any err70 aborts.

The other major fix that needs to happen is to detect when the camera is displaying menus. Right now it overwrites the entire screen with the zebras, which prevents Canon's menus from being displayed.

Bravo Tramm
 

Your commitment and motivation to making this fine camera even better is
a treat to behold. As a token of the masses of us that are indebted to you for
your abilities....is there any way we can return the favor? Maybe voluntary
monetary contributions to you or your favorite charity or...?
This expenditure of creative positive energy on your part deserves to be acknowledged
and rewarded in some manner.

I agree. Tramm, your commitment to the firmware is incredible. Let us know if you are taking donations, etc.

I'll ask Tramm if he can set up a PayPal donation page that references DV Info Net. Thanks for the suggestion,

Nice! I wonder if Tramm single handedly will put a fire under Canon once again for yet another firmware update. :) Man, give us an inch.....

Yeah, the sampling time needs to be much longer. Ideally, you'd be able to fade the edges of the sampling window, but that's probably not possible. With my 500 Hz tone calibration tests, the meters are highly inconsistent, I assume because it catches the tone at various phases.

Paypal link
 

Thanks to everyone who has offered donations. The software will be free when it is released next week and if you want to donate to help with the development, I've setup a dvinfo PayPal donation link: https://www.paypal.com/cgi-bin/websc...ton_id=6273230

I'm also looking for used film-making equipment. Send me an email if you have an older Steadicam, rails systems, matte box or lenses that you aren't using anymore.

The full source will also be released under the GPL so another way that some folks will be able to help is by writing new software to run on everyone's cameras. While it isn't directly based on CHDK, I've benefited from their GPLed sources and the hard work that they did in reverse engineering Canon's P&S cameras. Without their initial effort, I would not have been able to make such rapid progress on the 5D Mark II.

Thanks Tramm! I've copied your post and made it a "sticky" at the top of the forum:

http://www.dvinfo.net/conf/canon-eos...tion-link.html

Thanks Tramm
 

And as one of the iniital contributors to the cause I just want to say thanks!

source location
 

Tramm,

Thank you for your efforts. Where will you be posting the code? Can you say a few words about the development environment?

Regards,

Marc Fairorth
Austin, TX

I know there are at least a few of us out there checking various forums everyday waiting to hear about the firmware getting released. WE do really appreciate it, and I hope when that happens at least a few people out there will give you an IMDB credit for the work you've done!

Now the moment 24p is announced... the internet will go crazy.

There will be a public wiki for documentation, development and source distribution. It's not ready to go live yet, but I'm hoping after Jon's tests this weekend the firmware will be ready for wider distribution. I'll announce it here as soon as it looks stable enough for beta users to start playing with it.
It is very similar to CHDK's requirements: an arm-elf-gcc cross compile setup and some perl scripts. I do the hacking on my Linux desktop box and my OS X laptop ("sudo port install arm-elf-gcc" was all it required).

There are only a few lines of assembly in the entire code tree. I've made an effort to jump into C code as quickly as possible to lower the barrier to entry for other coders. I have also avoided copying any Canon code into my firmware so that it can be distributed without any encumberances. I have, however, written headers based on my reverse engineered firmware so that it is possible to create DryOS tasks, interact with some of the system structures and devices, and call into functions in the ROM image.

The Magic Lantern firmware is structured as a set of loosely coupled .c files. They add entry points to a ELF segment to indicate which tasks to startup at boot time once the grungy bits are done, simply by virtue of being linked into the image. This allows new functions to be added just by adding the .o file to the list of object files in the Makefile.

Jon's tests are going great, but one of the alpha users reported a fairly major bug: the digital zoom in live view gets "stuck" and it doesn't return to full screen mode. I'm working on that one now, which is the last hurdle before public availability.

I promise!

Take whatever time you need to get it right...

Tramm or Jon:

In first release are we getting any way to monitor other than LCD ? I assume, as previously indicated, we are losing Video when we get phones monitoring through AV jack.

Hi Chris,

Tramm will have to answer that. I'm just doing audio testing. I do a quick test and immediately pull the battery to remove the firmware and any possible infinite loops that could heat up the chips. That way, Tramm can send me his very latest builds with various audio tweaks without doing delivery-level testing.

But, yeah, hopefully we won't lose any features when we add the new ones...

Unfortunately, no. By disabling the hotplug task, the camera no longer responds to HDMI cables, USB cables or A/V cables. Many users have reported significant noise on the audio track when using the composite video output with the stock firmware as well, which might steer you away from trying to use it.

This is, after all, still a first beta release. HDMI support may be implemented once someone with a HDMI monitor has a need to write the code necessary to switch the camera into HDMI output mode. I don't have an HDMI field monitor, so it hasn't been a huge priority...

Yikes! Just a personal response here, but that kind of prohibits my use of the software.
My 5D is primarily used on a Glidecam X-10 rig. Monitoring video is this configuration is
more important than audio for obvious reasons. The size and placement of the camera lcd make it somewhat useless for a stabilization rig. Its a bummer that there is this either or situation. Regardless, I do appreciate the added capabilities you have created for the camera!

I fully anticipate fixing that soon after the initial release. Since you're using an HDMI monitoring, you'll be a great beta tester for that code. If I had a Steadicam and a field monitor, it would be one of the first additions that I'd make!

It looks pretty easy to switch between the different modes; set a global variable in the hdmi_config_state structure, call the refresh_video_state() function and, I hope, it all works. That is what the hotplug_task() code does; we should be able to make the same sequence of calls to force it. But I don't have any way to test it, so it won't be in the first release, and all of my gui elements are hard coded for the 720x480 LCD.

Likewise, I'm not supporting use of the internal mic. My code forcibly selects the external input regardless of if it is connected. This won't work for everyone, but we're still in a early beta state and hopefully anyone who cares about audio quality will be using an external mic.

Field Monitor
 

FYI this is the monitor I will be use with the 5D stabilized rig (when its available in about a month)
SmallHD.com - 8.9" High Definition - the DP1

Love to help
 

[QUOTE=Tramm Hudson;1161602]I fully anticipate fixing that soon after the initial release. Since you're using an HDMI monitoring, you'll be a great beta tester for that code. If I had a Steadicam and a field monitor, it would be one of the first additions that I'd make!

I'd love to help, just as soon as I can purchase one from smallHD.

Very neat. The only thing that seems to be missing is a headphone amp. If we could get HDMI audio output to the monitor and use it for audio monitoring that would be one less cable to connect to the camera.

The other major hurdle for HDMI output is to fix the mode switch when recording starts so that it doesn't blank out for a few seconds while the screen resyncs. I haven't seen any reason that it happens.

Continued Optimism
 

Whew! Im glad there are possibilltes regarding video output. I will continue to be optimistic
and assist any way I can.

You will need to have an external monitor in a lot of setups. A Glidecam or Steadicam is just one of them. Video output is more than secondary.