Messages

1

General Chat / Re: M50 Mark II: Features and I don't want to live in this world anymore

« on: October 26, 2020, 04:40:19 PM »

Does it add those stupid side bars, with a blurred version of the video, to fill an horizontal display?
Or perhaps it converts an horizontal video into vertical, by adding top and bottom bars, and ruining it for everybody (yes, I have seen that)?

2

Feature Requests / Re: shoot with multiple shutter

« on: August 16, 2020, 01:30:59 AM »

Are you asking to change the aperture on a mechanical diaphragm 60 times per second? How many seconds of video do you think it is going to last before breaking?

And what about focal length... is the zoom supposed to move back at forth 60 times per second, too? How many lenses do you own that have a motorised zoom, by the way?

3

General Development / Re: Shoot calculator UI in ML (A New Year's dream?)

« on: January 04, 2020, 10:55:07 PM »

You'd be surprised!  I've seen "work towards this UI goal" as the first step before in professional teams.  I will admit it's often a lot more painful if the UI design came from the marketing department...

When you are developing a custom application for a specific client, you always create a mock UI first... "a customer only tells you what he wanted after you present him what he asked for".

4

Reverse Engineering / Re: Canon 7D Factory Menu

« on: June 14, 2019, 12:32:37 PM »

Done. Also tested the "Factory Menu" on 5D3, EOS M and 70D (and many other models in QEMU). Expecting it to work on any camera running EOS firmware. None of these options are interesting for regular users, so I'm not going to enable it just because we can.

There is also a "Factory Menu" on the 400D (not sure if it's among the screenshots you posted), that could be enabled from our hack, but we took it out of our menus many years ago, as it interfered with the USB connection and was of no use to most users. Also, there is an easter egg / hidden menu, that does not seem to make anything useful at all, if you switch the camera on with two specific buttons pressed.

5

General Development / Re: Remote single frame trig of time lapse movie - any models supported with this?

« on: June 07, 2019, 02:44:47 PM »

Can you use the flash hot-shoe, as a means to signal an external device when a photo has been taken?

6

General Chat / Re: SuperEIGHT Beer

« on: March 23, 2019, 02:29:10 PM »

Why?

7

Feature Requests / Re: Use scene modes as custom modes

« on: March 18, 2019, 12:33:04 PM »

sorry if OT but what about ML port for 400D?

I am not going to tell you not to do it, but... there are big differences between the 400D and ML-supported cameras (VxWorks vs DryOs, or no video/live-view support for starters) and the user base for that camera is now close to zero. I see a daunting task with little benefits: most of what ML can do but 400plus cannot do is because the hardware just cannot do it.

By the way I use 400D+ a lot but just curious about your opinion on porting ML

I do not want to seem anal about this, but the project is called "400plus"; I just do not want to infringe on any trade marks, and risk waking up the sleeping giant.

8

Feature Requests / Re: Use scene modes as custom modes

« on: March 15, 2019, 02:31:51 PM »

I wonder how 400plus does this. Got a ROM dump from 400D (as the portable ROM dumper works there too), but didn't attempt to emulate it beyond what already happened to work. It boots the GUI (I didn't do anything special for that), but the buttons are not working, as the MPU messages use a different format. I can ask Edu to capture diagnostic logs or whatever else I need to understand how it works, so it should be doable.

Did I hear my name...?
This is what we did in 400plus:

* Users can write a complete dump of the current camera configuration (mode, exposure, aperture, iso, ...) to the card; there is a structure in RAM called "DPData" that contains that info.
* Users can also assign each one of those dumps to one of the scene modes (this is done purely in 400plus, the original firmware is not aware of this).
* We intercept intercom messages, and when we detect that the user moved the wheel to a scene mode, we recall the configuration we had dumped previously, and then we apply it as if the user was navigating the menus.
* We also save the configuration from the manual modes and recall them when the user goes back from an override scene mode to a manual mode.
* If the user moves the wheel too fast, weird things happen...

All the interesting code is in those two files:

* https://github.com/eduperez/400plus/blob/master/cmodes.c
* https://github.com/eduperez/400plus/blob/master/snapshots.c

I made lots of mistakes during the development of that feature (we did not have an emulator back then ), and I never experienced any ERR70 or (soft)bricks... perhaps the 400D is more resilient than other cameras .

9

General Development / Re: Portable ROM dumper

« on: February 19, 2019, 11:31:35 PM »

I have a 30D if you want me to try anything. I must admit though that I am an absolute beginner in this space and will need some handholding to get me going.

Just download the file for your camera from the first post in this thread to a memory card, then place the card in the camera, and follow the firmware update procedure (it should be explained in the camera's manual, if it is not obvious by following the menus). Read the instructions on the screen, wait until it tells you to take the battery out, then share the new files that got created in the memory card.

10

General Development / Re: Portable ROM dumper

« on: February 18, 2019, 10:16:59 PM »

Results on a 400D:

Code: [Select]

  Magic Lantern Rescue
 ----------------------------
 - Model ID: 0x236 400D
 - Camera model: ???
 - Firmware version: ???
 - IMG naming: 100?????/????0000.JPG
 - User PS: ??? ??? ???
 - Boot flags: FIR=0 BOOT=-1 RAM=-1 UPD=-1
 - ROMBASEADDR: 0xFF810000
 - card_bootflags 101c0c
 - boot_read/write_sector 10735c 107374
 - 1023a0: cf_dir (cfata_init error)\n
 - 1020d8: cf_read_dma (cfata_init error)\n
 - 107260 Card init => 0
 - Dumping ROM0... 100%
 - MD5: 2c7ab85a893283e98c931e9511add182
 - Dumping ROM1... 100%
 - MD5: 51d4dc45a6cf2cf1ea077ac13c404786
 - No serial flash.

MD5 verified on computer.

11

Feature Requests / Re: Wanted: "sharpness bracketing" aka 2 consecutive frames w different aperture

« on: November 19, 2018, 11:33:47 PM »

[...]
The idea for a ML module would be the following:
  1. I set my exposure with a wide aperture (M mode)
  2. I take a 1st picture
  3. As soon as that picture is taken, ML reads my exposure settings and takes a 2nd picture closing my aperture by three stops and rising the ISO to compensate and achieve the same exposure.
[...]

Just out of curiosity: why do you raise the ISO instead of using a slower shutter speed?

12

Feature Requests / Re: Generating Ultra Resolution Images Through Vibrations

« on: October 26, 2018, 01:19:54 PM »

Some cameras already do this, primarily to overcome the limitations of the Bayer sensor (see Pentax's "pixel shift" technology, for example).
However, again, I do not think this should be done in the camera instead of using a computer.

13

Feature Requests / Re: Utilizing Dual-Pixel Sensors for Depth Map Generation

« on: October 26, 2018, 01:16:17 PM »

Your idea seems quite interesting, I think I posted an anaglyph made from a dual-pixed photo some time ago in this forum. You just need to get your hands on some dual-pixel RAWs and start experimenting on your computer. However, I do not see any advantage (and I see many disadvantages) on doing this on camera...

14

General Chat / Re: Removing Bayer Filter of EOS M or 100d?

« on: October 19, 2018, 03:16:56 PM »

But you gain some light by removing the bayer filter, so it accepts all available light...

And in some cases, "all available light" includes infrared and/or ultra-violet light...

15

Camera-specific Development / Re: Canon 80D

« on: July 17, 2018, 08:56:03 AM »

The MS614 is a rechargeable button cell, probably there only for timekeeping when there is no battery in the camera.
Since it's rechargeable, no need for user replacement...

Oh, I did not know that, thanks!

16

Camera-specific Development / Re: Canon 80D

« on: July 06, 2018, 09:49:32 AM »

Hopefully these photo's will help with something.

Congrats on these photos, they are very clear.

I'm surprised to see that there is a button cell there, but it cannot be changed by the user...

17

Camera-specific Development / Re: Canon 80D

« on: May 15, 2018, 10:13:59 AM »

@alex how is it coming with the 80D?
I have a brand new one and might help if you need it.

How can I help sir? I have an 80d and maybe can run some tests.

As @a1ex has commented before, you cannot help, but you can ask for help.

18

General Chat / Re: Leica Coding

« on: May 14, 2018, 10:19:05 AM »

I would say this is a very, very, long shot... but I do not want to discourage you, so here are my humble two cents:

* You will probably need to understand assembler, because you are not going to have access to the source code for the current firmware, and you will need that to do lots of reverse-engineering.
* You will also need to be able program in C, so you can write your own code.
* But before you can do anything useful with that knowledge, you will need to figure out how to execute your own on code on the camera's processor; Canon cameras have a nice mechanism to boot a program from the card, you should probably try to figure out whether there is something similar for Leica.
* One good starting point are firmware updates, if there is one available for your camera, but you will have to figure out how to interpret the file yourself.
* Only after you have understood the internals of the current firmware you will be able to answer questions 1 and 2.
* As far as I know, electronic shutter requires dedicated hardware.

19

Reverse Engineering / Re: JTAG on DIGIC chips

« on: April 24, 2018, 09:25:01 AM »

Somebody once told me that the JTAG connector was accessible through the grip connector...

20

Camera-specific Development / Re: Canon 70D

« on: January 17, 2018, 04:52:36 PM »

I was reviewing the list of Magic Lantern features which cannot be implemented on EOS 70D due to firmware limitations.  Okay, I don't know a thing about the CPU on this device or what language its firmware was written in, but I would imagine that somebody had to run a decompiler on the firmware at some point, while verifying what limitations it presents when porting Magic Lantern to run on it.  Furthermore, I would imagine, that if it could be demonstrated that the source code of decompiled firmware was sound enough to be compiled and link-edited to create machine code identical -- or at least functionally identical -- to the original firmware from which that source code was decompiled -- well, then I'd imagine the source code could then be tweaked so that the desired missing features of Magic Lantern would then run on EOS 70D.

Now, I know that's a lot of ifs -- and testing tweaked firmware would not only void warranty but could damage the camera.  But I imagine it could be done -- unless there is an actual hardware limitation on this camera beyond what the firmware will allow.  It might be foolish to try this ... but I cannot help wondering if somebody has?  Anybody in this forum perhaps?

That is not how it works...

Most of the firmware (at least the parts of it being executed on the main CPU) were (most probably) written in C. So far, all decompiling efforts have just translated machine code into assembler, and only for the purpose of studying how does the firmware work; it has never been translated into the original C (except probably some very specific parts, for illustration purposes). Besides, ML does not contain any of Canon's code, neither as binary, source code, or compiled from a decompilaton.

ML does not replace or substitute the original firmware, or even parts of it: what ML does is to interfere in specific points, hijacking the communication between different parts of the firmware, or between the firmware and the hardware; but the original untouched firmware is still in charge of the hardware, most of the time.

What you are proposing is a whole new beast... not only you need to produce a sorce code that can be compiled to match the current firmware, you also have to ensure that any modification you make to it does not break everything. I have still not heard of anyone decompiling the ASM into the original C, or any C code that can be compiled back and produce the same firmware, let alone some C that can be understood by humans. And then, just adding one single instruction means all code and data gets relocated, and thus all references must be updated.

21

General Chat / Re: Hacking DSLR battery to power camera from power supply

« on: December 10, 2017, 12:13:43 AM »

My two cents:

• Use a proper power supply, instead of the battery charger.
• Have you tried to find compatible devices on eBay?

22

Feature Requests / Re: Canon PowerShot G7 X Mark II USB microphone adapter

« on: November 30, 2017, 11:29:14 AM »

I might be wrong... but as far as I know there is a hardware limitation that makes impossible to use the USB port as a HOST.

23

Camera-specific Development / Re: Canon 60D

« on: November 21, 2017, 11:07:47 AM »

Okay, this is the closest i got: 40D

http://cholla.mmto.org/photography/gear/repair/eos_40d_service_manual.pdf

Otherwise:

http://pdfwhiz.org/lp4/?title=canon%2060d%20service%20manual%20pdf

But don't count on me putting any credit card infos in that king of a website.

Yes, the "2. BLOCK DIAGRAM > 2-1 GENERAL" on page 151 could be interesting, if there is something there that developers still do not know.

24

Camera-specific Development / Re: Canon 60D

« on: November 20, 2017, 12:54:35 PM »

Here what i found on the web:

https://www.dropbox.com/s/gz50t04h4chxvhv/EOS%2060D%20Parts%20catalog.pdf?dl=0

60D part catalog! I got also for 7D, 5DII, 5DIII and 600D.

Might be some help for retroengineering?!

Cheers.

It just goes down to "printed circuit board" level, it does not even list the integrated circuits in that board... I do not think it can be used for reverse-engineering, unfortunately. However, service manuals do have that information (and more); those could be useful.

25

Camera-specific Development / Re: Canon 80D

« on: September 09, 2017, 07:16:28 PM »

I have to install http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTF_80D.FIR, which will "only" modify the boot flag, after which the tests should not modify anything, they are just some test and then normal situation should resume?

Just for clarification: you only need to enable the boot flag to execute AUTOEXEC.BIN files, all .FIR files are executed using the firmware update procedure, and do not need the boot flag enabled.
On the other hand, only the "BOOTF_80D.FIR" makes changes to the camera, all other .FIR files are supposed to be harmless.