might have found possible other hd buffers? not sure about their size yet.
spying on a few locations that i found contain 0x46000080 (one working hd address we have), using hunt.py from alex. Below are a few locations and the values i noted they cycle through in live view:
--0x157f84--
0x46000080
0x06000080
0x48000080
0x08000080
--0x869a70--
0x46000080
0x48000080
--0x48a0--
0x46000080
0x48000080
I have now confirmed that 0x46000080 and 0x48000080 work (using dimensions 928x616 with pitch 1856), as noted on the vram page for the 500d. the 0x44000080 value on that wiki appears to be wrong, because silent pics/magic zoom weren't right at all.
I'm going to try some of these other values now.
edit:
0x06000080 works
0x08000080 works
so now we have 4 lv_hd_buffer addresses: (0x06000080, 0x08000080, 0x46000080, 0x48000080). with a possible dma address at 0x157f84 switching between all 4, or 0x869a70 switching between 0x46000080 and 0x48000080.
the only odd thing is that focus peaking is offset, vertically lower than the actual display, so the whole focus peaking map is off by a little bit -_-
it isn't like this on the lv address, but it is on all 4 of these hd vram addresses... i'm stumped.
everything is working beautifully now.
Strange, I'm sure I found an actual image at 0x44000080 in one of my old dumps. Maybe the location varies between 0x44..., 0x46... and 0x48... or so.
Also, I always assumed that the first nibble of the address somehow did not really matter, apart from 0x1 and 0x5 (garbage), and high values (0x8 and higher iirc).
Either way, now that we have the location of the dma pointer, we can always be sure instead of guessing :-).
With regards to those 0x0 and 0x4 addresses in the dma pointer at 0x157f84. That's a really interesting find! Maybe that 0x0 and 0x4 page arent the same after all? Or maybe that second bit is a flag for something -- like "this buffer is still being written to atm", as the other addresses don't seem to mention anything in the 0x0 section.
Regarding the offset peaking: the HD buffer maybe uses a different pixel ratio than the liveview buffer, so you will possibly need to do some resampling to get it to map correctly to the vram that ML writes to. Just about every resolution found on the vram wiki page has a different aspect ratio...
One final note, I found the 0x48000080 buffer to contain a 1576x1048 image once (when recordig at 1080p), you might try to check this to see if this breaks the current code (ie if the features don't work when actually recording at 1080p).
I'm trying to get my camera to boot ML again asap, but something fishy has happened (probably whist dumping vram) that makes it impossible to boot from the autoexec (tried pretty much everything). Grrr.
