maybe other can try this idea or help if it work better on 16:9 Camera when have a buffer
I don't understand. Your idea about AllocateUncacheableMemory is wrong, as I explained.
maybe when allways allocate a 16:9 temporary buffer, and copy the display buffer(center) to correct positions, zebra/edge overlay can work in 4:3 mode too ?
I don't understand.
I think in libc this fixed values are wrong, because when the camera use a 4:3 shooting mode, the wide of the buffer is smaller.so need return value depend on shooting mode.
long vid_get_bitmap_buffer_width() { return 960; }
long vid_get_bitmap_buffer_height() { return 270; }
So change the code so it depends on shooting mode....
1 raw have 15 meg, so this are a buffer of 75 megabyte need.75 is a odd number for memory, maybe there are some 500 kb more RAM here.
Odd number doesn't mean anything. There are other pools, this is known. To figure out how to use them you need to be able to reverse engineer the firmware.
Information below is untested:
The stings EXMEM_* list the different memory pools.
If you look at ExMem.AllocateCachable eventproc, it calls another function (sub_FF86C810 in d10), something like this
f(0xA,<size>,0)
Based on a table of the EXMEM_ strings (starting at FFB5031C in d10), this should be EXMEM_SCRIPT.
The final 0 means cachable.edit: looks like this is actually something else. AllocateUncachable calls different but very similar function, with the equivalent parameter also set to zero.
In my experience EXMEM_SCRIPT is small (not big enough for a full CHDK build). But 0 above should be EXMEM_RAMDISK, which ewavr reported to allowed a lot to be allocated.
You will also have to make the corresponding free function, which you should also be able to base on the corresponding ExMem eventproc.
Side effects of using memory from these pools are unknown.
Edit:
It looks like these only allow a single allocation (the Free function doesn't take an argument), so you'd need to make a sub-allocator if you wanted to use one as a replacement from malloc. This probably makes my conclusion that EXMEM_SCRIPT is small wrong, because I was trying to allocate more than one thing from it.
Edit:
If ExMem.View is to be believed, EXMEM_SCRIPT is good for 3,185,280 bytes on D10.
If you use ExMem.AllocCacheable with any size, this shows up in the size column of ExMem.View. If you free, it goes back to zero. It doesn't fail if you request a larger value.
Maybe I'm not understanding how this works...
Edit:
OK, I'm definitely not understanding something.
If I call_event_proc("ExMem.AllocCacheable") with any value, ExMem.View always reports
EXMEM_SCRIPT [0x43E02B80] , [0x00309A80]
If I call sub_FF86C810(0xA,size,0) it reports the requested size. Same for all the other EXMEM_ pools. It asserts if you try to alloc on one that is already allocated.
ExMem.AllocCacheable is
MOV R1, R0
MOV R0, #0xA
MOV R2, #0
B sub_FF86C810
And is registered with
RegisterEventProcedure_im1
