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 2:08 pm
Location: FR/CH/ES

Displaying images (not OFFIMGs)

Post by nibheis »

NOTE: For the latest script to convert images to .raw file, see this thread.


Hello all!

I am trying to find a way to get the DM42 to display pictures (process a bitmap image in some way and upload the result onto the DM42).
(eventually, I'd like to plot some basic coastline maps at large scale)

I imagined several possibilities (using a matrix for storing the pixels,etc.) but as far as I know, it is only possible to transfer programs as .raw files.
With that in mind, I wrote a python script to read one of the OFFIMG (matterhon.bmp) and basically it is translated to a large (very large) program that looks like:

Code: Select all

LBL "Image"
CLLCD
3
170
PIXEL
3
172
PIXEL
...
... for 45900+ lines.

It loads fine on Free42. It also runs fine on Free42 (even if most pixels coordinates are off its tiny screen...)

Then, I tried on the DM42:
1) the encoder/decoder page fails to process the 45900+ lines: Status: HTTP response code 500 (Internal Server Error)
2) using the 146K .raw file exported from Free42, I get the following error on the DM42:

Code: Select all

Unhandled memory allocation:

Unhandled memory allocation fail file:
../common/core_globals.cc
at line 2012
size 25088

Press EXIT to RESET the calculator...
I am using the latest FW.

My questions are:
1) Am I doing something wrong?
2) What should I do to fix that?
3) Can you think of a better/more effective/working way of display pictures?

Best regards,
nibheis
Last edited by nibheis on Wed Jun 12, 2019 5:32 pm, edited 1 time in total.
Dave Britten
Posts: 137
Joined: Wed Jun 14, 2017 9:27 pm

Re: Displaying images (not OFFIMGs)

Post by Dave Britten »

If you hit Shift-Catalog, MEM, I think you'll see why it's choking on a 146 KB program import. ;)
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Displaying images (not OFFIMGs)

Post by grsbanks »

nibheis wrote:
Tue Jun 04, 2019 11:40 am
My questions are:
1) Am I doing something wrong?
2) What should I do to fix that?
3) Can you think of a better/more effective/working way of display pictures?
Your problems will be helped tremendously if you look into AGRAPH instead of addressing pixels one by one.

Don't forget that the DM42 only has about 70KB free RAM so if you try and load a 146KB .raw file then you will have problems!
There are only 10 kinds of people in the world: those who understand binary and those who do not.
User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 2:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis »

Dave Britten wrote:
Tue Jun 04, 2019 3:20 pm
If you hit Shift-Catalog, MEM, I think you'll see why it's choking on a 146 KB program import. ;)
OMG... only 70KB free. :lol:
I took for granted that it had enough memory because my FAT partition is empty ; I messed up between RAM and FAT :oops:

So yes, I need to find a better solution... so much for quick and dirty programming.
User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 2:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis »

grsbanks wrote:
Tue Jun 04, 2019 3:26 pm
Your problems will be helped tremendously if you look into AGRAPH instead of addressing pixels one by one.

Don't forget that the DM42 only has about 70KB free RAM so if you try and load a 146KB .raw file then you will have problems!
I thought about it briefly, before falling into the easy (quick and dirty) solution of using PIXEL.
With AGRAPH I can address 8 pixels at a time (per char), so basically the display is 30 lines of 400 caracters.
That's already 12KB for one picture - but already 10x less. And that's independent on the number of black pixels ;)

- How long can an ALPHA string be ? (I think it is something like 44...)
- While encoding pixels to chars (during image processing), I'll run into odd chars that will break the encoder. Is XTOA the only solution then? Or maybe it is easier to just directly generate a raw file from the BMP file. It's only strings, string-appends a few integers and AGRAPH calls in the end.

After some testing, I suspect the encoder/decoder does not like special characters (I tried to decode a F1FF string and it was not happy...)

Now, I am playing with xxd on my raw files, looks like it's feasible:

Code: Select all

00000000: c000 f500 3030 3132 f1ff 1100 1100 a763  ....0012.......c
00000010: a764 c000 0a                             .d..
This raw program (called "0012") just print a black 8 pixel-long vertical line at 1,1.
I have it all, except the logic behind the integers - but I guess you know that :) Can you explain it to me please ?
e.g. Why is 1 translated to "1100" and 10 to "111000" ?

Best regards,
nibheis
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Displaying images (not OFFIMGs)

Post by grsbanks »

The encoder/decoder will handle any character that the DM42 can handle. If the encoder/decoder can't handle it then the DM42 can't, but remember the encoding to use if you want to create a string directly is that of the HP-42S/Free42/DM42. It will not handle UTF8 or any other representation of Unicode.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 2:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis »

grsbanks wrote:
Tue Jun 04, 2019 5:03 pm
The encoder/decoder will handle any character that the DM42 can handle. If the encoder/decoder can't handle it then the DM42 can't, but remember the encoding to use if you want to create a string directly is that of the HP-42S/Free42/DM42. It will not handle UTF8 or any other representation of Unicode.
Step #1:
Encode:

Code: Select all

"0"
Result:

Code: Select all

F130
Change that to :

Code: Select all

F1FF
Decode it back (we should get "ÿ"), but we get:

Code: Select all

Status: Invalid TEXT subcommand at PC:0001
If I change the raw file manually with an hex editor (30 -> FF) and upload it to free42, then it works!
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Displaying images (not OFFIMGs)

Post by grsbanks »

Check the character table in appendix E of the HP-42S manual.

All string opcodes with a first byte greater than 0x7F correspond to instructions that operate on names.

Thus, hex data F481414243, for example, is not a 4-character string including chr(0x81), A, B, C. It is the internal representation of the instruction STO "ABC".

There is no way to get characters with a code above 0x7E into a string without resorting to XTOA.

"ÿ" might well be char 0xFF in the printer's character set. Not in that of the HP-42S.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
User avatar
nibheis
Posts: 13
Joined: Tue Feb 05, 2019 2:08 pm
Location: FR/CH/ES

Re: Displaying images (not OFFIMGs)

Post by nibheis »

Thanks for all this precious information!
I will try to work around these specific opcodes using XTOA and maybe string append. I will let you know how it goes.

Best regards,
nibheis
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Displaying images (not OFFIMGs)

Post by Thomas Okken »

grsbanks wrote:
Tue Jun 04, 2019 5: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, and all subsequent codes can be anything, including >= 0x80.
At least, on the DM42 and in Free42. I haven't tried what happens when you use such strings in a real HP-42S.
Note that the append character, in lines like

Code: Select all

01 ├"FOO"
is actually a part of the string, despite being displayed before the opening double quote. Thus, in an append string, all character codes can be used.
Post Reply