Nonpareil display improvements


Release 0.68 of Nonpareil has much better looking LCD displays for the HP-41C and Voyager series calculators. Now instead of single-pixel-wide "stick digits", they have segments that look pretty much like the real thing, thanks to the scaling and compositing features of gdk-pixbuf. The Voyager annunciators are also now implemented.

The .png image files contain an oversized digit/character template, with each segment in a different color. The KML file specifies where the segment tempate is, how big it is, and what colors (RGB) the segments are. At startup, Nonpareil extracts the segments individually, changes their color to black, scales them, and converts the result to alpha channel data for compositing.

Display updates are also faster because display update requests now only invalidate the digits and annunciators that have actually changed, and the expose event handler uses the update region to determine which ones need to be repainted.

Updated the About box. Added some animation and an easter egg.


Hi Eric!

Compiling nonpareil-0.68 under CYGWIN_NT-5.0 i686 1.5.17(0.129/4/2) 2005-05-25 19:38 reveals following:

$ scons
scons: Reading SConscript files ...
KeyError: 'DISPLAY':
File "SConstruct", line 220:
File "/usr/lib/scons/SCons/Script/", line 581:
return apply(method, args, kw)
File "/usr/lib/scons/SCons/Script/", line 508:
return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
File "/usr/lib/scons/SCons/Script/", line 239:
exec _file_ in stack[-1].globals
File "src/SConscript", line 172:
str2png_env ['ENV']['DISPLAY'] = os.environ ['DISPLAY']
File "/tmp/python.572/usr/lib/python2.4/", line 17:
def __getitem__(self, key): return[key]
Nonpareil-0.67 compiled and installed perfectly, but:
$ nonpareil hp21
error opening object file
fatal error: can't read object file '/usr/local/lib/nonpareil/hp21.obj'

BTW: HP-12C works nice on VM/ESA



I think you need a newer SCons, 0.96.90.

However, there is another build problem in Nonpareil 0.68, so I suggest you wait for the next release, which will probably happen tonight or tomorrow night.


Yes, of cause I did _not_ install the beta version. But the SCons_local you supply with Nonpareil fails in similar manner.



Sorry Eric, but what did you change from 0.67?

$ ./scons-local/
scons: Reading SConscript files ...
KeyError: 'DISPLAY':
File "SConstruct", line 220:
File "/cygdrive/d/clicker/np/nonpareil-0.69/scons-local/scons-local-0.96.90/SC
ons/Script/", line 534:
return apply(method, args, kw)
File "/cygdrive/d/clicker/np/nonpareil-0.69/scons-local/scons-local-0.96.90/SC
ons/Script/", line 471:
return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
File "/cygdrive/d/clicker/np/nonpareil-0.69/scons-local/scons-local-0.96.90/SC
ons/Script/", line 217:
exec _file_ in call_stack[-1].globals
File "src/SConscript", line 172:
str2png_env ['ENV']['DISPLAY'] = os.environ ['DISPLAY']
File "/tmp/python.572/usr/lib/python2.4/", line 17:
def __getitem__(self, key): return[key]
This is with scons-local-0.96.90



In order to render the images used in the About box, there are two utilities that get built and executed as Nonpareil is being built. One of them uses the library gdk-pixbuf, and even though I never tell it to draw anything to the X server, the library will not work if it cannot connect to an X server. The SCons error you're reporting is the result of not having the DISPLAY and XAUTHORITY environment variables set; SCons is trying to copy the values of those environment variables to the environment it will export to the utility.

Whatever means you use to start the X server should set those environment variables in any subprocesses it creates, such as xterms. It's easiest to run SCons from one of those.


Thank you!! Up to now I used the simple "Bash window" (?, looks like a DOS box) to compile Nonpareil. If I do the same from the X-Window the DISPLAY key-error ceased. Now it hangs with KeyError XAUTHORITY. Well, I do not have enough time for that here at work (yes - i know - it's Saturday), I'll try at home 2nite.



Try commenting out the line in src/SConscript that uses XAUTHORITY. If that makes it work for you, I'll figure out how to make it optional.


Hi Eric!

When I do as adviced, I suddenly get an error from Windows: "cygX11-6.dll not found in path: ..." when the scons process invokes str2png.exe. The path shown in the error message is incomplete compared to the settings listed with SET within XWindow. Seems it's getting hairy - at least I feel lost in the middle of the jungle. Any pathfinder around?



Make sure the CygX....dll is in your Windows path (or in the autoexec.bat-Path.

Use the cygwin-bash and then type


in the xterm, you can then enter

xauth info

to view the settings

Good Luck!


Thank you for the hint, I get a "time out error" on xauth info as at work I am not admin of my PC. I'll try once more at home ASAP. Up to now I assumed using the SET PATH=... in cygwin.bat would be enough. Now I did so in startxwin.bat too. Alas still no success.

Seems I realy have to change the path in the autoexec.bat, I do not like that, I wanted to keep Cygwin separated from windows.



the addr_t is already defined in /usr/include/cygwin/types.h

you can disable the definition by defining "__addr_t_defined".

gcc -Wall -D__addr_t_defined -g -D_REENTRANT -DDEFAULT_PATH=/usr/local/lib/nonpareil -Ibuild -Isrc -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -c -o build/csim.o src/csim.c

executed in folder src compiles without error, but I have no idea how to add "-D__addr_t_defined" in the SConscript.

EDIT: Do not execute this in folder src, but in nonpareil_root!

Edited: 8 June 2005, 5:04 a.m.


Well - ah - ... - yes, for addr_t I use a brute-force method: I search for all *.c and *.h files in Nonpareil, load them to UltraEdit and change all addr_t to azzt_t. Pronto!



I changed the functions in sound.c to return 1, and defined size_t as int in sound.h, and now it works. I just started the 41cv, and now I will try the other calcs!!!

Thank you Eric for this wonderful piece of software!!!
(By diving into the build-process I found your easteregg in the aboutbox!) Nice work!

Edited: 8 June 2005, 6:17 a.m.


This is an odd error:
scons calls

build/str2png.exe -x 40 -y 44 kml/41cv.kml "." build/rgoose.png

among others, and this seems to cause the error "DLL not found". If you call it manually, it works. I commented out the lines in the SConscript, and called the commands manually, and copied the pngs from /build to /src, and it seems to work. However, the next problem is the sound, it requires the file "SDL_mixer"...

I can send a zip with my SConscript and src folder.


I had the .obj file open issue with 0.67 on Cygwin as well. Some debugging showed that it was actually a file re-open that was failing.

Inside the sim_read_object_file() function in proc.c, freopen() had NULL for the .obj file name string, and it was bombing the reopen. I replaced NULL with the actual filename string (as in the fopen() earlier in the same function) and the issue went away.

/* f = freopen (NULL, "rb", f); */

f = freopen (fn, "rb", f);

It's been years since I've programmed in C and I didn't research further -- I was just happy everything automagically worked after that and I could play with the calculators.

Many thanks to the author of Nonpareil!!


Aha! There is at least one more (or two?) using Cygwin. Did you encounter that type mismatch for variable addr_t too?



Yep. I compiled nonpareil after you, so getting down to just the addr_t naming conflict was an indicator to me that I had all the necessary libraries and headers in place. :-)



Did you encounter that type mismatch for variable addr_t too?

Where is that occuring? I get several other warnings when I build on Linux, but not that one.


freopen() had NULL for the .obj file name string, and it was bombing the reopen.

Apparently the Cygwin implementation of the freopen() function is not compliant with the C standard. ISO/IEC 9899:1999(E), section, paragraph 3 states:

If filename is a null pointer, the freopen function attempts to change the mode of the stream to that specified by mode, as if the name of the file currently associated with the stream had been used.

Anyhow, your fix should be OK. The reason I used NULL was that I *only* wanted to change the mode, not to actually close the file and reopen it, though doing that shouldn't hurt anything unless the file has been deleted in the mean time. (Some operating systems allow deleting an open file; the actual deallocation of the occuiped space is deferred until all open file handles are closed.)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Improvements for productivity for the Prime Stefan Dröge (Germany) 2 768 12-08-2013, 05:11 AM
Last Post: Stefan Dröge (Germany)
  Nonpareil Rom files davorin 2 612 09-20-2013, 06:20 PM
Last Post: Didier Lachieze
  Nonpareil + HP10C Mike (Stgt) 0 439 05-13-2013, 04:58 AM
Last Post: Mike (Stgt)
  Can the display for a HP32Sii be replaced with the display from another model? Bruce Larrabee 8 1,326 10-10-2012, 10:05 PM
Last Post: Luiz C. Vieira (Brazil)
  Nonpareil stuck Arnaud Amiel 3 640 08-05-2011, 10:00 PM
Last Post: Eric Smith
  HP65 in Nonpareil Harald 4 738 01-28-2011, 02:05 PM
Last Post: Harald
  My HP 35s keyboard improvements kiril t 25 2,707 01-07-2010, 11:52 PM
Last Post: Mohammed Hadi
  16 segment Led display would mimic a HP-41 display? Giuseppe Marullo 3 763 11-12-2009, 08:08 PM
Last Post: db (martinez, ca.)
  A webserver running on a HP-41 and HPIL patch for nonpareil Khanh-Dang Nguyen Thu-Lam 10 1,231 02-01-2009, 12:59 PM
Last Post: Khanh-Dang Nguyen Thu-Lam
  MOD file format differences for V41 vs i41cx/Nonpareil PeterP 3 618 10-16-2008, 04:36 AM
Last Post: Meindert Kuipers

Forum Jump: