Fourpack collection

Hi all,

I want all those fantastic program in my DSO so I have made a “four pack” collecton. The idea came from jpa and gabonator excellent works. Those 2 programs (alternative UI and Pawn) already take one slot only so all I made is just sliced two other oscilloscope firmware.
The attached file contains these:
PV110-1X.HEX: Plus A1 version. Changed all “kilo” prefix and all “sec” to small caps. Removed 8M flash support. Linked for Slot 1.
WCAT-2X.HEX: Latest (3.1) community firmware from wildcat. Kilohertz and secundum fixed. Linked for Slot 2.
GABOUI-3.HEX: gabonator’s alternate UI. Reduced code size (-sdk) and the extra rom space by 64K. Also removed some user application (those that requires extra HW). The freed 2*32K space is used for the other scope firmwares.Linked for Slot 3.
For completeness, here is the programs for Slot 4:
PWN011-4.HEX: jpa’s Pawn environment, linked for slot 4. I just removed the alternate BIOS from the HEX file.
ALT-04s.HEX: The alternate SYS152 file from jpa, patched all “KHz” and “S” to “kHz” and “s”.

Hope someone will find this useful.
Fourpack-20140214-src.tar.gz (3.32 MB)
Fourpack-20140214.tar.gz (347 KB)

thats nice - thanks!

Hi. I have just got my Quad and would like to know if your Fourpack will work on it. It currently has 2.72 and is an 8MB version…
From what I have been reading I understand that the 8MB models have some problems with upgrades… Is your compilation OK to use on 8MB?

Sorry, it’s for 2MB only.

OK. Thanks. Ive heard Gabo’s alternative FW works on 8MB but there’s a problem with the save…?
I may try this one.
Thanks again,

Does that work for 8MB version? If not then is there any roadmap on how to do it so I could try to do it myself?

I started to look at this but am away at the moment and can’t progress it for a couple of weeks.

I think there are two basic approaches that can be used after the basic fourpack compiles are working. The first is to restore the original 8M code into the main App and then apply the other 8M fixes that are on here into the other Apps. The basic fourpack memory model then applies

The second and better way is to use the 8M support that is in AlterBIOS to provide the fille services. That should be straightforward for the Standard apps but is more complicated forGabonator which has the same fatfs code built in that AlterBIOS uses. It would be best to change the Gabonator internal calls like fread fwrite to call the corresponding function in AlterBIOS. There is already an API for this.

The second method means the Apps don’t have to be 2/8M aware and I think also could save some RAM buffer space.

for the original minidso PLUS V1.10 program an
#define EN_FLASH_8M
line in top of the defs.h file should restore the 8M program codes.
Similarly, you can re-enable the license checking code snippet with defining LICCHK.

Thank you for this!

and please keep it updated once in a while…



Is there an actual version of this great pack? I mean, e.g. with wildcat’s latest firmware 3.3. Unfortunately I’m not able to compile it myself.

By the way, does anybody know if gabonator’s fantastic alternative firmware is now 100% complete (on github it sound like it is not)?


OK, here is Wildcat’s firmware, recompiled/sliced to fit to extra slots.
WCAT33-1 for slot1 and
WCAT33-2 for slot2.

  • changed all KHz to kHz and ‘S’ to ‘s’ (Siemens to seconds)
  • also changed ‘db’ to ‘dB’ (deci??? to decibel)
  • redeclared Delay_Cnt as unsigned so (Delay_Cnt>0) now has meaning (calibration didn’t work because ot his bug).

Gabonator’s firmware:
I processed this at 2014-Feb-08, at that time wirebadger’s fork was the latest. Now the newest program that includes the 8MB patches is another fork, not based on wirebadger’s one.
I had a lot of work with this program. Frankly, I don’t know if I would want to do it again. (144 KB)
wildcat33-4pack-src-20140818.tgz (1.35 MB)

Looking at your source code, I believe that what you mean is that you re-declared Delay_Cnt as a SIGNED, not an unsigned.
It WAS declared as an unsigned, always has been that way from the original authors of the firmware, has never been changed,
and to my knowledge has never caused any issues.

Just exactly what part of calibration is/was not working because of this “bug”? Delay_Cnt’s purpose is as a counter for the
Delayms function and a countdown for the keystroke time selection delays, all of which to my knowledge are working fine.

I will grant you that it probably makes more theoretical sense to declare it as a signed, since unsigned vars can “roll under”
if brought below zero and cause problems, but they DO go to zero, and CAN be tested as such. As used here, I see no part
of the program that can force it to go below zero. The TIM3_IRQHandler is the only function that can decrease this variable,
and it resets it to 0 any time it’s 20 OR less, otherwise decreasing it by 20, so the original author certainly was aware of
potential problems and took care to avoid such.

I will also grant you that I have not recalibrated my devices for some time, so if there are any problems with calibration
could you be more specific? I would rather like to avoid drudging through the entire calibration procedure to check this out…

By the way, I appreciate your work in splitting the programs, very useful.

Well, it seems I was a little premature.

Yes, it was a typo.

Here’s the story: After the 1st compilation I quickly checked the functions and realized I can not enter to Calibration. No matter how long I pressed KEY2 button, there was no 3rd beep and releasing the button always went to Manual trigger (which is after the 2nd beep).
Then I looked the source and found that the loop which checks Delay_Cnt probably never ends.
<------> while ((Delay_Cnt >0)&&(Delay_Cnt <=2500)){<-><------><------><------><------>// long press^M

Then I found the Delay_Cnt variable and its dangerous usage.

Yes, but it’s still dangerous, a potential trap. “As used here”, this is the keyword. You have to look after from now on. The best avoid is never give the chance to malfunction.
Anyway, I had a problem, I was in hurry and it was faster to recompile the program than doing a deeper analysis. So I did it and voila! It worked.

I thought I solved the problem.
Now I’m not sure anything.

I’ve recompiled your code with unsigned counter, again. Yes, it works properly.
Now I’m not sure anything.
Sorry to suspect you.

No problem…

The wait time for hold to engage on this function is 3 seconds as opposed to 1 1/2 seconds for all other
functions. You stated “no matter how long you pressed”, is it possible it was not held long enough?
You also stated that it’s now working ok, so I assume you are aware of the longer wait…

There is not much going on in the program at this time, just a loop waiting for the button to be released
and the interrupt decreasing the count. I checked things over, and can’t think of anything else that could
have caused this without causing other obvious problems.

I really don’t know what to think. I tried several times, waiting longer and longer. I didn’t count, just felt it was way more longer than it should be.
After recompilation it appeared to be fixed.

I can’t explain it so I just move on…