Great to know that you made some improvements.
BTW, the Rigol MSO5000 has Zone Trigger which is very useful. I haven't found Zone Trigger on DHO4000 yet. Is it possible to have Zone Trigger on DHO800/DHO900?
There is a dead (unused, because other code doesn't execute it) code for zone trigger.
To test it and eventually put this into usable code, I need:
1. Change code in Assembly. While binary is compiled and I don't have source code, I can't just add something. I can only change existing machine code. For example, if there is a compiled function with switch-case, I just can't simply add another case, because I will overwrite next function or something else - in compiled binaries all functions takes constant size, one after another and there is no free space.
Because of mentioned lack of source code and other limitations, I need to change one single CPU instruction at the beginning of function to a jump into unused code (at way different memory address). In this unused code I need to make a some condition in machine code (kinda Assembly but I can only modify what is already - small mistake in the middle can force me to make a half of it from scratch, which can take hours of work).
2. After making temporary changes, I need to test it.
At first I need to pray, to not have any crash caused by SIGSEGV or any other problem that will require a lot of time to diagnose and to fix small mistake. Mistakes are extremely easy to do, when dealing with executable binary without source code. I know in C (or C++ which I hate) this is extremely harder to make mistake and extremely easier to fix, but I will repeat once more: I don't have source code, only compiled binary, so this is not the case. Maybe someday there will be somebody brave to (somehow) take source code from Rigol, but I have some doubts about that.
I can't say if making this test code will take 15 minutes, 15 hours or 15 days. Because I don't know how many problems I need to face. This is almost like dealing with the extremely big electronic device without schematics and no documentation - You can never know.
Lets say I finished temporary code and it works. Now I need to pray to be any support in FPGA firmware for this trigger and to be working properly. Hacking compiled FPGA binary firmware is at completely another level - so either it will work or it will not and I lost a lot of my time with nothing in return. I never heard of anybody doing FPGA firmware hacking (personally I tried to achieve more than 134 Mpts which is the current maximum, but it was too much time consuming).
One bright side is: FPGA firmware from DHO4000 works 100% properly on my DHO924S, at least what I tested. Only difference I noticed, is when I call unused function that takes some data - in both firmwares it gives slightly different data, but as I said, it's unused anyway. So if one will not work, I can pray for FPGA firmware from DHO4000.
Lets now say, it looks like it's working (which I will repeat - it's not guaranteed). Now I need to test if that change breaks anything, like other triggers, LA, AFG or self-calibration - this last one is the most annoying when it's not working, because testing fixes, requires to run self-cal again and again, which everytime it takes half hour. Not only highly time consuming but also very boring.
Lets say, we had luck and everything looks good. Now I need to create new code for UI to set-up this trigger by regular user (instead of temporary hacks). I need to make almost everything from scratch, every button, switch or input with values to setup from keyboard with limits set appropriately to current conditions. Normal user doesn't see this, unless something doesn't work properly - in such cases what I can only hear are complaints, as if I did it on purpose...
Anyway, to do UI changes, I need to deal with much more annoying languages. Exactly Smali and Android layouts. Believe or not, but whole Android system was made by idiots (Google, You can sue me, Im waiting.). Android become popular, because of marketing and Android-Studio, which is software that allows most stupid people on earth to make an phone app. But this (extremely slowly) generates code that is very far from being professional or easy to maintain. And when You don't have original files that Android Studio created (beside of only apk file, which we all have), it becomes much more difficult to make any changes, often including changes that can look extremely easy to make for somebody who is not a programmer.
There is a lot of people who told me how usable is my mod and how many other changes they want. But try to take one minute and look at another side, which is me. If somebody wants to have some extremely useful functionality, optimizations (everything working 5x faster), bugfixes or any other changes, don't expect to somebody seating one month and doing this for free or half-free. Either do it by Yourself or become a supporter. Currently what I see, support 3$ per moth is too much for most people, but in same time there is a hundreds of users of this series who wants my mod and future changes.
If those things, will not change, upcoming v0.3.2 will be the last release, at least with a new features/optimizations. I just don't want to spend another months doing something that gives almost nothing in return. Hacking existing software without source code is not like a black magic in Hollywood movie, when somebody screams hocus-pocus and suddenly there is a palace.
Finally answering Your question, there is a chance to make it work. But if I will still have so small support as it is today, I will start doing something completely else.