It would definitely be nice to have a circuit diagram, wiring in an ATtiny is something i would be willing to do for the sake of custom modes.
While mucking around in the driver, replace those LM358 op-amps in the current sense circuit with something like a LT1466 micro-power op amp… they draw about 1/10 the power and should cut the parasitic battery drain way down.
ATTiny13A with Power down mode when off + port pin to control power to OpAmps via tiny P-channel FET will reduce parasitic drain.
ATTiny can be wake up from external interrupt (button)
Anyone already identified the MCU ? it has no any markings. looks like chinese MCU
I don’t really have SMD soldering equipment, just a normal soldering iron with a 1mm round soldering tip, so I’ll just replace the MCU and leave the rest as is.
I made a 1st version of the new firmware (“kingdrv”) with just the basic UI. It distinguishes between short taps (“S”, <0.2s), long taps (“L”, 0.2s … 0.6s) and hold (“H”, >0.6s). Flashlight operation is based on tap sequences like for example long-long (“LL”), short-short-short (“SSS”) or just “S” or “L”; sort of Morse-style. Hold does nothing yet but will do ramping later.
There are 2 main mode groups and an extended group. In each group the last used mode is remembered.
The commands implemented so far:
S: on/off
L: next mode (within group)
SL: previous mode (within group)
SS: switch to other main group or return to main group from extended
LS: go to extended group
There are some commands that directly lead to extra modes:
LL: high
SSS:strobe
SSL:beacon
SSSSS: momentary mode; exit by SSSSSS
From those extra modes (except momentary) L,SL,SS return to the last used main mode.
This is how far it works on my test board currently; I have yet to solder the MCU to the King and test it there.
Planned are Ramping, battery monitoring, temperature monitoring, some more fancy/fun modes (I’ll add some “secret” modes, too) 
nice project
me subscribed
Actually, you could probably just power the op-amps from a port pin. Those LM358’s draw less than 1 mA each (the CMOS op amps less than 100 uA).
It should be easy to just lift pin 8 (the corner pin) of the op-amps and run a wire to a pin on the micro.
got some ATtiny’s on order in anticipation of this.
Brian
I've got a couple sitting around for the same anticipation months ago. The good doctor sure took his own sweet time 
lol. well i just got my light the other day so i havent been waiting quite as long.
Brian
I will probably end up getting another one, mayhapse even 2. They work really well as photography lights when mounted to umbrella’s
Soldered out the original MCU, connected an ATtiny via some wires, works.
Got a strange flickering on medium levels, also on my test board; have to investigate.
Added “programming”, i.e. change mode config, via two tap sequences.
I definitely share in your feel about this
King uses QX9920 buck driver. there is no output capacitor. may be this can cause flicker. try to put caps and check
how you setup PWM ? stock MCU driving each emitter (driver) separately by 3 outputs. 10K series resistor & 30K to ground.
What PWM rate are you using? Perhaps the QX chip does not like fast PWM’s (of so that could be why the SRK uses a 200 Hz PWM).
flickering can be cause due to MCU reset itself/brownout detect when heavy load current.
I also faced this problem with breadboard test (not SRK. )
problem fixed after putting large cap for MCU power line.
Found the problem; it was due to slightly different frequencies of the PWM outputs causing a beat frequency of 16 Hz.
Now that this issue is resolved, I'll further work on implementing more features (ramping, battery and temperature monitoring, fun stuff).
I use 4kHz PWM.
are you using separate 3 PWM outputs for each LED driver ?
how about combine 3 into one PWM output ?
By using independent signals to PWM the drivers, you can drive each one out of phase with the other two. That way only one LED is on and driving power at a time. That should make the run time longer because the batteries will be more lightly loaded. Frankly, I’d be surprised if the Chinese would implement such sophistication, but why else would they use three separate driver enable signals?