Canon 5d Classic Development ***BOOTDISK NOW ENABLED*** - page 6 - DSLR Hack development - CHDK Forum  

Canon 5d Classic Development ***BOOTDISK NOW ENABLED***

  • 65 Replies
  • 55979 Views
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #50 on: 02 / May / 2012, 10:31:34 »
Advertisements
I'm starting to realize just how different the 5dc is from all cameras. There is nothing else in the same group as it. The startup code is more like the 400d, while the tasks (like gui main task) seem to be more like modern DryOS cameras like the 5d2.
actually i find it more like 400d than what you would expect ;)
or to be correct, 400d is like 5dc ;)
the tasks in 400d are not so different than the ones in 5dc and in the DryOS cameras.

I do not understand 400plus very well, specifically the main event queue you guys hijack, something about event proxy or something. I have not found anything like this in the 5dc yet, it seems to be very similar to modern DryOS cameras.
it's just an abstract work, though the ML and your path are based mostly on GUI task hijacking, and our work is based mostly on InterCom/MainCtrl hijacking... different tasks, nothing more.

I think 5dplus is going to take a very similar path to MagicLantern. It's very similar to DryOS cameras, but not similar enough to port MagicLantern on it (mainly because of things like the bmp vram being half the size, so all printing routines like bmp_hexdump need to be rewritten to fit on the 5dc screen).
i too believe it wont be possible to port ML on vxworks camera... atleast not w/o too much of effort...
though the DryOs cameras are very similar with VxWorks cameras, canon kept their api almost the same, or atleast it looks like this... i guess DryOs cameras would have more functionality of course.

At the rate things are going, I'm projecting 5dplus to be available to the public by the end of this month. I've almost got the framework written for a hack, it's just a matter of finishing now. Once I have the property system figured out, that will be the last thing on the list before I begin writing a menu system and add features.
My guess would be for much more time ;) you will have to fight a lot more battles IMO, but i will be happy if you prove me wrong :)
Though we shall acknowledge your fast progress these days ;)

I'm excited to see what this camera can do :) Here's a (not so organized) list of things I've discovered recently:
- setting ISO property above ISO3200 does not seem to have any effect, so ISO caps out a 3200.
- inbetween ISO values like iso2500 don't seem to work, it just sets it to ISO3200.
- the properties seem to work the same as in magic lantern dryos cameras, I used the values for the ISO property from lens.h of magic lantern to test the ISO stuff.
I'm not vary familiar with the iso stuff, but Edu perhaps could help you...

- I discovered that the maximum size for an autoexec.bin seems to be about 2mb, anything higher causes the camera to crash in play mode. This means 5dplus has plenty of room to grow for the future.
while it's quite possible to have 2mb of space for your stuff,
i wonder how much ram is there ... it seems like 8mb in 400d, but could be more...


// AF

Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #51 on: 02 / May / 2012, 10:59:38 »
I'm excited to see what this camera can do :) Here's a (not so organized) list of things I've discovered recently:
- setting ISO property above ISO3200 does not seem to have any effect, so ISO caps out a 3200.
- inbetween ISO values like iso2500 don't seem to work, it just sets it to ISO3200.
- the properties seem to work the same as in magic lantern dryos cameras, I used the values for the ISO property from lens.h of magic lantern to test the ISO stuff.
I'm not vary familiar with the iso stuff, but Edu perhaps could help you...

I think all I can say is that we have to "enable" intermediate ISOs before using them:
Code: [Select]
start_up@tasks.c:47
        // Enable (hidden) CFn.8 for ISO H
        send_to_intercom(IC_SET_CF_EXTEND_ISO, 1, 1);
And our camera does not support "higher" ISOs (despite the comment), just intermediate values; so we max out at ISO-3000 (ISO-1600 + 7/8 EV).

*

Offline Coutts

  • *****
  • 538
  • www.flickr.com/couttsphotog
    • Flickr
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #52 on: 02 / May / 2012, 12:38:41 »
I think all I can say is that we have to "enable" intermediate ISOs before using them:
Code: [Select]
start_up@tasks.c:47
        // Enable (hidden) CFn.8 for ISO H
        send_to_intercom(IC_SET_CF_EXTEND_ISO, 1, 1);
And our camera does not support "higher" ISOs (despite the comment), just intermediate values; so we max out at ISO-3000 (ISO-1600 + 7/8 EV).
I don't think the 5d has this "send_to_intercom" function, how's that work exactly?

In the 5d, I plan on just changing properties as in Magic Lantern. I have already tested successfully prop_request_change on PROP_ISO.
Canon 5d
Canon 50mm f/1.8
Sigma 24mm f/1.8

Flickr

*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #53 on: 02 / May / 2012, 14:15:08 »
Quote
send_to_intercom

In 5D2:
Code: [Select]
dec InitializeIntercom #0xff861988
AJ_setup_MREQ_n_SIO3_ISR(arg0, arg1, arg2, AJ_hotplug_or_secretMode_Jtbl)

MREQ and SIO3 seem related to Tx19a.

Hint: 550D can take pictures and show ISO and other parameters in viewfinder without even booting the main firmware (try with an infinite loop in reboot.c). Sure, it doesn't save them on the card.


*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #54 on: 02 / May / 2012, 18:01:13 »
I don't think the 5d has this "send_to_intercom" function, how's that work exactly?

You do have SendToIntercom(msg, len, param) for sure... all canon cameras should have it...
and you should have Intercom task too.
the SendToIntercom() basically should do : PostMessageQueue(intercom, msg, len, param);

here is how we hijack the intercom task:
          InitIntercomData(intercom_proxy);
the intercom_proxy() is our task routine...


EDIT:
you should be able to do what Edu said by finding the SendToIntercom(), you do not need to hijack the intercom task at this time i believe.

EDIT2:
btw your bmp_vram() returns uint8_t, which is wrong i guess...
and check where you use it, it seems you store the result in uint8_t too...
« Last Edit: 02 / May / 2012, 18:57:00 by 0xAF »
// AF

*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #55 on: 02 / May / 2012, 20:20:54 »
Ok, great news from here,
With the great help and work of Andrew and Alex, i've managed to find the VRAM buffer and ported 5dc's bmp.[ch] with the fonts.

400D now says "Hello World!"

Thanks guys.

http://code.google.com/p/400plus/source/detail?r=1342
// AF

*

Offline Coutts

  • *****
  • 538
  • www.flickr.com/couttsphotog
    • Flickr
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #56 on: 16 / May / 2012, 16:34:46 »
Lots of help from Alex today (thanks!), finally I think my code is sitting in a safe spot in memory. We also located some new functions (some of these were tricky):

Quote
NSTUB(0xFFB2F664, AllocateMemory)
NSTUB(0xFFB2F680, FreeMemory)
NSTUB(0xFFB2A56C, allocate_dma_memory)
NSTUB(0xFFB2A5B0, free_dma_memory)
NSTUB(0xFFB2F750, GetMemoryInformation)
Using GetMemoryInformation we found that there is about 3mb of heap space free at the moment.


I changed the first call to CreateMainHeap in task_Startup, to make the heap end 512kb sooner than normal. This leaves a gap at the end like this:

Normal
---[ heap space]------

Modified
---[heap space][ 512kb gap]------

Then, I used the COPY function from 400plus to copy 512kb from 0x800000 (the spot where the bootloader copies/links autoexec.bin files) to the new space, and changed the linker script to link my code to that new spot. This should have 5dplus code sitting in a safe spot in memory now where it cannot be overwritten by Canon. This also means that our autoexec.bin file can grow up to 512kb (which is plenty, ML in its current state is just under 400kb I believe).

So, this is another step forward. Next I will be spending my time slowly porting the menu system from magic lantern. Alex has told me that there is a routine in ML to resize vram on the fly, so that means I can keep the ML code for the most part identical, and just scale everything down to 1/2 size to fit the 5dc screen on the fly (and not worry about all of the hardcoded values for sizes).

Changeset can be found here:
https://bitbucket.org/coutts/5dplus/changeset/858ffa089521
« Last Edit: 16 / May / 2012, 16:37:19 by Coutts »
Canon 5d
Canon 50mm f/1.8
Sigma 24mm f/1.8

Flickr

Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #57 on: 17 / May / 2012, 06:28:05 »
Do you know if reserving that much memory can have any side effects? Perhaps the image buffer is smaller now?

We have been reserving just 64KB on the 400D, and recently changed that to 128KB; but I still tend to save as much memory as possible in the code, just in case we need to lower that limit again.


*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #58 on: 17 / May / 2012, 06:54:53 »
Since there are 3 MB free, I don't think there's any problem. Plus, you can always monitor the amount of free memory with GetMemoryInformation.

Shoot memory is somewhere else (much bigger).

*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Canon 5d Classic Development ***BOOTDISK NOW ENABLED***
« Reply #59 on: 17 / May / 2012, 07:50:50 »

Since there are 3 MB free, I don't think there's any problem. Plus, you can always monitor the amount of free memory with GetMemoryInformation.

Shoot memory is somewhere else (much bigger).

yeah, we've never checked the free memory (thanks for the hint). ;)

Do you know if reserving that much memory can have any side effects? Perhaps the image buffer is smaller now?

We have been reserving just 64KB on the 400D, and recently changed that to 128KB; but I still tend to save as much memory as possible in the code, just in case we need to lower that limit again.

i think we have a plenty of space to use, still we are limiting us to remember that this an embedded environment and we should care of the space :) :) :)
« Last Edit: 17 / May / 2012, 07:53:03 by 0xAF »
// AF

 

Related Topics