I tidied up the logo handling. It will now save as bmp and requires bmp as input. The new version is attached.
The LZMA header is indeed as you say except for the file SparrowCalFile.hex, where compressed and uncompressed sizes are much different from the real ones.
4 is AA 55 55 AA (something spezial ?)
55AA is often used to verify that memory is working it's (every other bit)
01010101
10101010
IIRC correctly IBM PC add on roms required 55AA as the 1st two bytes to signal it was a real thing (and not just random data). But that was a loooong time ago
55AA is often used to verify that memory is working it's (every other bit)
01010101
10101010
IIRC correctly IBM PC add on roms required 55AA as the 1st two bytes to signal it was a real thing (and not just random data). But that was a loooong time ago
0x55AA also used to be widely used in older graphic file formats, where the byte order used by the writing and reading machines might be unpredictably different. I've forgotten what one was supposed to write (21930 or 43605), but whatever it was, if you read the other one back then you knew you had to byte-swap while reading the rest of the file. In recent, tagged (TIFF-based) formats, the byte order is still the file-writer's choice, but it is the file-writer's obligation to put an indicator (0x4D4D for big-endian, 0x4949 for little-endian) as the first 16 bits of the file header. The codes are ASCII for "II" (hinting at Intel, little-enders) and "MM" (hinting at Motorola, big-enders).
Logo customize option is working now.
So, we can close this thread.
Of course not. This is only beginning and may be there can be done something more useful.
But be careful with next steps and think about motto there:
"We don't like to break it - we like to make it better!"
and test your idea before and have repair or undo procedures
ready so you don't have many angry "brick" owners here.
Always is good idea to remove non working files from here too. Or what you think?
SparrowCalFile.hex consists of 420 individual LZMA streams concatenated together. Each one is 604 bytes long (uncompressed). I've only decompressed a few at random, but they don't look terribly interesting.
@smithnerd is there any documentation on this archive format? What tool did you use to decompress it?
Edit:
Sometimes it's just too obvious. Got it.
I was able to replace the start screen image (logo.hex) by the one attached.
......
I'm not a good artist but something like this is needed there
or old BW type : )
(I was growing up with this kind of round corners TV
http://mentallandscape.com/L_0249.jpg)
guiPicData.hex is a very simple format, which is easy to traverse.
A 4 byte header represents x and y dimensions for each image, followed by the RGB565 data.
uint16 x;
uint16 y;
char data[x*y*2];
So it's easy to calculate the offset of the next image. I make it 494 bitmaps in total. Once I figure out how to put headers on the data, I will post a thumbnail image.
Edit:
This seems clunky, but it works OK:
$ avconv -vcodec rawvideo -f rawvideo -pix_fmt rgb565 -s 9x9 -i image.data -f image2 -vcodec png output.png
avconv is from libav.
what is the dimensions then for 40 00 11 00
64 x 17
My 9x9 was for a file picked at random.
It seems avconv chokes on files smaller than 8 pixels wide. RGB565 is a pain in the arse...
This is better arrow : )
But let's ask from Userli, who made logo changer, what You can do with this file?
Rigol packer did make png from hex too or bmp or....
Here is my preferred boot screen!
I'm hacking something up in C which puts a BMP header on the data - seems the easiest solution.
There is CRC errors with V7. If I skip crc check, the file is extracted correctly and crc is the same as in the header.
Yeah sorry, there is some weired thing, where crc32 in python interprets the crc as a signed integer. I added the workaround to the second crc check as well... If anyone is still interested
Quick and dirty RGB565 to BMP converter.
some interesting stuff here. nice work guys
Being a complete "noob" on this hacking - what do you think is possible beside modifying the startup-screen?
Some things I would find useful:
- Pluses -> Pulses text change
- Help-menu: English text is sometimes almost non-understandable, could that be modified?
- Exchange some GUI elements - e.g. the WAIT button has very uneven spacing...? Or menu-icons?
- Remove all the "glass/gloss"-effects from the UI and make it more modern by replacing the underlying images?
I implemented the findings of smithnerd and re arranged the interface slightly.
Now the usage is more consistent: After loading the .GEL file you double click on the name of the file you're interested in.
This opens the hex code and clicking on "open content" will then decompress, show images, etc. , depending on the nature of the file.
It's iterative such that on each new panel you can again click open content to dig deeper if possible.
The new way of changing the start screen would be:
1) open firmware file
2) double click on /sys/logo.hex
3) click "show content" in new window
4) in logo window save image (as BMP)
5) modify BMP without changing it's size
6) click change image and select the changed BMP
7) save firmware file
I should maybe mention here that you use this application at your own risk.
I found that SparrowConfig.hex is the start screen image with "MSO ready" written in addition. The tool will show it the same way as the logo file.
The aim is definitely to be able at some point to change more serious data.
The problem currently is that I didn't find a compression tool yet, which will create the same compressed form of a file as is in the .GEL.
This is necessary since the ELF file (SparrowApp.out) containing the processor code with all the typos is LZMA compressed in the .GEL .
The same holds for GuiPicData.hex, which contains all the little images the user interface is made of.
Being a complete "noob" on this hacking - what do you think is possible beside modifying the startup-screen?
Some things I would find useful:
Then You must learn!
First rule is... take all apart and look inside to see how the system is working [big hammer emoticon here]
and then we see what we can do if all are coming apart. We are working with hammer right now.
Like I said, who knows where we ending with this... at the end or dead end.
The problem currently is that I didn't find a compression tool yet, which will create the same compressed form of a file as is in the .GEL.
This is necessary since the ELF file (SparrowApp.out) containing the processor code with all the typos is LZMA compressed in the .GEL .
The same holds for GuiPicData.hex, which contains all the little images the user interface is made of.
I share this concern and It's something I've been looking into.
I suspect the LZMA implementation is part of the MQX SDK used to create the firmware (Classic or v5, I couldn't say). I haven't got round to seeing what documentation or code is available on the NXP MQX pages yet.
That said, it may not be a problem. The fact that 7z's LZMA decoder can cope with their code bodes well for the opposite being true, so long as their header weirdness is respected.
Just posting so I can be notified of replies to this thread.
Go guys and gals!!!
Just fyi, quoting Borjam's post from other thread.
New firmware version!
http://int.rigol.com/Support/SoftDownload/3
[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date] 2016/05/31
[Updated Contents]
--------------------
v00.04.04.00.07 2016/07/19
- Added the full-screen display in the XY mode
- Modified the Trace data of average sample mode
- Fixed the bug of system halted for wave persistance in the Zoom mode
- Fixed bugs about Measure
Now. Who dares?
Nice finally Rigol released the whole firmware update history in the latest 00.04.04.00.07 firmware archive. If you have any of the firmware shown in red please PM or attach in a post.
v00.04.04.00.07 2016/07/19
v00.04.03.02.03 2015/10/20
v00.04.03.01.05 2015/06/16
v00.04.03.00.01 2015/05/05
v00.04.02.04.07 2014/12/31
v00.04.02.03.00 2014/10/21
v00.04.01.02.00 2014/07/28
v00.04.00.00.00 2014/03/18
v00.02.03.05.00 2014/01/27
v00.02.01.01.00 2013/10/31
v00.02.00.01.00 2013/09/02
v00.01.00.16.09 2013/08/14
v00.01.00.13.09 2013/07/25
v00.01.00.12.08 2013/07/10
v00.01.00.03.00 2013/05/21
v00.01.00.02.00 2013/05/19
v00.01.00.00.05 2013/05/19