Display (bitmap overlay) - page 34 - General Discussion and Assistance - CHDK Forum

Display (bitmap overlay)

  • 336 Replies
  • 66930 Views
Re: Display (bitmap overlay)
« Reply #330 on: 10 / June / 2021, 13:12:57 »
Advertisements
M


Update


Just tried resetting several times and problem has gone away.  :)
« Last Edit: 10 / June / 2021, 14:44:41 by pigeonhill »

*

Offline srsa_4c

  • ******
  • 4409
Re: Display (bitmap overlay)
« Reply #331 on: 10 / June / 2021, 17:22:55 »
With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.
Since this new drawing method isn't finalized yet, we'd really like to know more about these cases where it fails.
Quote
Just tried resetting several times and problem has gone away.
A missed opportunity, sadly.

What I'm thinking is: we could make copies of the ximr struct (one for normal, one for the yuv case), and write them to card when the debug shortcut is pressed. We could use the memory dumper mode (DmpRAM), but write our debug buffer instead.

Re: Display (bitmap overlay)
« Reply #332 on: 10 / June / 2021, 17:34:17 »
@srsa_4c

Quote
A missed opportunity, sadly.

The problem was definitely there, ie only when CHDK was enabled on the card and I was in Manual C mode.

I then reset C mode to Av and then back to M mode and the problem disappeared.

I’ll keep looking out for ‘anomalies’ and report.

Cheers

Garry

*

Offline philmoz

  • *****
  • 3319
    • Photos
Re: Display (bitmap overlay)
« Reply #333 on: 10 / June / 2021, 17:57:31 »
With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.


@pigeonhill


I don't see any issues with the EVF on my G5X even in C mode - so there may be some Canon setting that is affecting the EVF that I am not using.
Can you list what settings you have saved to your C mode.


Also what firmware version is your camera.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


*

Offline philmoz

  • *****
  • 3319
    • Photos
Re: Display (bitmap overlay)
« Reply #334 on: 10 / June / 2021, 18:01:41 »
Just tried resetting several times and problem has gone away.  :)


@pigeonhill


Did you reset the Canon settings or the CHDK settings?

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: Display (bitmap overlay)
« Reply #335 on: Yesterday at 00:33:03 »
Quote
Did you reset the Canon settings or the CHDK settings?

I just changed the Canon custom setting, ie from M to Av and then back to M.


*

Offline srsa_4c

  • ******
  • 4409
Re: Display (bitmap overlay)
« Reply #336 on: Today at 17:37:04 »
I've been doing some research on the Zico side, some of this may help clear up a few of the unknowns. I did not try any of the following on camera.
- There is an optional (output?) MARV struct, starting at byte offset 12 of ximr_context. At least two fields in the struct need to be nonzero for it to be recognized. I don't go in details as I doubt this is of any use.
- The halfword at byte offset 6 of ximr_context seems to be referred to as "DivSize". It gets compared with width1 (at byte offset 2). width1 and height1 seem to be the maximum width and height used in layers. When width1 is set to 0xffff, the layers are searched for the largest width.
- There is a color type 3 (probably not used) which needs some additional bytes of ximr_context filled (so it would be quite difficult for us to try).
- The first 18 bytes of ximr_layer are written to MMIO like this (I did this by hand, mistakes are possible):
Code: [Select]
*(uint32_t*)0xc80b0040=u8_14 | (u8_13<<2) | (u8_12<<6) | (u8_11<<8) | (u8_10<<10) | (u8_9<<12) | (u8_8<<14) | (u8_7<<16) | (u8_6<<18) | (u8_5<<20) | (u8_4<<22) | (u8_3<<24) | (u8_2<<26) | (u8_1<<28) | (u8_0<<30)
*(uint32_t*)0xc80b0044=u8_17 | (u8_16<<8) | (u8_15<<16)
The bits are not masked before the OR operations, which explains why I found scale bits somewhere else. The 18 bytes are followed by 6 halfwords (which don't overlap like the first bytes can).

One more finding: there is an additional memory range that the Zico core sees: 0xBFF1xxxx. It contains a few kB of interface functions that write to MMIO. I had to memcpy it out using Zico side code as that range is inaccessible from ARM. Strangely, I can't find that code in the ROM dump(s) and I also couldn't find a piece of code that would fill it. So, it's either stored compressed/scrambled, or it's on-chip ROM.
« Last Edit: Today at 17:47:14 by srsa_4c »

 

Related Topics