Displaying images (not OFFIMGs)

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 1:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis » Tue Jun 04, 2019 5:38 pm

I confirm: it looks like string append helps to work around the opcodes working on names:

Code: Select all

FF7FFFFFFFFFFFFFFFFFFFFFFFFFFFFF
decodes correctly to:

Code: Select all

├"ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ"
That means a few extra CLA (one byte), and an extra byte in every strings.
String limit is 44 chars, so working with 40 chars-long string will make, for one complete screen length of 400px by 8px:

Code: Select all

00 { 536-Byte Prgm }
01 1
02 -39
03 CLA
04 ├"00000000000000"
05 ├"00000000000000"
06 ├"000000000000"
07 40
08 +
09 AGRAPH
10 CLA
11 ├"00000000000000"
12 ├"00000000000000"
13 ├"000000000000"
14 40
15 +
16 AGRAPH
17 CLA
18 ├"00000000000000"
19 ├"00000000000000"
20 ├"000000000000"
21 40
22 +
23 AGRAPH
24 CLA
25 ├"00000000000000"
26 ├"00000000000000"
27 ├"000000000000"
28 40
29 +
30 AGRAPH
31 CLA
32 ├"00000000000000"
33 ├"00000000000000"
34 ├"000000000000"
35 40
36 +
37 AGRAPH
38 CLA
39 ├"00000000000000"
40 ├"00000000000000"
41 ├"000000000000"
42 40
43 +
44 AGRAPH
45 CLA
46 ├"00000000000000"
47 ├"00000000000000"
48 ├"000000000000"
49 40
50 +
51 AGRAPH
52 CLA
53 ├"00000000000000"
54 ├"00000000000000"
55 ├"000000000000"
56 40
57 +
58 AGRAPH
59 CLA
60 ├"00000000000000"
61 ├"00000000000000"
62 ├"000000000000"
63 40
64 +
65 AGRAPH
66 CLA
67 ├"00000000000000"
68 ├"00000000000000"
69 ├"000000000000"
70 40
71 +
72 AGRAPH
Which results in:

Code: Select all

1100
1C131900
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
87
FF7F3030303030303030303030303030
FF7F3030303030303030303030303030
FD7F303030303030303030303030
141000
40
A764
That's 1072 chars per line, let's say approx 550 bytes.
We need 30 lines to fill the 240px, that 16.500 bytes (16.2 KB).

That's better !

grsbanks
Posts: 856
Joined: Tue Apr 25, 2017 9:23 am
Location: Preston, Lancs, UK
Contact:

Re: Displaying images (not OFFIMGs)

Post by grsbanks » Wed Jun 05, 2019 6:37 am

Thomas Okken wrote:
Tue Jun 04, 2019 4:54 pm
grsbanks wrote:
Tue Jun 04, 2019 3:41 pm
There is no way to get characters with a code above 0x7E into a string without resorting to XTOA.
Actually, there is: just make sure that the first code in a string is <= 0x7f

{…}

Thus, in an append string, all character codes can be used.
Very good points that I should have included. Thanks for completing the answer!
Not SwissMicros staff, just an enthusiast.

User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 1:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis » Wed Jun 05, 2019 6:55 am

To let you know the progress:

As I anticipated (and Thomas confirmed it): using string append is the way to go.
I now have a python script that reads the 1-bit 400x240 bitmap and converts it into a 42s program doing many CLA/|-/AGRAPH.

Last problems to iron out:

1) my script generates ASCII hex code (which decodes without error in the decoder):

Here is an example:

Code: Select all

C000FB004D6174746572686F726E
A763
1100
1C131900
87
FF7F0000000000000000000000000000
FF7F0000000000000000000000000000
FD7F000000000000000000000000
141000
40
A764
87
FF7F0000000000000000000000000000
FF7F0000000000000000000000000000
FD7F000000000000000000000000
141000
40
A764
87
FF7F0000000000000000000000000000
FF7F0000000000000000000000000000
FD7F000000000000000000000000
141000
40
A764
87
FF7F0000000000000000000000000000
FF7F0000000000000000000000000000
FD7F000000000000000000000000
141000
40
A764
87
FF7F0000000040001820802C008C1864
FF7F9890503020E0A020404080008000
FD7F800000000000000000000000
141000
40
A764
[...]
The problem is with the alpha lines: some chars get lost in the decoding part:

Code: Select all

FF7F0000000040001820802C008C1864
FF7F9890503020E0A020404080008000

decodes to:
├"÷÷÷÷@÷ᴇ €,÷Œᴇd"
├"˜P0 à  @@€÷€÷"

... which encodes to:
FD7F00000000400018202C001864
F97F5030202040400000
Comparing the lines to see what chars are lost in translation:

Code: Select all

FF7F0000000040001820802C008C1864
FD7F0000000040001820xx2C00xx1864  => 80 and 8C
FF7F9890503020E0A020404080008000
F97Fxxxx503020xxxx204040xx00xx00 => 98, 90, E0, A0, 80 and 80
So the encoder has some problems dealing with those chars.

Which does *not* mean the code hex cannot run on the DM42 or Free42... (I mean, maybe it's only the decoder). Good !
But without the decoder, I have to generate the raw file myself. Not so good ;)

So, as a last step, I now need to convert the hex chars to binary (aka .raw) - which should be straight forward from the hex file.
Then I'll tell you if that code runs on the DM42/Free42.
THAT is a really cliffhanger, isn't it ?!?

User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 1:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis » Wed Jun 05, 2019 7:31 am

Instead of changing the python script that generates the hex code, I've been lazy again and just used xxd:

Code: Select all

cat Matt.hex | tr -d \\n | xxd -p -r > Matt.raw
This code loads and runs in Free42. Yeah!
When listing the code on Free42, I can confirm that no chars where harmed (I mean lost) in the translation.

But the screen stays white...
OK, stupid me, I forgot that the screen is only 131 pixel-wide on Free42.
I'm using Matterhorn.bmp as a test and the top-left corner is blank :oops:
I changed the hex file manually and it's OK. It loads and runs on Free42.

Now, it's time to encode the whole picture in a raw file and test is on my DM42!!
OMG sooo many cliffhangers in a single forum threat !

grsbanks
Posts: 856
Joined: Tue Apr 25, 2017 9:23 am
Location: Preston, Lancs, UK
Contact:

Re: Displaying images (not OFFIMGs)

Post by grsbanks » Wed Jun 05, 2019 9:37 am

nibheis wrote:
Wed Jun 05, 2019 6:55 am

Code: Select all

FF7F0000000040001820802C008C1864
FD7F0000000040001820xx2C00xx1864  => 80 and 8C
FF7F9890503020E0A020404080008000
F97Fxxxx503020xxxx204040xx00xx00 => 98, 90, E0, A0, 80 and 80
So the encoder has some problems dealing with those chars.
That's because of the way Unicode is encoded in UTF8.

https://en.wikipedia.org/wiki/UTF-8

You're basically trying to get the decoder page to display glyphs that don't exist. Characters with codes up to 0x7F are clearly defined in ASCII. Anything above that is undefined unless you know the code page that is being used. The HP-42S character set is no good because anything above 0x82 is just a fuzzy blob. So what code page do you use?
Not SwissMicros staff, just an enthusiast.

User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 1:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis » Wed Jun 05, 2019 9:39 am

WARNING: the script code contained here is obsolete, look further in the thread for the latest version.

And here we are! A massive "thank you" to all the persons involved.

Attached to this post a tarball with the following files:
- bmp2hex: a python module (using "pillow" python lib - the only requirement) that read the BMP file and outputs its HEX code equivalent
- hex2raw: a bash one-liner that converts the HEX file to a RAW file

Also included for lazy people:
- matterhorn.bmp
- Matt.hex
- Matt.raw

By default, the bmp2hex works on 'matterhorn.bmp' and generates a program with LBL "Matterhorn".

Usage (could not be simpler):

Code: Select all

./bmp2hex > Matt.hex
./hex2raw Matt.hex > Matt.raw
Transfer the Matt.raw file to DM42, set GrMod to 3, XEQ Matterhorn... and voilà !

Some statistics:

Code: Select all

  4304  ./bmp2hex
    43  ./hex2raw
 12544  ./matterhorn.bmp
 34548  ./Matt.hex
 16161  ./Matt.raw
.raw image is 16 kB, while the corresponding bmp file is 12 kB - not a big overhead.
Any 400x240-1bit bmp image will result in exactly the same raw file size.

Maybe the code could be improved to skip blocks of blank pixels.

Now I'm ready to add some basic charts to my navigation library !
Attachments
bmp2raw.tar.bz2
(20.42 KiB) Downloaded 22 times
Last edited by nibheis on Fri Jun 07, 2019 8:29 pm, edited 1 time in total.

User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 1:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis » Wed Jun 05, 2019 9:58 am

grsbanks wrote:
Wed Jun 05, 2019 9:37 am
You're basically trying to get the decoder page to display glyphs that don't exist. Characters with codes up to 0x7F are clearly defined in ASCII. Anything above that is undefined unless you know the code page that is being used. The HP-42S character set is no good because anything above 0x82 is just a fuzzy blob. So what code page do you use?
I understand that what I was trying to do the encoder/decoder involves conversions of unprintable/displayable chars... and in fact this is not needed at all.

I gave it a shot for 2 reasons:
1- check the produced hex code by parsing it with the decoder
2- convert it back to get a raw file (this does not work for this very reason)

My solution to avoid those conversion issues is to use "xxd" to convert "82" (hex in pure ASCII) to the corresponding binary 8 bits, strictly, without involving any codepage or anything in the middle.

Side note: using xxd directly in vi on the current buffer (with the command ":%!xxd -p -r") does not work properly because it adds a new line (x0A) at the end (not sure why, but I could not get rid of it)

Thomas Okken
Posts: 609
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: Displaying images (not OFFIMGs)

Post by Thomas Okken » Wed Jun 05, 2019 3:16 pm

nibheis wrote:
Wed Jun 05, 2019 9:58 am
Side note: using xxd directly in vi on the current buffer (with the command ":%!xxd -p -r") does not work properly because it adds a new line (x0A) at the end (not sure why, but I could not get rid of it)
Assuming you're using vim -- you probably are, even if the command you type is "vi" -- this may help: https://stackoverflow.com/questions/105 ... nd-of-file

(In a nutshell: add

Code: Select all

set noeol
to your .vimrc file.)

Thomas Okken
Posts: 609
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: Displaying images (not OFFIMGs)

Post by Thomas Okken » Thu Jun 06, 2019 7:30 am

Actually, no, "set noeol" doesn't do the trick. I don't know what that option does, to be honest -- clearly not what I thought.
This does work: "set nofixendofline". Just tested it with vim and xxd (using the exact command :%!xxd -p -r) on my Mac, and it works.
https://stackoverflow.com/questions/162 ... ol-to-work

cdmackay
Posts: 81
Joined: Fri Oct 05, 2018 6:33 pm
Location: Cambridge, UK
Contact:

Re: Displaying images (not OFFIMGs)

Post by cdmackay » Thu Jun 06, 2019 12:46 pm

Thomas Okken wrote:
Thu Jun 06, 2019 7:30 am
Actually, no, "set noeol" doesn't do the trick. I don't know what that option does, to be honest -- clearly not what I thought.
This does work: "set nofixendofline". Just tested it with vim and xxd (using the exact command :%!xxd -p -r) on my Mac, and it works.
https://stackoverflow.com/questions/162 ... ol-to-work
I think noeol also depends on the binary option; see:

https://vimhelp.org/options.txt.html#%27fixeol%27

https://vimhelp.org/options.txt.html#%27endofline%27

it's a little confusing :)
Cambridge, UK
41CL, 12C/15C, DM15/16, 71B, 17B, 28S, DM42, 48GX, 17bII+, 50g (& newRPL), 35s, 30b (WP 34S), Prime G2
& Casios, Rockwell 18R :)

Post Reply