the ,,mode" byte & eeprom use #3

sueppchen · 2024-04-14T07:56:46Z

          I adopted your tables into my script and... used mod=2:

when message arrives, eeprom is read. in my case
mode=0 --> normal operation
mode seems to be divided into bits:
bit0: unknown
bit1: is memory mode

memory mode:
byte 2 = 0xEESSSS (end end start start start start)
maybe the missing 2 End-bits are coded into mode itself
byte 3 = Attack + random
byte 4 = release + hold
byte 5 = unknown changing the value has no effect
byte 6 = same like byte 5
byte 7 = could be group
there are 16 memorys each containing 4 bytes from 0x10 to 0x4F
it is always played from start to end (if start is after end all 16 are played)

when you get mode 4 working, you could reverse the byte5 and byte7 table values - because its not group and random anymore

Originally posted by @sueppchen in #1 (comment)

The text was updated successfully, but these errors were encountered:

Serge-45 · 2024-04-14T12:17:39Z

New kind of message, with MOD=4, it activates a double-color short flash : a very short Color1 lightning immediately followed by a short Color2 lightning :
<CRC1, MOD=4, Green1, Red1, Blue1, Green2, Red2, Blue2, CRC2>
It seems that we can only select the two colors, but not the attack, duration or release.
The same CRC rule applies on each of the bytes, even if they have a different meaning.

Serge-45 · 2024-04-14T12:20:41Z

It seems that "mode" is only on the 4 lower bits of byte 1. Setting the 2 higher bits of first byte has apparently no effect.

sueppchen · 2024-04-14T12:20:58Z

mode bit1 = play from memory
mode bit2 = two color mode
mode bit4 = one shot mode (rise, hold, release ... stay black until other message arrives)
mode bit5 = does nothing change

Serge-45 · 2024-04-14T12:27:46Z

Interresting : in mode=2, reaction time (from end of message transmission to first change on LED outputs) is much faster (<0.6ms) compared to mode=0 (about 8ms when no attack ramp).

Serge-45 · 2024-04-14T19:17:54Z

Mode = 0x10 => same as mode 0x00 but with a "no-repeat". If the exactly same message is received a second time, it is ignored.

Serge-45 · 2024-04-14T19:32:53Z

Mode = 0x11 = "LOOP" => same as mode 0x00 but effect is automatically repeated until next command

Serge-45 · 2024-04-14T19:42:10Z

mode = 0x12 => same as 0x02 with the no-repeat feature

Serge-45 · 2024-04-15T19:36:27Z

As a summary :

  mode = 00?xxxxx, where xxxxx is :

    standard flash modes - < mod, G, R, B, attack/random (AAArrr), release/hold (RRRHHH), group >
    0x00 = 00000 - standard
    0x10 = 10000 - no repeat
    0x11 = 10001 - loop

    double flash modes - < mod, G1, R1, B1, G2, R2, B2 >
    0x04 = 00100 - standard
    0x14 = 10100 - longer flash

    EEPROM modes - < mod, End/Start (EESSSS), attack/random (AAArrr), release/hold (RRRHHH), ??, ??, group >
    0x02 = 00010 - standard
    0x12 = 10010 - no repeat
    0x13 = 10011 - loop

sueppchen · 2024-04-15T22:04:44Z

in my case the speed in mode=4 is the same like the packets are send. (40ms)

sueppchen · 2024-04-16T13:05:00Z

ah, I understand what you mean with loop:
when loop-bit is set, the batch continues playing the last instruction even without an RF
it is the ,,go home from concert" - mode

Serge-45 · 2024-04-16T17:14:07Z

Yes, when "loop" is activated, playing continues. In case of EEPROM, each successive memory position is played up to END and then it restarts from START.

Serge-45 · 2024-04-16T17:14:38Z

No able to activate a "double flash" + "loop" mode...

sueppchen · 2024-04-16T22:20:15Z

I think double flash needs the timing of the data-input to switch between the two colors loop mode doesn't need that data in, so loop would not work with double flash.

sueppchen · 2024-04-17T22:19:30Z

loop-Mode is a permanent mode: when activated it stays active even when power is cycled.
it writes to eeprom @0x04 = 0x11 when started
then writes checks and updates the values from 0x50 to 0x57
--> see /eeprom/readme.md

when a new message arrives eeprom 0x04 is written back to 0x00

loop mode does not use random (values are ignored)

mem mode has special byte-order:
byte 6.5 = random.0
byte x.x = random.1 (havn't found that byte yet... it is always 1 - maybe a mode-bit)
byte 2.2 = random.2

byte 1.0 = start.0
byte 1.1 = start.1
byte 1.2 = start.2
byte 1.3 = start.3

byte 1.4 = end.4
byte 1.5 = end.5
byte 2.0 = end.6
byte 2.1 = end.7

some values of mode do not give a valid checksum... maybe the message length is longer or shorter for that modes.
EEprom-write would need only 5 bytes payload. not checked yet.

Serge-45 · 2024-04-21T08:37:55Z

Something is hapening with MOD = 0x0f, a flash is emitted with :
0x0F, 0x00, 0x30, 0x00, 0x02, 0x01, 0x00 (adding valid CRC before and after)
I guess it is related to EEPROM locations. As I haven't connected EEPROM line, I cannot monitor what is going on.
Another message is setting the background color :
0x0F, 0x00, 0x30, 0x20, 0x10, 0x00, 0x00 (adding valid CRC)

sueppchen · 2024-04-21T14:58:43Z

the first message is reading @0x01 ( value 0x00) and @0x08 (0x01)
this is maybe a set group (with blue confirm) because this is part of the startup-reading.
but i can't alter that message to another value yet.

the second message does not use the eeprom. It displays magenta which would be the normal mode0 behavior (except it is another mode)

Serge-45 · 2024-04-21T16:21:56Z

Exploring the mode=0x0F, the byte 6 seems to specify a kind of sub-mode :

  // 0x0F, GGGGGG, BBBBBB, RRRRRR, 00????, 0x00, ??????  // mode F/0, 6-bit colors
  // 0x0F, GGGGGG, BBBBBB, RRRRRR, 01????, 0x00, ??????  // mode F/0, 6-bit colors background
  // 0x0F, rrGGGG, BBBBRR, ??????, 01????, 0x01, ??????  // mode F/1, 4-bit colors (rr is LSB, RR is MSB)
  // 0x0F, rrGGGG, BBBBRR, ??????, 01????, 0x02, ??????  // mode F/2, 4-bit colors (rr is LSB, RR is MSB)
  // 0x0F, ??????, ??????, ??????, ??????, 0x03, ??????  // mode F/3, no reaction
  // 0x0F, ??????, ??????, ??????, ??????, 0x04, ??????  // mode F/4, no reaction
  // 0x0F, ??????, ??????, ??????, ??????, 0x05, ??????  // mode F/5, no reaction

sueppchen · 2024-04-21T17:01:39Z

ok, mode 0x0f is eeprom-write-mode:

message = 0x0f,green, red, blue, memLocation, Sub-mode?, group
it is possible to store custom messages to the 16 internal locations.
they are stored: location = 0x10 + (memLocation<<3)
eeprom[location+0] = (green<<2)
eeprom[location+1] = (red<<2)
eeprom[location+2] = (blue<<2)
eeprom[location+3] = ((green<<2) + (red<<2) + (blue<<2)) & 0xff

it shows the simplicity of internal checksum generation and that the values are internal shifted left by 2

sueppchen · 2024-04-21T19:55:17Z

each batch has 8 group memories which can be predefined and switched easy during the show.
in eeprom bytes 0x08 - 0x0f the group number 0x00 - 0x1f is stored
this bytes are written by
mode = [ 0x0f, rrGGGG, BBBBRR, location, value, (subMode = 0x02), group ]
location is internal cut to 0-7 (by & 0x07) and add by 8
value is internal cut to 0-0x1f (by & 0x1f)

to write Master Group (tell the batch witch memory is active) a write operation to eeprom byte 0x01 has to be done:
mode = [ 0x0f, rrGGGG, BBBBRR, value, {don't care}, (subMode = 0x01), group ]
value is internal cut to 0-7 (by & 0x07)

after success the group-value from corresponding eeprom-register is read back and set.

the color-information is only to show success: it is activated after all write and read operations are done

sueppchen · 2024-04-21T20:53:27Z

a few bytes eeprom are missing... (but some are read @startup)
0x00 = 0x0d if that byte is changed to 0x0c everything is set to default
0x02 = 0x00
0x03 = 0x01 / 0x02 --> it must be able to set this byte
0x05 = 0x00
0x06 = 0x00
0x07 = 0x00

Serge-45 · 2024-04-21T21:08:13Z

(wrong assumption removed...)

sueppchen · 2024-04-21T21:58:56Z

aaaawwww... no.
we have 16 memory slots for colors (read by mode 0bxxxx1x )
we have 8 memory slots for group

sueppchen · 2024-04-21T22:02:35Z

group is ... imagine you have 32 different wristband-,,fixtures" of crowd in a stadium, each block can have its own color or fx - so it is possible to let a rainbow cycle over all pixelgroups.

Serge-45 · 2024-04-22T05:57:54Z

Ok, got it. Thanks !
Updated summary (let me know if incorrect) :

  // EEPROM map
  // 0x00 - 0x07 : control registers
  //    0x00 : 0x0d, if that byte is changed to 0x0c everything is set to default
  //    0x01 : 
  //    0x02 : 
  //    0x03 : 
  //    0x04 : 
  //    0x05 : 
  //    0x06 : 
  //    0x07 : 
  // 0x08 - 0x0F : 8 slots for Group# (set by mode 0F/01, selected by mode 0F/02)
  // 0x10 - 0x3F : 16 locations for predefined colors (set by mode 0F/00)
  //    0x10 - 0x17 : color#0
  //        0x10 : green << 2
  //        0x11 : red << 2
  //        0x12 : blue << 2
  //        0x13 : checksum = ((green<<2) + (red<<2) + (blue<<2)) & 0xff
  //        0x14 - 0x17 : ???
  //    0x18 - 0x1F : color#1
  //    ...
  //    0x38 - 0x3F : color#F
  //
  // Summary of Mode 0x0F messages :
  // 0x0F, GGGGGG, RRRRRR, BBBBBB, 00LLLL, 0x00, ?group  // mode F/0, store 3x6-bit color at location L
  // 0x0F, GGGGGG, RRRRRR, BBBBBB, 01????, 0x00, ?group  // mode F/0, 3x6-bit background color
  // 0x0F, rrGGGG, BBBBRR, ???SSS, ?GGGGG, 0x02, ?group  // mode F/1, store group value at slot S, 3x4-bit color for acknowledgement (rr is LSB, RR is MSB)
  // 0x0F, rrGGGG, BBBBRR, ???SSS, ??????, 0x01, ?group  // mode F/2, select active group slot S, 3x4-bit color for acknowledgement (rr is LSB, RR is MSB)

Serge-45 · 2024-04-22T06:12:43Z

And by the way, I've found the missing 2 bits for the End location of EEPROM read, they replace the Random value :

  // 0x13, eeSSSS, AAA?EE, RRRHHH, ??????, ??????, ?group  // EEPROM loop read from location SSSS to EEee, with usual Attack/Release/Hold parameters (no random)

Serge-45 · 2024-04-22T06:23:28Z

Question : where is stored the background color set by mode F/0 with location=01???? ? The 4 bits of location address seem to be ignored...

sueppchen · 2024-04-22T06:35:26Z

Question : where is stored the background color set by mode F/0 with location=01???? ? The 4 bits of location address seem to be ignored...

it is not stored... as there is no eeprom use with that command. and after power cycle the information is lost.

I updated the readme yesterday evening. have a look at /readme.md and at /eeprom/readme.md

sueppchen · 2024-04-22T09:26:46Z

updated readme and wiki

sueppchen · 2024-05-20T20:27:38Z

yes, did some testing... no result for 0x02
this is only true for 0x02 / xx and only the lower 3 bit are used.

for 0x03 I have no idea yet

sueppchen · 2024-05-20T20:40:10Z

here the values of 0x03 are little different...
mode 0x0F:
0f xx xx XXXXXX ????YY 08 00

0bYYXXXXXX to adress 0x03

Serge-45 · 2024-05-20T20:46:00Z

Mode 0x0f / submode 0x0f is also playing with the EEPROM

sueppchen · 2024-05-20T20:51:24Z

it seems to be deleting all values @0x02 and 0x03 to zero

sueppchen · 2024-05-20T21:12:16Z

wiki updated...

sueppchen · 2024-05-22T20:47:21Z

have you found the missing bit in memory play mode?

mem mode has special byte-order: byte 6.5 = random.0 byte x.x = random.1 (havn't found that byte yet... it is always 1 - maybe a mode-bit) byte 2.2 = random.2

byte 1.0 = start.0 byte 1.1 = start.1 byte 1.2 = start.2 byte 1.3 = start.3

byte 1.4 = end.4 byte 1.5 = end.5 byte 2.0 = end.6 byte 2.1 = end.7

sueppchen · 2024-05-22T22:55:20Z

library is updated with all store/recall/send stuff except the unknown bytes

Serge-45 · 2024-05-23T12:35:49Z

I did some extra testing using mode 0x13 and checking how this command is stored in EEPROM[0x50-0x57]:
What I originally had:

< mod, End/Start (EESSSS), attack/random/End (AAArEE), release/hold (RRRHHH), random (???rrr), ??, group >

What I finally found:

< 0x13, End/Start (EESSSS), attack/random/End (AAArEE), release/hold (RRRHHH), ??, ??, group >
    - only 1 bit for coding randomness
    - no effect coming from the two last bytes before group
    - special behaviour when hold=7
Stored in EEPROM as:
     0x53 - attack 0, 2, 6, 12, 30, 60, 150, 240 (0x00, 0x02, 0x06, 0x0c, 0x1e, 0x3c, 0x96, 0xf0)
     0x54 - hold 0, 2, 6, 12, 30, 60, 150, (hold=7 has a special meaning, stored here as 30)
     0x55 - release 0, 2, 6, 12, 30, 60, 150, 240 (0x00, 0x02, 0x06, 0x0c, 0x1e, 0x3c, 0x96, 0xf0)
     0x56 - from mem 0-f to mem 0-f = 0bfffftttt
     0x57 - random = 0x02 + (0x06 if bit r is set) + (0x20 if hold=7)

Other memory play modes (0x02 and 0x12) have most probably the same syntax, but it's more difficult to test as they are not stored in EEPROM[0x50-0x57].

sueppchen · 2024-05-28T21:45:03Z

I checked with a logic analyzer... group bit 5 is random on mine...

ok, hold 7 does write the random byte ... special.

does the eeprom 0x02 and 0x03 have some effect?
and - is background color stored in go home mode?

Serge-45 · 2024-05-29T18:39:52Z

Hi,
I've just received a USB logic analyzer I ordered from the UK. I'm using it with PulseView. That's really great, much easier for testing!
Pixmob is full of surprises: I discoverd that there are in fact 3 phases on the dual-flash. 1st color for 25ms, then second color for 210ms (or 500ms if mode 0x14), and then a 16ms short phase with 2nd color but lesss bright... It's like having a RELEASE = 1.

sueppchen · 2024-05-30T18:21:00Z

I checked it here again and there is no difference between mode 0x04 and mode 0x14

it is locked to RX here. and all brightness is the same

sueppchen · 2024-05-30T19:00:12Z

byte 0x02 and 0x03 do not change anything here

cra0 · 2024-05-31T06:19:58Z

Hey I just found this I'm doing my own research into this.
I wrote a flasher for the eeprom using the Pico.

Serge-45 · 2024-05-31T17:14:45Z

I checked it here again and there is no difference between mode 0x04 and mode 0x14

it is locked to RX here. and all brightness is the same

Here is what I get with a dual-flash (0x04) having (0x30,0x30,0x30) as the second color. 16ms before the end, there is a change in the PWM duty cycle from 48% (consistent with brightness 0x30) to 13% (similar to a RELEASE=1) :

Serge-45 · 2024-05-31T17:34:09Z

Most of all changes in PWM cycles happen every 16.2ms. The HOLD time is always multiple of 16.2ms. Let's name T this 16.2ms period :

Mode 0x00 standard flash :
- ATTACK and RELEASE values 1, 2, 3, 4 => give timing 1T, 5T, 11T, 26T
- HOLD values 1, 2, 3, 4 => give timing 3T, 7T, 13T, 31T
Mode 0x04 gives the timing : 1.5T (color 1), 13T (color 2) equivalent to HOLD=3, 1T (release of color 2) equivalent to RELEASE=1
Mode 0x14 gives the timing : 1.5T (color 1), 31T (color 2) equivalent to HOLD=4, 1T (release of color 2) equivalent to RELEASE=1

Serge-45 · 2024-05-31T19:30:36Z

Hi cra0 ! Welcome here !
Check the Wiki, most of the bytes of the EEPROM have been identified, but some others not... For example bytes at address 0x02 and 0x03, any clue would be welcome !
In your dump, I can see that you have 0x09 as the very first byte (addr 0x0000). Surprising as we have 0x0D instead. What model type is the PIXMOB you got ?

Serge-45 · 2024-06-01T14:12:41Z

Stored colors & checksum

The 16 colors are stored in the EEPROM starting at address 0x0010, each color uses 4 bytes:

green << 2
red << 2
blue << 2
checksum = ((green<<2) + (red<<2) + (blue<<2)) & 0xff

What if the checksum is incorrect when a "read from EEPROM" command is received?

the MCU ignores the 4 bytes just read if the 4th byte (checksum) is incorrect
the MCU reads 4 new bytes starting at address+3 and check the new checksum read
if checksum is ok, use this color
if not, MCU reads 4 new bytes starting at address+6 and check the new checksum read
if checksum is ok, use this color
if not : abort, do nothing.

Note: if the wrong checksum is on the 16th storage location (0x004c), the MCU continues to read above address 0x0050 which is not intended to contain colors values.
This raises a few questions:

why storing a checksum? Is there a big risk of data alteration in the EEPROM?
why trying to read another color at address+3 and not at address+4 which would be more logical ?
why storing the value<<2 instead of the value itself (the 2 lower bits do not seem to have any effect when directly set into EEPROM) ?

sueppchen · 2024-06-01T14:21:34Z

I think they store something to be in 4 byte count. because 4 is more easy to handle and to calculate than 3 (shifting)
probably the firmware has some bugs... which never be fixed because the scenario would not occur in normal situation

they store value<<2 because I think the internal process is to receive the values, then convert it and then do something with it... the conversion is made in input function and not in output to save time. because of that the Attack hold release values are translated from 0-7 virtual values into real 0-255 byte values

sueppchen · 2024-06-01T14:25:20Z

I checked it here again and there is no difference between mode 0x04 and mode 0x14
it is locked to RX here. and all brightness is the same

Here is what I get with a dual-flash (0x04) having (0x30,0x30,0x30) as the second color. 16ms before the end, there is a change in the PWM duty cycle from 48% (consistent with brightness 0x30) to 13% (similar to a RELEASE=1) :

which values do you send exactly? at which refresh rate and did you change anything in eeprom? so I will try to reproduce the behavior here with the double flash mode or find what is the difference to do demystification of that mode.

sueppchen · 2024-06-01T14:38:56Z

your pic is measuring on the wrong edge of pwm... it starts with rising edge so there is no fade, it is a jump.

Serge-45 · 2024-06-01T15:11:00Z

your pic is measuring on the wrong edge of pwm... it starts with rising edge so there is no fade, it is a jump.

Yes, the PWM cycle starts with a HIGH and then a LOW, and the active state is LOW (LED is on). I cannot do this setting with my logic analyzer, I can only choose active LOW or HIGH and it considers always that the active level is first and inactive is second in the cycle. This doesn't change the duty % calculation except right at the time of the change. But if you look at few cycles before and a few cycles after the 16ms mark, there is a difference.

Serge-45 · 2024-06-01T15:18:31Z

I checked it here again and there is no difference between mode 0x04 and mode 0x14
it is locked to RX here. and all brightness is the same

Here is what I get with a dual-flash (0x04) having (0x30,0x30,0x30) as the second color. 16ms before the end, there is a change in the PWM duty cycle from 48% (consistent with brightness 0x30) to 13% (similar to a RELEASE=1) :

which values do you send exactly? at which refresh rate and did you change anything in eeprom? so I will try to reproduce the behavior here with the double flash mode or find what is the difference to do demystification of that mode.

Using {0x04, 0x30, 0x20, 0x20, 0x20, 0x20, 0x30}, I get a 251ms effect:

Using {0x14, 0x30, 0x20, 0x20, 0x20, 0x20, 0x30}, I get a 542ms effect (time scale is not the same on the graph):

Sampling is at 8MHz. I did so many things with EEPROM, I cannot say if I changed something causing that. Your test will be interesting for comparison.

Serge-45 · 2024-06-01T15:35:29Z

your pic is measuring on the wrong edge of pwm... it starts with rising edge so there is no fade, it is a jump.

OK, got your point. No real fade just a change of duty % on the rising edge. The intermediate value shown is fake, just created by the logic analyzer.

cra0 · 2024-06-06T02:34:50Z

Do you guys have a discord or IRC/IM to chat about this in real time.
I have made a tool to dump the EEPROM using a PI PICO if it helps anyone:
https://github.com/cra0/Pixmob-IR-Reversing/releases/tag/release1

@Serge-45 I have the VIC model
Image

sueppchen · 2024-06-10T19:22:53Z

@cra0 remember... pi PICO has only 3.3V tolerant input pins...
also this is pixmob RF version development, so I am not shure if everything will work with the IR version.
for that try Daniel Weidman's repository .

edit: link added

sueppchen · 2024-06-10T20:28:39Z

@Serge-45 have a look at the manual of the transmitter there are some things to find:

firmware readout...
reset

Serge-45 · 2024-06-12T12:12:43Z

@Serge-45 have a look at the manual of the transmitter there are some things to find:

firmware readout... reset

I searched for such a manual but was not able to find it. Great ! Yes, some more commands to discover. I think that this manual refers to some older revisions of the PIXMOB as some advanced features are not described (group settings, random, background color...). I'm not sure about the "impact mode", maybe the double flash mode ?

sueppchen · 2024-06-12T20:52:10Z

impact mode is maybe for receivers that have an IMU attached. there are some with infrared which recognize a handclap.
the cement1.1 does not have an IMU.

it is also possible to get the battery level or to set the timeout... hmm, eeprom 0x02 or 0x03 ?

https://user-images.githubusercontent.com/6167947/208201576-fb3d5d79-1454-4e71-af5f-e3e55a69fb99.png

sueppchen · 2024-06-12T22:13:41Z

eeprom 0x02 could be the timeout after data loss. it changes between 60 sec when set to 0 and 120 sec when set to 0xf0

impact mode is maybe what we call one-shot-mode

sueppchen · 2024-10-13T21:05:49Z

found ... https://github.com/jamesw343/PixMob_IR/blob/master/docs/ir_protocol.md
and https://github.com/jamesw343/PixMob_IR/blob/master/docs/eeprom.md

which are IR versions but share many...many similarities with the RF version

sueppchen added enhancement New feature or request help wanted Extra attention is needed labels Apr 23, 2024

the ,,mode" byte & eeprom use #3

the ,,mode" byte & eeprom use #3

Comments

sueppchen commented Apr 14, 2024

Serge-45 commented Apr 14, 2024

Serge-45 commented Apr 14, 2024

sueppchen commented Apr 14, 2024

Serge-45 commented Apr 14, 2024

Serge-45 commented Apr 14, 2024

Serge-45 commented Apr 14, 2024

Serge-45 commented Apr 14, 2024

Serge-45 commented Apr 15, 2024

sueppchen commented Apr 15, 2024

sueppchen commented Apr 16, 2024

Serge-45 commented Apr 16, 2024

Serge-45 commented Apr 16, 2024

sueppchen commented Apr 16, 2024

sueppchen commented Apr 17, 2024

Serge-45 commented Apr 21, 2024

sueppchen commented Apr 21, 2024

Serge-45 commented Apr 21, 2024 • edited Loading

sueppchen commented Apr 21, 2024 • edited Loading

sueppchen commented Apr 21, 2024

sueppchen commented Apr 21, 2024

Serge-45 commented Apr 21, 2024 • edited Loading

sueppchen commented Apr 21, 2024

sueppchen commented Apr 21, 2024

Serge-45 commented Apr 22, 2024

Serge-45 commented Apr 22, 2024

Serge-45 commented Apr 22, 2024

sueppchen commented Apr 22, 2024

sueppchen commented Apr 22, 2024

sueppchen commented May 20, 2024

sueppchen commented May 20, 2024

Serge-45 commented May 20, 2024

sueppchen commented May 20, 2024

sueppchen commented May 20, 2024

sueppchen commented May 22, 2024

sueppchen commented May 22, 2024

Serge-45 commented May 23, 2024

sueppchen commented May 28, 2024

Serge-45 commented May 29, 2024 • edited Loading

sueppchen commented May 30, 2024

sueppchen commented May 30, 2024

cra0 commented May 31, 2024 • edited Loading

Serge-45 commented May 31, 2024

Serge-45 commented May 31, 2024

Serge-45 commented May 31, 2024

Serge-45 commented Jun 1, 2024

Stored colors & checksum

sueppchen commented Jun 1, 2024

sueppchen commented Jun 1, 2024

sueppchen commented Jun 1, 2024

Serge-45 commented Jun 1, 2024

Serge-45 commented Jun 1, 2024

Serge-45 commented Jun 1, 2024

cra0 commented Jun 6, 2024 • edited Loading

sueppchen commented Jun 10, 2024 • edited Loading

sueppchen commented Jun 10, 2024

Serge-45 commented Jun 12, 2024

sueppchen commented Jun 12, 2024

sueppchen commented Jun 12, 2024

sueppchen commented Oct 13, 2024

Serge-45 commented Apr 21, 2024 •

edited

Loading

sueppchen commented Apr 21, 2024 •

edited

Loading

Serge-45 commented Apr 21, 2024 •

edited

Loading

Serge-45 commented May 29, 2024 •

edited

Loading

cra0 commented May 31, 2024 •

edited

Loading

cra0 commented Jun 6, 2024 •

edited

Loading

sueppchen commented Jun 10, 2024 •

edited

Loading