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

Messages - Ant123

Camera-specific Development / Re: Canon 40D
August 08, 2022, 11:18:21 AM
Quote from: heder on August 07, 2022, 08:47:31 PM
No one have documented to JPEG engine and registers so it's a black box.

Have you tried to logging MMIO traffic through JPCore?
General Chat / Re: Post waiting to be approved
June 27, 2022, 10:32:42 AM
Yes, it seems that to contributors, too.
At least it works on EOS M3. Of course it is possible that 6D behaves differently.
Did you try to isolate both service contacts on your battery?
On LPE-17 one of two middle contacts is temperature sensor and the other one is used for data communication.
When you leave only "+" and "-" terminals, camera can decide that you are using a DC coupler.
But the shut down level might change.
Quote from: kitor on June 09, 2022, 05:51:29 PM
Maybe StartGyroRec?

Maybe. On EOS M3 "EnableAcceleLogWrite" just sets the flag which is checked in "Accelerometer" task.
I did not find this task in RP's task list. Maybe "EIS" task?

M3 uses MMA8452Q chip. The same accelerometer found on PCBs of EOS R, RP, M50
I wrote "probably". I don't have access to the firmware of EOS cameras(Digic8, DigicX) with Canon Basic.
But you can look for similar names in your firmware.
EOS M3 has builtin event procedure "EnableAcceleLogWrite" which creates the "Accelelog0.csv" file (Accelelog1.csv, Accelelog2.csv, Accelelog3.csv, etc) containing the following data:

time, x_axis, y_axis, z_axis
0, 2066, 1029, 2036
20, 2065, 1031, 2038
40, 2067, 1036, 2038
60, 2067, 1029, 2042
80, 2067, 1027, 2042
537380, 3074, 2003, 1986
537400, 3074, 2004, 1986
537420, 3074, 2004, 1985
537440, 3074, 2004, 1984
537460, 3074, 2004, 1984
537480, 3076, 2003, 1988

Probably it can be used on modern cameras with Canon Basic if this data is sufficient for Gyroflow.
This source code came from the official ML bitbucket repo last year before they removed all mercurial repos.
It contains my 450D related changes. Some code was taken from heder's 40D project.
But there was no changes since summer 2020. I was trying to convert mercurial to git locally but without success. Maybe I am wrong  but it's strange that bitbucket do not provide mercurial to git conversion like github doing it (AFAIK).
I uploded the source code and the latest build to bitbucket.
But the modules can't be built because of missing the ".hg" folder. How to fix that?
Motion Jpeg movie recording is still experimental. It is limited to the SD controller speed.  Maybe there need to increase somehow the compression of JPEG frames.
Is there the way to run event procedures with arguments?
Yes. It works.
Just because of Canon's firmware:

uint handle_PTP_OC_0x9050
               (undefined4 param_1,undefined4 *param_2,undefined4 param_3,undefined4 param_4,
               undefined4 param_5)

  uint uVar1;
  uint uVar2;
  uint uVar3;
  uint uVar4;
  uint uVar5;
  uint uVar6;
  uint uVar7;
  undefined2 local_38 [2];
  undefined4 local_34;
  undefined4 uStack48;
  undefined4 local_2c;
  uVar7 = 0;
  uStack48 = param_5;
  local_2c = 0;
  DAT_0000ef68 += 1;
  local_34 = param_4;
  if (DAT_0000ef68 == 3) {
    uVar1 = add_ptp_handler(&DAT_00009052,handle_PTP_OC_0x9052 + 1,0);
    uVar2 = add_ptp_handler(&DAT_00009053,handle_PTP_OC_0x9053 + 1,0);
    uVar3 = add_ptp_handler(&DAT_00009057,handle_PTP_OC_0x9057 + 1,0);
    uVar4 = add_ptp_handler(&DAT_00009058,handle_PTP_OC_0x9058 + 1,0);
    uVar5 = add_ptp_handler(&DAT_00009059,handle_PTP_OC_0x9059 + 1,0);
    uVar6 = add_ptp_handler(&DAT_0000905a,handle_PTP_OC_0x905a + 1,0);
    uVar7 = add_ptp_handler(&DAT_0000905b,handle_PTP_OC_0x905b + 1,0);
    uVar7 |= uVar6 | uVar5 | uVar4 | uVar3 | uVar2 | uVar1;
    DAT_0000ef64 = 1;
  if ((uVar7 & 1) == 0) {
    local_38[0] = 0x2001;
    (*(code *)param_2[3])(*param_2,local_38);
  else {
    local_38[0] = 0x201f;
    (*(code *)param_2[3])(*param_2,local_38);
    uVar7 = 1;
  return uVar7;

I already found that the command 0x9052 becomes available after calling the command 0x9050 three times.
Does this mean that ptp command 0x9052 (36946) is not supported?
Quotepython3 ./
    StandardVersion = 100
    VendorExtensionID = Microsoft
    VendorExtensionVersion = 100
    VendorExtensionDesc =
    FunctionalMode = 0
    OperationsSupported = ['GetDevicePropDesc', 'GetDevicePropValue', 'SetDevicePropValue', 'ResetDevicePropValue', 'GetDeviceInfo', 'OpenSession', 'CloseSession', 'CheckEvent', 36956, 36957, 'ChangeUSBProtocol', 'GetStorageIDs', 'GetStorageInfo', 'GetNumObjects', 'GetObjectHandles', 'GetObjectInfo', 'GetObject', 'GetThumb', 'GetPartialObject', 'SendObjectInfo', 'SendObject', 'DeleteObject', 'FormatStore', 'SetObjectProtection', 'GetObjectSize', 'GetObjectInfoEx', 'GetPartialObjectEx', 'GetObjectAttributes', 'SendPartialObject', 'GetObjectHandleByName', 'SetObjectTime', 'SetObjectArchive', 36940, 'SendObjectInfoByPath', 'SendObjectByPath', 36920, 36921, 36922, 36923, 36939, 36960, 36962, 38913, 38914, 38915, 38916, 38917, 'EOSGetEvent', 'EOSGetStorageIDs', 'EOSGetStorageInfo', 'EOSGetObjectInfo', 'EOSDeleteObject', 'EOSFormatStore', 'EOSGetPartialObject', 'EOSGetObjectInfoEx', 'EOSGetThumbEx', 'EOSSetObjectAttributes', 'EOSTransferComplete', 'EOSCancelTransfer', 37164, 37170, 37173, 37184, 37185, 37187, 'EOSPCHDDCapacity', 37183, 'EOSSetEventMode', 'EOSSetUILock', 'EOSResetUILock', 'EOSKeepDeviceOn', 37181, 37174, 37175, 'EOSSetRemoteMode', 'EOSGetViewFinderImage', 'EOSRemoteReleaseOn', 'EOSRemoteReleaseOff', 'EOSZoom', 'EOSZoomPosition', 'EOSDoAf', 'EOSAfCancel', 'EOSDriveLens', 37211, 36911, 'EOSSetDevicePropValueEx', 'EOSRequestDevicePropValue', 37250, 37251, 37252, 37253, 36944, 36945]
    EventsSupported = ['CancelTransaction', 'ObjectAdded', 'ObjectRemoved', 'StoreAdded', 'StoreRemoved', 'DevicePropChanged', 'ObjectInfoChanged', 'DeviceInfoChanged', 'RequestObjectTransfer', 'StoreFull', 'DeviceReset', 'StorageInfoChanged', 'UnreportedStatus', 49153, 49157, 49162, 49409]
    DevicePropertiesSupported = [53317, 53322, 53294, 53295, 'BatteryLevel', 53250, 'ViewfinderMode', 'UnixTime', 53319, 53318, 53296, 53321, 'CameraModel', 'CameraOwner', 'FlashMemory', 53328, 53329, 53330, 53331, 53332, 53335, 54274, 54278, 54279, 54019]
    CaptureFormats = ['EXIF_JPEG']
    ImageFormats = ['Association', 'Script', 'DPOF', 'WAV', 'EXIF_JPEG', 'UndefinedImage', 'CRW3', 47490, 45317, 48897]
    Manufacturer = Canon Inc.
    Model = Canon EOS M3
    DeviceVersion = 3-
    SerialNumber = *
Quote from: kitor on May 29, 2021, 10:42:55 AM
Good and bad at the same time.
Bad - considering XimrContext struct changed multiple times in Digic6 gen and then for each next generation. It will require work for multiple models.
It's not a big problem. Look at CHDK: they support 160 cameras and 320+ firmwares.

QuoteGood - I noticed this week that GUI code on R swaps buffer addresses inside VRAM struct used for 1st layer (GUI) somewhere on early boot. If I grab GUI VRAM struct fast enough, I get pBitmap address of overlays buffer instead of GUI. Thus hardcoded addresses would fail quickly.

The current YUV Bitmap address can be obtained from MMIO register of display controller.
Quote from: kitor on May 29, 2021, 09:01:05 AM
Static source and destination addresses or you somehow parsed XimrContext?
The second one. ATM I use only one RGBA buffer. It's should be enough for playback mode

QuoteGood to see a progress on that.
It is bad that A1ex and other 'guru' developers  show little activity now. There are less than 20 commits for two years.  :(
These steps are performed on special hardware(zico and display controller) independently of the main (ARM) core. So they could be emulated by the second thread independently...
Some progress with GUI emulation on EOS M3:

Is it possible to utilize more than one host's core by QEMU?
For example for display redrawing.
My current implementation converts zico's rgba buffer to yuv bitmap+opacity, then converts yuv image and yuv bitmap buffers to rgb, mix them using opacity buffer and put the result to QEMU's output buffer. This is a job for the second core.
Camera-specific Development / Re: Canon 40D
January 16, 2021, 01:23:00 PM
Quote from: a1ex on March 09, 2019, 08:05:05 AM
FIO_SeekSkipFile: should be testable in QEMU, with a large SD image and the test code from That test will create a large file (2GB) and seek within that file.

There are two versions in Canon firmware: one that accepts 32 bits for the position and another one that accepts 64 bits. They are not interchangeable at binary level.
Quote from: McPretzl on October 18, 2020, 03:12:22 PM
This delay can apparently cause some electronic parts of the lens to take physical damage, perhaps due to an ongoing electrical impulse
(so the guy at the repair center told me)

He had to come up with a justification for the cost of the repair. But perhaps he actually replaced only this part:)
Camera-specific Development / Re: Canon 40D
October 01, 2020, 02:22:29 PM
Quote from: theBilalFakhouri on October 01, 2020, 12:00:16 PM
I am excited to take a look into MJPEG code :D
You can look into my current version

Quote from: a1ex on February 23, 2019, 09:34:06 AM
On newer models (DIGIC 5, IIRC also 60D and newer DIGIC 4), this function no longer runs automagically while in LiveView, so this approach is only valid for older models.
Camera-specific Development / Re: Canon 5D Mark IV
September 17, 2020, 07:15:19 PM
Quote from: chris_overseas on September 17, 2020, 06:43:05 PM
Your best bet would be to find someone who backed up the BitBucket Hg repos and grab a copy of my code from what used to be, and see how you go from there.

Probably can help...
Camera-specific Development / Re: Canon EOS R5 / R6
September 08, 2020, 11:09:24 PM
This shouldn't be a big problem for people who have decided to remove the rubber.