Eos 400d ( Rebel XTI )

guffster

There are some really nice changes coming to 400plus in the most recent and upcoming nightly builds. If you have not tried a recent 400plus nightly build then you might want to give one a shot (or two or three)... Many issues have been and are being addressed and resolved!

Thank you to all the developers, testers, bug/issue enhancement reporters, and others who have contributed a lot of time and energy to make these changes and document them all! Nice job.

kuilrega

Hi

I cannot disable the double flashing with 400plus. Is it supposed be possible or not?
I want to synchonize with an external flash, it is too slow to detect the double flash so I have to lift the mirror in advance. Better it would be to get only one flash.

eduperez

kuilrega
Hi

I cannot disable the double flashing with 400plus. Is it supposed be possible or not?
I want to synchonize with an external flash, it is too slow to detect the double flash so I have to lift the mirror in advance. Better it would be to get only one flash.

That's the TTL pre-flash, and you cannot disable it; you need a slave flash prepared to fire on the second shot only.

kuilrega

Ok thanks, good to know.
My slave is too slow to detect it. It detects it only if I lift mirror first (with first flash), half a second or so ... 🙁

eduperez

kuilrega
Ok thanks, good to know.
My slave is too slow to detect it. It detects it only if I lift mirror first (with first flash), half a second or so ... 🙁

I would guess that your slave does detect both flashes, but when the second one is too close to the first one, it does not have enough time to recharge and simply has to ignore it; prepared slaves do not fire at all during the first flash, and simply wait for the second one.

kuilrega

eduperez
it does not have enough time to recharge

No it doesn't fire at the first flash, nevertheless it detects the second one only when slow enough. Really bad.

... It works with flash on second curtain and 1/25 s

edmundronald

Is there any way to get Lua or uBasic user scripting working on the 400D?
Do these work on any dSLR?

Edmund

eduperez

edmundronald
Is there any way to get Lua or uBasic user scripting working on the 400D?
Do these work on any dSLR?

Edmund

Each DSLR has its own hack: for the 400d we have 400plus, and many other cameras share MagicLantern; right now, there is no support for user scripting in 400plus.

Gigaah

Hi. Myself and other fellow photographers locally and random inquiries I see across posts from CHDK and MagicLantern have a solid interest in getting some sort of alternate firmware and features on our 1000D's.

Some initial work was done by Coutts and Others seems to have been kinda of set in place and left for someone else.
Here are links to the stuff that was finished
https://bitbucket.org/coutts/1000d_dev/commits
https://bitbucket.org/coutts/1000d_dev/src/a7835d17602f?at=default
https://bitbucket.org/coutts/1000d_dev/src/a7835d17602fe2de51fda54d372f48ede290858e/engelmarkus_examples?at=default

It looks like Coutts initially was working towards porting 400plus to the 1000D and infact initially ported a bunch of init functions before reverting back to basic and labeling the work done as "ready to be ported to magic lantern".

I'm seriously not a great programmer. Can anyone give me an idea of how much work needs to be done to get 400plus or ANY mannor of alt firmware with extended functions done?

I'd give it a shot but I don't know where to start and it could very easily be way beyond my expertise.

Any help is appreciated. Its a shame all that work has gone dormant with nobody to work on it.

eduperez

Gigaah
Hi. Myself and other fellow photographers locally and random inquiries I see across posts from CHDK and MagicLantern have a solid interest in getting some sort of alternate firmware and features on our 1000D's.

Some initial work was done by Coutts and Others seems to have been kinda of set in place and left for someone else.
Here are links to the stuff that was finished
https://bitbucket.org/coutts/1000d_dev/commits
https://bitbucket.org/coutts/1000d_dev/src/a7835d17602f?at=default
https://bitbucket.org/coutts/1000d_dev/src/a7835d17602fe2de51fda54d372f48ede290858e/engelmarkus_examples?at=default

It looks like Coutts initially was working towards porting 400plus to the 1000D and infact initially ported a bunch of init functions before reverting back to basic and labeling the work done as "ready to be ported to magic lantern".

I'm seriously not a great programmer. Can anyone give me an idea of how much work needs to be done to get 400plus or ANY mannor of alt firmware with extended functions done?

I'd give it a shot but I don't know where to start and it could very easily be way beyond my expertise.

Any help is appreciated. Its a shame all that work has gone dormant with nobody to work on it.

Programming is not the hard part, but reverse-engineering: coding features is relatively easy for anyone with some background in programming, and there is lots of information and resources about it... that is, provided you know how to talk to the camera, and obviously there is no documentation about how to talk to the camera. You need to get a firmware dump, decompile it, start digging around the code to find function calls, guess what they do, ...

There was some relatively recent activity at the ML forum:
http://www.magiclantern.fm/forum/index.php?topic=2054.0

And there is a board dedicated to reverse-engineering:
http://www.magiclantern.fm/forum/index.php?board=6.0

Hope this helps...

eduperez

It's been almost a year since the last major release was announced, and we think it is time for a new one. We have a long list of new features and enhancements ready, and probably a long list of new bugs, too... this time, I'd like to open a period of "BETA releases" before the next major release.

There is still some polishing needed, but these beta releases are feature complete, and completely usable, in my humble opinion; besides, I am convinced we need more testers before announcing a new release.

As always, this is the result of the collective work of lots of people who contributed with code, ideas, bug reports, documentation... Many thanks to everybody!

Beta releases can be downloaded from here:
* http://code.google.com/p/400plus/downloads/list?q=label%3ABeta

There is an updated user guide at:
* http://code.google.com/p/400plus/wiki/UserGuidePreview

And this is the list of new features and enhancements:

* General enhancements:
- Faster initialization.
- Added a method to disable 400plus during boot-up.
- Added some info to the main display.
- Relax Av limits when a manual lens is attached to the camera.
- New menu entry to restore settings to its default values.

* "Presets" have been renamed to "custom modes":
- All "scene modes" can now be configured into a "custom mode".
- Up to sixteen "custom modes" can be saved.
- The A-DEP mode is no longer special.

* Scripts:
- New "bulb ramping" script.
- New "exposure bracketing" script.
- Improved the long-exposure script and calculator.
- When available, use lens' focal length for the DOF calculator.
- Scripts now honor camera's MLU and self-timer options honored.
- Added an option to switch the review off during a script.

* Misc functions:
- Multi-spot metering.
- Quick exposure for M mode.
- Named custom temperatures.
- Use the burst count to display ISO in the viewfinder while in P and Av modes.

* AutoISO:
- New AutoISO algorithm for Tv mode: "Av max" is now relative to max aperture supported by the lens.
- New AutoISO algorithm for M mode: use only real ISOs, and respect min / max limits.
- Configurable sensitivity for AutoISO in M mode.
- Added an option to make AEB persistent.
- Added an option to revert D-Pad to its original function.
- Configurable intermediate ISO step.

* Usability enhancements to menus:
- Added an option to disable warp menus.
- Added an option to make main menu navigable.
- Added an option to enter directly to the main menu.
- Enter menu to last active page after a powercycle
- Use ZOOM IN / OUT as PAGE UP / DOWN buttons.

* Shortcut buttons:
- Enhanced quick-AEB action.
- New action: toggle flash.

Edu.

repeater

I honestly thought that the work on this project had stopped. TBH, I am more than happy with what you guys have already built but I am blown away to see you adding even more functionality! Thanks for the hard work - it really is appreciated.

Personally, I am looking forward to trying these out...

'- All "scene modes" can now be configured into a "custom mode".'
'- Up to sixteen "custom modes" can be saved.'
'- New "bulb ramping" script.'
'- New "exposure bracketing" script.'
'- Named custom temperatures.'

Needless to say, I will be updating when I get home from work tonight - I appreciate this is a beta so will make sure I feedback any issues. Thanks again to all involved!

teemo

I was impatient and compiled a week ago from the nightly source.
I can only say: This is 400Plus reborn. It is like getting a new camera.

Many many thanks to Edu and everyone helping. They (he) have been busy for a long time, cleaning, updating and adding features to the code.

My favourite: With one simple turn on the dial you can change all settings. No more messing with menus when changing settings.
Second favorite: Change AEB up to six steps without entering the menu system - just push a button a few times.

Awesome!

eduperez

There has been a very interesting conversation between Serguei and 0xAF about the VRAM and other subjects; it started as private messages, but we agree that it is too interesting and must be shared, so I am going to dump it here in separate messages.

eduperez

Sergei wrote:
Hi eduperez, 0xAF !
I have being working on VRAM last couple of weeks. I was trying to stop flicker, but don't have any luck to find a function which writes into the vram. Maybe you have any idea?
Here my code, look in display.c VramModTask().https://lh.rs/ycJ2bZHHEwRy

Thanks for your help.

eduperez

eduperez wrote:

Sergei wrote:
Hi eduperez, 0xAF !
I have being working on VRAM last couple of weeks. I was trying to stop flicker, but don't have any luck to find a function which writes into the vram. Maybe you have any idea?
Here my code, look in display.c VramModTask().https://lh.rs/ycJ2bZHHEwRy

Thanks for your help.

Hi Sergei! Glad to know about you again!

After 0xAF ported all the code to write to VRAM, we also began to work with the display. We've managed to make it almost flicker-free: it only flicks when the exposure needle flashes (because there is over/under exposure); but, when that happens, we lose the overlay completely until the user half-presses the shutter button again. Really annoying.

All I know is already committed into our repository: what we are doing now is to refresh the overlay when we detect certain events (GUI_START_OLC_MOD in GUI_IDLEHandler and IC_MEASURING[0x80] or IC_MEASUREMENT[0x81] in the intercom proxy), and then refreshing it again after a small delay.

I have the impression (and please, take this with a grain of salt) that there is some "idle state" related to the display, and when it enters into that state, then it does not refresh, no matter what we do.

I'll have a look to your code right now, this is one of my current priorities; let's try to find a solution together!

Many thanks!
Edu.

eduperez

0xAF wrote:

eduperez wrote:

Sergei wrote:
Hi eduperez, 0xAF !
I have being working on VRAM last couple of weeks. I was trying to stop flicker, but don't have any luck to find a function which writes into the vram. Maybe you have any idea?
Here my code, look in display.c VramModTask().https://lh.rs/ycJ2bZHHEwRy

Thanks for your help.

Hi Sergei! Glad to know about you again!

After 0xAF ported all the code to write to VRAM, we also began to work with the display. We've managed to make it almost flicker-free: it only flicks when the exposure needle flashes (because there is over/under exposure); but, when that happens, we lose the overlay completely until the user half-presses the shutter button again. Really annoying.

All I know is already committed into our repository: what we are doing now is to refresh the overlay when we detect certain events (GUI_START_OLC_MOD in GUI_IDLEHandler and IC_MEASURING[0x80] or IC_MEASUREMENT[0x81] in the intercom proxy), and then refreshing it again after a small delay.

I have the impression (and please, take this with a grain of salt) that there is some "idle state" related to the display, and when it enters into that state, then it does not refresh, no matter what we do.

I'll have a look to your code right now, this is one of my current priorities; let's try to find a solution together!

Many thanks!
Edu.

Hi Guys,
I've been away from the camera hacking for long now, though i remember many things and eventually will try to implement some of the ideas I still have.

What I know from Alex about the display refreshes is that they (ML) found a way to block them.
There are some events that will force display to refresh, Edu, you're right, the display can stay in idle state until some events (messages) are received.

We have our code wrapped around the Intercom task mostly, hence our intercom proxy.
It seems our camera is the only one (may be there are few more cameras, namely 30d, 450d and 1000d i think) that have intercom. All other cameras are using the so called properties system, which i'm not so familiar with.
The properties are basically what we have in DPR Data (Digital PRoperties Data). But somehow they can be used to traverse messages and commands. So it's not so different after all.

The ML guys have worked their way around the GUI Task (not the intercom task, like we are), so Alex told me that in GUI task they can block some events (namely, DISPLAY_REFRESH).

So my idea was to reverse the GUI task (somewhere it is called: GUI Idle) and then we can block the original display refresh if we need to. That's what I know about it.
If somehow in our intercom task we can see these events we can block them there I guess.

Unfortunately so far (the last 2 years) I have very little time to work on hobby projects 🙁 which is very sad, since I'm missing the camera hacking so much.
If I can help somewhere, please do not hesitate to ask. I will gladly help (at least with knowledge I have).

Be cool.

eduperez

Sergei wrote:

eduperez wrote:
All I know is already committed into our repository: what we are doing now is to refresh the overlay when we detect certain events (GUI_START_OLC_MOD in GUI_IDLEHandler and IC_MEASURING[0x80] or IC_MEASUREMENT[0x81] in the intercom proxy), and then refreshing it again after a small delay.

I did it little different way. I start a new task right before "START_OLC_MODE" which writes overlay to vram plus sets one pixel at a corner of the screen. Then it checks for set pixel to be the same, if not it rewrites overlay again.
Still flickers time to time. That's why i want to find what writes into vram address and see if it is anyway to control it.
I tried to stop blink timer in OLC by setting hBlinkTimer (*(int*)0x47F4) to 0. It makes OLC stop flashing Tv or Av values on the screen but something else still rewrites overlay.

eduperez

Sergei wrote:
Looks like I successfully locked vram. OLC can't change anything on screen after lock, but direct write to vram still works .

DEF(TakeVramSemaphore, 0xFF92E41C) //
DEF(GiveSemaphore__, 0xFF92E46😎 // goes in funclist.txt

#define VramInstance_address *(int*)0x5190

TakeVramSemaphore(VramInstance_address); // takes vram semaphore so other tasks have to wait for it to free before thay can write to vram
SleepTask(2000);
bmp_printf(50, 134, "test", COLOR_BLACK, COLOR_GRAY); //writes directly to vram
SleepTask(7000);
GiveSemaphore__(VramInstance_address); //releases the semaphore

Not exactly what I needed but it can be used for custom windows on OLC screen or maybe to hide menu screen when firmware goes into 400plus menu.

eduperez

Sergei wrote:
Well, firmware waits for semaphore to free before it starts menu, so I guess it's no way to hide the menu screen.

« Previous Page Next Page »