Discussion about Canon XF605

[ponguin]

This thread is meant for the general discussion targeting Canon XF605, i.e. everything that does not clearly belong into another section of this forum.

Always bear in mind, that XF605 is a camcorder and not a target DSLR/DSLM of ML!
So any requests, especially feature requests should be carefully assessed before posting them here, especially whether they rather ought to be addressed (and sent) to Santa Claus.
Rule of thumb: High profile features and requests like "raw video, plz!!" -> Santa Claus (unless you provide a proof of concept of course  ).

Remarks about bugs in the official firmware are welcome here, although chances are negligibly small that someone besides Canon can fix them.
So do not forget to talk to your Canon representative (unless you do not care about your bug).

Shortcomings that are very unlikely to be related to pricing policy, however, might be of interest and are welcome in this thread.

E.g., the direction of the zoom ring could be inverted from Canon's first HD(V) camcorders in the same category as XF605 onwards (XH A1/G1/A1s/G1s/...).
This is not the case anymore on XF605, which is extremely annoying, and nothing that you could get from Canon by throwing money on the problem (buying XF705) either.
While it is absolutely unknown whether this shortcoming could be theoretically overcome via an firmware update or a ML like firmware extension, investigating whether that seems possible (i.e. the zoom ring's position is forwarded by the ICU to the electromechanical system) or not (i.e. the zoom ring's position is directly coupled with the electromechanical system without the ICU being able to interfere) might be a very interesting research question.

Last but not least, discussion about possibly relevant old/other threads for XF605 can go here as well.
If it turns out that something is indeed the same on XF605, the link can/will be later added to another thread, dedicated to summarizing progress on XF605, with a detailed description explaining the findings (including possibly observed minor differences).

[names_are_hard]

Welcome to ML!  Or, almost ML

This cam looks full of promise and should be easy enough to port to.  I'm not sure about features, but getting ML framework running looks doable

For ML people, this looks like a Digic X cam, with an unusual startup routine that copies almost the entire rom into ram before running it.  Patching this cam will be much easier than normal.

Good luck with the puzzle!  I will help whenever I can.

[names_are_hard]

Always bear in mind, that XF605 is a camcorder and not a target DSLR/DSLM of ML!

I did a blind port of ML to XF605: https://github.com/reticulatedpines/magiclantern_simplified/tree/xf605

This is untested on phys cam and caution should be used.  The code around the bootloader has been tested in qemu and works for me...  later code cannot be tested in qemu because it doesn't emul far enough.  If you test it, please let me know how it goes

From experience with other cams, I would expect this to be safe to run on phys cam.  It might crash, but it is probably safe.  I put some uart_printf() logging in init.c inside CONFIG_XF605 guards, which will give some idea of how far through the boot process it gets.

In general, this feels like a standard Digic X cam, until you get quite high up in the GUI layers.  I would guess the windowing system is the same, but what is drawn with it is different.  Makes sense, since it has a video oriented GUI.  It does have some LiveView strings though, so I'd guess the code has DSLR heritage.  I saw no fundamental reasons why ML wouldn't run fine on this cam.  I'm not sure the standard ML menus would be very useful, so we might want to split that up, menu-dv.c or something.  But all the code we have for drawing menus, storing settings, interacting with tasks etc would still be useful.

Some notes:

Lens info struct is definitely not correct.  I made it the right size, but don't know the names or offsets of fields.

DryOS asserts have two potential handlers on this cam!  One at 0x4004, one at 0x4000.
ML hijacks one handler, assuming there is only one.  I haven't investigated what the second handler does (GUI handler maybe?)

I couldn't find CancelDateTimer() so I hacked this out in source for XF605 only.  Would be nice to find it.

All the button codes in platform/XF605.101/gui.h are junk, so you won't be able to enter ML menus.  The easiest way to find these is log them from uart, see e.g. here in menu.c:

6258 // SJE useful for logging buttons
6259 //    DryosDebugMsg(0, 15, "event->param 0x%x", event->param);

Last note, not relevant to the port, just something interesting I found, XF605 (fw 1.0.1) appears to have a GUI service mode, see "WINSYS_CreateDialogBox (StartServiceModeMainApp)", 1eac6046(), 1eac5de4().

It's likely triggered by an event:

    if (param_2 == 0x10000052) {
      DryosDebugMsg(0x82,3,"IDLEHandler(Common) : PRESS_SERVICE_ON",0x1c);
      FUN_1eac6046();
      return 0;
    }

I don't know the buttons on this cam, possibly there's one labelled Service?  If not, this is probably a synthetic event.  You could create it via code, might be interesting.