Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - kitor

A very RAW update, February 2024!
Current state of Magic Lantern project (updated February 2024)

New update, October 2023!
Another mini-update.
Current state of Magic Lantern project (updated October 2023)

New update, July 2023!
This time just a quarterly mini update, so requires you to read April update for the context.
Current state of Magic Lantern project (updated July 2023)


This is a relatively short summary about what is going on with the project in last years. This thread started as an update on development for "new era" models - this includes cameras based on DIGIC 6, 6+, 7, 8 and DIGIC X processors. But with recent exciting news for older models we decided we owe you a full update  :)

We will try to keep this post written in layman's words - providing just links to more in-depth readings where suitable.

Credits to @theBilalFakhouri, @names_are_hard and @Walter Schulz for their help in preparing this write up.

For your reading convenience, thread is split into chapters, each of which is a separate post:

Chapter 1: What is Magic Lantern? Who is responsible for it?
Chapter 2: Developments in already supported generations (DIGIC 3, 4, 4+)
Chapter 3: DIGIC 5 and 5+: Exciting updates: SD overclocking, Full resolution LV preview
Chapter 4: What is going on with new models? All supported cameras are 10 years old!
Chapter 5: So what is the status of newer models? (DIGIC 6, 6+, 7, 8, X)
Chapter 6: I noticed PowerShots on the list? Do you want to steal CHDK user base?!
Chapter 7: What can I expect from you? How can I help?

... there's Basic interpreter on Digic 6 and 7 models too! (checked on 750D, 5D4, 200D). It works differently than D8+, so I'm creating a separate thread.

There's no need for script.req file on card, or any bootsector flags.

I found no way to execute script without UART. With UART:

' Comment test, will this be ignored?

public sub my_test(string)
    ' moar comments
    Printf("\nyo man!\n")
end sub

K393[1]>LoadScript B:/test.m
Load B:/test.m
LoadScript returned 0(0x0)
Show Script
                          Name:     Code: CodeSize:     Data: DataSize:
                      B:/test.m  0x9ac3cc      0x28  0x9ac400      0x14
ShowScript returned 0(0x0)
yo man!

my_test returned 0(0x0)

Quirks: I found no way to auto execute any function from script. All public subroutines get exported into Evprocs.
If subroutine doesn't have any arguments, parser complains:
K393[1]>LoadScript B:/test.m
Load B:/test.m
Syntax Error:Invalid Parameter Name
3:private sub my_test()

LoadScript returned 1(0x1)

Thanks to Lorenzo for pointing me into that direction. He claimed that there may be Basic engine on 6D, unfortunately this is not yet confirmed/busted. on D5 is something with different syntax.
Reverse Engineering / EDMAC in Digic 7 / 8 world
September 25, 2021, 01:23:08 PM
Some time ago I identified configuration-like structures related to EDMAC (asserts Engine:Edmac.c, Engine::BoomerVdKick.c).
There were a ton of asserts with structure details in the code.

Not me, nor @names_are_hard were able to find any similarities to how EDMAC functions worked in Digic 4 / 5 cameras. I decided it is worth to decode structures above.

Some details about structures found in R.180 ROM:

0xE0DD5C64 DmacInfo, 76 entries
  Entry structure:
    EDMAC_Channel * ptr;               # Pointer to memory in 0xD04xxxxx region
    uint32t ModeInfo;                  # see ChannelFlags

0xE0DD641C InterruptHandlers, 76 entries
  Entry structure:
      void * pISR;                     # Pointer to ISRs
      uint32_t ID;                     # Can be mapped to IVT entries from the wiki


0xe0dd5b34 PackUnpackId, 76 entries
  Entry structure:
      uint32_t UnpackID;               # Maps DmacInfo ID into PackUnpackInfo ID


0xe0dd5ec4 PackUnpackInfo, 38 entries
      void * ptr;
      uint32_t unk_1;
      uint32_t PackUnpackInfo;         # see PackUnpackModeFlags

0xe0dd608c DmacBoomerInfo, 76 entries
  Entry structure:
      uint32_t BoomerID;               # BoomerId >> 0x10 is ID used in Boomer* structures below
      uint32_t BoomerInSelType;        # Name may be wrong. Masked with 0x0000FF00 to get InSelType
      uint32_t BomerInSelEdmacType;    # Masked with 0xFFFF0000 to get AssertInfo


0xe0f73510 BoomerVdKickInfo, 265 entries
  Entry structure:
      uint32_t VdType:                 # 0x1 for E_BOOMER_VD_KICK, 0x2 for <unnamed>
      void * ptr1;                     # Pointer to memory in 0xD04xxxxx region. Non-zero only in E_BOOMER_VD_KICK entries
      void * ptr2;                     # Pointer to memory in 0xD04xxxxx region

BoomerVdKickInfo has 225 entries of VdType E_BOOMER_VD_KICK, rest are for type 0x2

0xe0f72e08 BoomerSelector1, 225 entries # Name not found in asserts
  Entry structure:
      void * ptr;                       # Pointer to memory in 0xD04xxxxx region
0xe0f7318c BoomerInputPort, 225 entries # Name not found in asserts, named after only field in entry (InputPort)
  Entry structure:
      void * ptr;                       # Pointer to memory in 0xD04xxxxx region

I identified following flag bit numbers from debug prints. Not all names are known, only known ones are listed below

ChannelFlags = {
    0x0  : "INFO_DMAC_TYPE_WRITE",
    0x1  : "INFO_DMAC_TYPE_READ",
    0x2  : "INFO_DMAC_SS",
    0x7  : "INFO_DMAC_DANCING",
    0x8  : "INFO_128BIT_MODE",
    0x9  : "INFO_64BIT_MODE",
    0xA  : "INFO_32BIT_MODE",
    0xB  : "INFO_DIV_MODE",
    0xC  : "INFO_XSYS_DIV_MODE",
    0x10 : "INFO_OPTI_MODE",
    0x11 : "INFO_VITON_MODE",

32 bit number, but i saw only two options in the wild.


Channels usually have 0, first or both set. If no mode is set (0),  PackUnpackInfo pointer and unknown value are set to 0.


0xe05378d7 EDMAC_ReadISR
0xe0537991 EDMAC_WriteISR
0xe0535c4c EDMAC_UnknownISR # doesn't seem to be used

There are a few more structures that I wasn't able to get direct relation to channel IDs. Those are related to Boomer and EdmacChaser

Up to not-so-long-ago everybody* thought that Digic 6+ cameras render GUI in YUV. In 80D thread, @a1ex documented MARV structures that referenced two UYVY VRAM surfaces. More of that in Chapter 0.

In last December @coon noticed that EOS RP seems to have RGBA VRAMs. This got somehow unnoticed, and he was unable to mess with them anyway.

About a month ago, after I tried to make GUI rendering work on R in YUV and failed successfully. I thought "There's no way that Canon renders GUI in YUV". The next day I found the same RGBA layers that coon noticed, with whole infrastructure related to that. This is Chapter 2 and Chapter 3.

@names_are_hard started looking into his 200D ROM and found some similar things to R/RP. It was lacking a lot of stuff, but he was able to locate one RGBA layer. I bought 200D to investigate this, and... this goes into Chapter 1

Finally @names_are_hard made a nice compatibility layer for existing indexed RGB code and I integrated compositor support PoC for EOSR. For TL;DR see Chapter 5.1

*Future me: See Chapter 6 :)
Not sure if this should go here or into general chat, since it's not camera and ML related.

Recently I got old EF 20-35 3.5-4.5 USM lens. Pretty good external and internal condition, focuses fast, shoots OK, but...
Shoots OK only wide open. Trying to shoot with lower aperture ends in err01 both on R and 5d3.

After some guessing I noticed that lens reacts randomly to aperture changes - this is best noticeable in movie mode where aperture should be kept at selected step all the time.
General rule is that closing from 3.5 in direction of f/29, step after step - it will close two steps, then open by one, then close by a few, then open a few and so on. When camera says it should be f/29, lens is really at about f/16 maybe. Behavior is inconsistent - most of the time it will change aperture in proper direction, sometimes it won't react at all and sometimes goes into opposite than requested.

I disassembled it twice - checked aperture ribbon - seems ok (both visually and using multimetr), disassembled even aperture itself - i can move it in both directions as freely as stepper motor allows me to do.
With each aperture "step" motor is making noises.

I wonder if the problem is in lens controller, ribbon or motor itself. Will use it wide open (as there are no hopes for parts for ~$150 lens, unless someone sells me dropped one with broken glass), but maybe someone had similar problem with any of Canon lenses?
Shot on 5D Classic with 28-135 1:3.5-5.6 IS USM @44mm f/5.6
ISO 800, 2s exposure.
Colors corrected a bit in Lightroom, then exif-based time overlay added using some magic in ImageMagick ( ;) )*
Unfortunately not 4K as Sony Movie Studio 12 can't go above 1080p.

Proves that 5D classic is still capable for this kind of usage  :)

*code if anyone would like to use it:
for f in *.tif; do
date=$(identify -format "%[EXIF:DateTimeOriginal]" $f 2>/dev/null)
echo $date
convert -size 500x56 xc:none -font DejaVu-Sans-Mono-Book -pointsize 44 -gravity southeast \
-stroke black -strokewidth 1 -annotate 0 "$date" \
-stroke none -fill \#999 -annotate 0 "$date" \
$f +swap -geometry +9+9 \
-composite comp/$f

General Development / Digging into audio code
July 23, 2015, 11:41:20 AM
As I had hardware problem with right mic channel in my 5d2 (, I played with source code a bit.
My first thoughts - while audio-lapis.c is using tons of obvious named constants, old "audio-ak.c" is documented very poorly. They have even identical headers, so for "new" person like me it took a while
to understand why they both exist.
Also, audio-ak has different styles of coding mixed, eg function declared in single line:
static inline unsigned mgain_index2gain(int index) // sorted mgain values
while a bit later
static inline uint8_t
                  int                   gain

I found also things like (in void audio_configure( int force ) )
#ifdef CONFIG_500D
    audio_ic_write( AUDIO_IC_SIG4 | pm3[input_source] );
    //PM3 is set according to the input choice
    audio_ic_write( AUDIO_IC_PM3 | pm3[input_source] );

and guess what... AUDIO_IC_SIG4 and AUDIO_IC_PM3 have the same addresses (0x3000), and that's the only one reference of this register I could find in source...
ofc I get it, by registers definition I belive that 500d uses other (yet similar) controller and thus different register names, but i can't find information what controller is used.

As I had to (first understand at all and then) modify audio_configure function, now it looks more like (ofc it's not final form, and only part of function, note comments with what each bit of register does)

//this should be moved to header file

//left channel path is controlled by D0 of AUDIO_IC_PM1
//right channel path is controlled by D0 of AUDIO_IC_PM3
//right channel is defined by D2 of AUDIO_IC_PM3

//left channel is defined by D1 of AUDIO_IC_PM3

//differential on left is
#define ML_MIC_IF_CTL_SINGLE  0x00
#define ML_MIC_IF_CTL_DIFFER  0x10


#define ML_SPK_ENABLE 0x10
#define ML_MIC_POWER_ON 0x04
#define ML_MIC_POWER_OFF 0x00

#define ML_MIXER_MONO_INPUT 0x04

    if( !force )
            // Check for ALC configuration; do nothing if it is
            // already disabled
            if( audio_ic_read( AUDIO_IC_ALC1 ) == gain.alc1
                &&  audio_ic_read( AUDIO_IC_SIG1 ) == gain.sig1
                &&  audio_ic_read( AUDIO_IC_SIG2 ) == gain.sig2
            DebugMsg( DM_AUDIO, 3, "%s: Reseting user settings", __func__ );

    audio_ic_write( AUDIO_IC_PM1 | ML_AUDIO_ENABLE_ADC_DAC | ML_RECORD_PATH_MICL2LCH ); // power up ADC and DAC

#ifdef CONFIG_500D //500d only has internal mono audio :(
    int input_source = 0;
    int mic_pow = 1;
    int input_source = get_input_source();
        //mic_power is forced on if input source is 0 or 1
        int mic_pow = get_mic_power(input_source);
        int mic_pow = 1;
    audio_ic_write( AUDIO_IC_SIG1 | ML_SPK_ENABLE | ( mic_pow ? ML_MIC_POWER_ON : ML_MIC_POWER_OFF )); // power up, no gain
    audio_ic_write( AUDIO_IC_SIG2 | ML_MIXER_MONO_INPUT | ( lovl & 0x3) << 0 // line output level

    //PM1 holds ADC & DAC enable + LR select on L channel
    //PM3 holds INT/EXT select for L and R channels, balanced mode and LR select on R channel
    switch (input_source)
        case 0: //LR internal mic
            audio_ic_write( AUDIO_IC_PM1 | ML_AUDIO_ENABLE_ADC_DAC | ML_RECORD_PATH_MICL2LCH );
        case 1:// L internal R extrenal
            audio_ic_write( AUDIO_IC_PM1 | ML_AUDIO_ENABLE_ADC_DAC | ML_RECORD_PATH_MICL2LCH );
        case 2:// LR external
            audio_ic_write( AUDIO_IC_PM1 | ML_AUDIO_ENABLE_ADC_DAC | ML_RECORD_PATH_MICL2LCH );
        case 3:// L internal R balranced (used for test)
            audio_ic_write( AUDIO_IC_PM3 | ML_MIC_IF_CTL_DIFFER | ML_RECORD_PATH_MICR2RCH); //0x11
            audio_ic_write( AUDIO_IC_PM1 | ML_AUDIO_ENABLE_ADC_DAC | ML_RECORD_PATH_MICL2LCH );
        case 5:// External mono left
            audio_ic_write( AUDIO_IC_PM1 | ML_AUDIO_ENABLE_ADC_DAC | ML_RECORD_PATH_MICL2LCH );
        case 6:// External mono right
            audio_ic_write( AUDIO_IC_PM1 | ML_AUDIO_ENABLE_ADC_DAC | ML_RECORD_PATH_MICR2LCH );

Yep, I added myself two possibilities of external left and right channel mono, but this I want to discuss later :)

What I want to discuss here is cleanup of this code. If that will be approved (it has chances to be included in main repo), i'm thinking about doing following things:
- Move all controller-specific constants from audio.h to audio-ak.h and audio-lapis.h, as they differs due to registers.
- Cleanup audio-ak.c to have one style of coding
- Where possible, replace hardcoded values with constants, like in my example code, that is based on how audio-lapis.c looks (it's much more human-readable this way)
- Add comments about functions of each register used, as at least in ak4646 they are mixed.
- Optional: Add "external mono left" and "external mono right" - they are useful also when you have eg. xlr to stereo jack cable connected to mono microphone, or have y-adapter with two mics each on own channel, and want to select it (already tested by me on 5d2 and works ok)

But of course I need approval so I don't waste my time :), and some suggestions if there are some internal rules of how code should look like.

My 5d2 has broken right channel. It has 100% signal all the time. It's issue between audio controller and digic, as i checked circuit from socket to controller and it's ok.
That creates annoying effects while editing files on pc, and also makes "L:int, R:ext" option useless for me.

I looked into source code, in audio-lapis.c there's function audio_ic_set_input(int op_mode)
Am I right, that to invert this behavior (use R:ext and internal on R) all I need to change is
case 1:// L internal R extrenal
            audio_ic_write(ML_RCH_MIXER_INPUT | ML_RCH_MIXER_INPUT_SINGLE_HOT); // replace with SINGLE_COLD
            audio_ic_write(ML_LCH_MIXER_INPUT | ML_LCH_MIXER_INPUT_SINGLE_COLD); // replace with SINGLE_HOT
            audio_ic_write(ML_RECORD_PATH | ML_RECORD_PATH_MICL2LCH_MICR2RCH); //
            audio_ic_write( ML_MIC_IF_CTL | ML_MIC_IF_CTL_ANALOG_SINGLE );


Also, as "L internal R extrenal" requires microphone power, is it possible to modify "External stereo" to work as mono (both channels left, or at least mute right channel)?
Just got new board to my not-turning-on 50d. It's giving me error 50, doesn't matter if with card or without.
I was able to put ML on card, I'm getting main log:, but no error/asset log.
I'm wondering if it's possible to use ML to get at least approximation of exactly what is causing this problem?

I got an idea to compile ML that will somehow bypass this error and call create_factory_menu_app(), there I would be able to test all stuff and find what's wrong, right?
I got 50d, died by unknown cause, but the result is known - fried (literally, when you connect only battery it gets hot in a second) DC-DC board. I found that this board is exactly the same as in 40d (only soldermask is bit different, all elements are the same), and got this part from someone with parts (from also not turning on) 40d.
It has also damaged CF slot (someone removed a few pins before me) - that is possible cause of damage and most probably I just need also to replace main board.
This DC-DC board seems to work, at least partially - i replaced faulty one in camera, got 3,3v near the place where voltage enters mainboard, but nothing more and camera is still dead. But 3,3v only may be normal situation when camera is turned off, so it can be faulty board, etc - that's where I need some help.

I'm looking for someone who can measure voltages on camera turned off (with battery inside) and turned on. They are traces on the easy accessible side of board, marked in pink circle on this photo:

(photo taken from

40d and 50d boards are almost identical there.
I just got myself external HDMI LCD. Well, literally LCD - this one is bare 7" 800x480 LCD + controller board with HDMI, VGA and Composite inputs. It handles inputs like 1920x1080 without problem, just downscale image to fit native resolution.
Exactly, this one: I got case from some old analog car lcd (7" 480x272) that has exactly same dimensions, so external lcd for 40 bucks seems like a very good deal.

But going back on topic. I connected it to my 550d. Everything's fine with one small exception - image on LCD is 3:2, like on camera internal LCD. Switching layout to 16:9/16:10 in ML menu (i use nightly from about a month ago) changes only position of elements inside that 3:2 part.
Does it work like this by design, and I should be able to "crop" image inside monitor, or camera is detecting LCD improperly?

That's how it looks on LCD:
General Chat / Magic Lantern Guide: Eos 1D mk2 & 1Ds mk2
September 20, 2014, 11:45:24 PM
I just bought myself MEDUSA NX Core Gaming Stereo Headset by Speedlink: (don't know retail price, got mine used for less than $10)
Note that's stereo, not 5.1 version.

This headset comes in two parts - one is headphones itself, other one is kind of USB soundcard. And we are interested with this part, as you can plug any headphones there.
It looks like this:

And have about 4 meters of USB cable... but not only with USB connector, also two RCA ones.
Why? It works also with PlayStation, etc - you connect USB to console as power supply and "inject" RCA into audio cable that goes from console to your TV.

And here comes the magic (that I found by accident) - in this "console" mode device works as... just headphone amplifier. I connected USB into my phone charger, RCA directly into Canon AV cable (as headphones got both male and female ones), turned on headphone monitoring in ML on my 550d... and it just works. Oh, and you got even volume control on "game" slider  :) Of course you can connect USB into some powerbank, I just don't have any with me now - that's why I used phone charger.

But, you know, "we need do dig deeper".
Cable is just too long, and I don't need USB soundcard (I bought this for good, cheap headphones, not for card itself). I disassembled device, found there just three microcontrollers - one is USB soundcard itself, other one kind of eeprom that stores card firmware (we don't need them for this purpose) - and third one is amplifier itself. After some checks using multimeter I belive that RCA input is independent from USB soundcard and goes directly to ampiflier and headphones.
And here's it's datasheet:

Now TL;DR quote from PDF above:
QuoteIt can operate from 3.0V to 7V single power supply (...)  The quiescent current is typically 1.5mA per amplifier @ 5V

That means that most probably (I need to confirm that) it can be powered directly from any cellphone battery (they are rated at about 3.7v), and at about 4mA current (two channels and smaller voltage) it would be enough for few hours of operation. Sadly, all Canon DSLRs seems to have 7.2V battery packs (fully charged goes over 8v) so taking power directly from battery grip is not an option.
So "to be continued"  ;)

A few days ago I was recording local event with my 550d (monument unveiling, concert, some interview, everything just before and after sunset). Because of lights on stage I needed much different WB than when looking on audience, etc. My idea is to have option for two custom defined (in K) white balances that user can quickly switch between with some keypress. There's (for example) this DOF preview button that is useless when in LV, so it could be potential place for this function.