Post Reply 
Trying to improve x49gp
10-28-2014, 10:08 PM
Post: #1
Trying to improve x49gp
Today I participated in a discussion about 50G grayscale graphics on the Omnimaga forums. As a result of that, I wrote and posted a patch allowing the good old x49gp emulator to switch its display into grayscale mode. Then I got a message from debrouxl pushing me to post about that here so it doesn't get lost over there - only a few 50G owners are visiting Omnimaga. He has a point there ...

So here I am, a new MoHPC user (though I've read the forums for a few months now). A 50G is my only working HP calculator. I've learned that trying to write native ARM software for it is quite a hassle, especially if it uses grayscale, because there are not many emulation / debugging environments to choose from - either real hardware, putting my precious SysRPL projects in port 1 at risk of being deleted by buggy programs, or x49gp with its limitations. The discussion on Omnimaga motivated me to get rid of one limitation.
May it help someone else out there too. I'm sure I'll use it myself.

x49gp had some compilation problems on my system, I've patched the Makefile to work around them, and somewhen I found a typo in flash.c and fixed it. These fixes are bundled in another patch. Feedback is welcome, x49gp could become a 50G developer's friend if someone takes care of its problems, of which it probably has accumulated many over the years without maintenance in addition to those present from the beginning, like use of deprecated GTK2 functions.

... Why are diffs not an allowed attachment file type? Also, if this is posted in the wrong place, feel free to move it.


Attached File(s)
.txt  grayscale.diff.txt (Size: 6.77 KB / Downloads: 18)
.txt  compile_fix.diff.txt (Size: 1.24 KB / Downloads: 14)
Find all posts by this user
Quote this message in a reply
10-28-2014, 10:53 PM (This post was last modified: 10-28-2014 10:55 PM by Han.)
Post: #2
RE: Trying to improve x49gp
Did you get this to compile on OS X? (Read through the diffs which suggested that this was the case -- I've been running into lots of issues with x49gp on Mac OS X)

Edit: nevermind; the OS X reference was just for the relative location for the diff

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
10-29-2014, 02:54 AM
Post: #3
RE: Trying to improve x49gp
I haven't had time to maintain this.

I applied 3298's patches and created a new github public project:

https://github.com/datajerk/x49gp

This should make it easier for others to contribute, fork, merge, etc...

The last OS/X build I did was for 10.6. If I have time over the holidays I'll try to build for 10.10 and update the repo.

Cheers,

Egan
Find all posts by this user
Quote this message in a reply
10-29-2014, 02:57 AM
Post: #4
RE: Trying to improve x49gp
Looks like there already is an x49gp on github:

https://github.com/NicholasKirchner/x49gp
Find all posts by this user
Quote this message in a reply
10-29-2014, 03:10 AM
Post: #5
RE: Trying to improve x49gp
Final update.

I dumped my github x49gp repo and forked the existing one, then applied the grayscale patches and the flash.c patch. The Makefile looked ok. I push my changes here:

https://github.com/datajerk/x49gp

I didn't test building it yet, just merged all the changes.
Find all posts by this user
Quote this message in a reply
10-29-2014, 08:43 AM
Post: #6
RE: Trying to improve x49gp
So you are this datajerk? I guess I didn't read the readme thoroughly enough.

The Makefie fix for Ubuntu present in that Git repo does its job, but on my system I'm running into another error which is shown as this:
Code:
/usr/bin/ld: ui.o: undefined reference to symbol 'floor@@GLIBC_2.0'
/usr/lib/libm.so.6: error adding symbols: DSO missing from command line
The fix was to link against libm, which led to a similar error about a function from libz. These are why I added -lm -lz to the LDFLAGS. For reference, the system is Manjaro (an Arch-based distro, rolling release, hence no version number other than "current"). I don't have a Mac to try the OSX compilation on, so there's little I can do about that.
Does the addition of -lm -lz break compilation on some system?

Also, I should mention that my tests with the grayscale patch were just "look whether it works at all". The stack showed up properly, meaning the monochrome mode works, and I opened a 4-bit grayscale GROB with OpenFire's viewer, which also looked like I expected. The palette register for 2-bit grayscale wasn't tested, but HPGCC3's grayscale mode switch routine refers to the word at an offset of 10 32-bit words as the palette register, which is the one called bluelut in x49gp's data structure. So in theory it should work once a silly mistake on my side is fixed: in s3c2410_lcd.c:117 I wrote
Code:
return 15 & (lcd->bluelut >> (2 * data));
which was supposed to shift the appropiate part of the palette register to the LSB end (data contains the 2-bit color). The 2 * data should be 4 * data because the colors in the palette register are 4 bits wide, of course.
Could someone confirm that grayscale works on other systems as well? I'm kinda new to X server graphics, so I could have done something non-portable. One of my attempts involved calling the wrong GDK function in the places where the foreground color is set, which made the virtual screen turn black.
The color selection is a bit lacking, too. I took the screen color of the calc pictures (171, 210, 180 in RGB) and scaled each component by the desired grayscale value.
Find all posts by this user
Quote this message in a reply
10-29-2014, 09:18 AM
Post: #7
RE: Trying to improve x49gp
Quote:Does the addition of -lm -lz break compilation on some system?
I heard a die-hard BeOS/Haiku user complain that -lm was not portable, but x49gp doesn't target those, AFAICT Smile
Find all posts by this user
Quote this message in a reply
10-29-2014, 11:58 AM
Post: #8
RE: Trying to improve x49gp
I had x49gp with greyscale for many years (16-greys only, though, which is what I needed to make hpgcc3 work), I just never had the time to clean it up and publish it. I also enabled the GDB server to enable step-by-step debugging and variable inspections from within Eclipse, making developing hpgcc3 programs much easier.

If there's a new maintainer now I guess I could create a couple of diffs and send to you for review.

Claudio
Find all posts by this user
Quote this message in a reply
10-29-2014, 12:04 PM
Post: #9
RE: Trying to improve x49gp
(10-28-2014 10:08 PM)3298 Wrote:  I've learned that trying to write native ARM software for it is quite a hassle, especially if it uses grayscale, because there are not many emulation / debugging environments to choose from - either real hardware, putting my precious SysRPL projects in port 1 at risk of being deleted by buggy programs, or x49gp with its limitations.

Too bad you never posted on this forum before (or comp.sys.hp48), I could've given you x49gp with 16-grays grayscale and GDB working, and guide you on how to use it with Eclipse.
Sometimes it's worth to ask the question before you put too many man-hours of work.
In any case, great work.
Find all posts by this user
Quote this message in a reply
10-31-2014, 12:36 AM
Post: #10
RE: Trying to improve x49gp
(10-29-2014 08:43 AM)3298 Wrote:  So you are this datajerk? I guess I didn't read the readme thoroughly enough.

Yep.

Quote:Does the addition of -lm -lz break compilation on some system?

Shouldn't, will test when I have time. For now I added to the Makefile.
Find all posts by this user
Quote this message in a reply
11-03-2014, 07:17 PM
Post: #11
RE: Trying to improve x49gp
Is there a version of x49gp for Windows (preferably running on Windows 7 and 8.1)???This HP 50G emulator is very known on Linux. If a pre-compiled version is disponible for download, I am very grateful for it.
Find all posts by this user
Quote this message in a reply
11-04-2014, 09:50 PM
Post: #12
RE: Trying to improve x49gp
Sorry, no. Your only option is a virtual machine. The code uses lots of Unix-specific things, such as signals. I actually tried compiling it on MinGW, but it failed on these. Too bad ... but you would have had trouble with other parts as well, for example exiting it. On Unix, having a terminal in the background is more usual than on Windows; exiting the emulator is done by switching to the terminal it is running in and pressing Ctrl+C there, which sends the termination signal.
Find all posts by this user
Quote this message in a reply
11-08-2014, 09:50 PM
Post: #13
RE: Trying to improve x49gp
(11-03-2014 07:17 PM)Anderson Costa Wrote:  Is there a version of x49gp for Windows (preferably running on Windows 7 and 8.1)???This HP 50G emulator is very known on Linux. If a pre-compiled version is disponible for download, I am very grateful for it.

Not that I am aware of. I did try years ago under Cygwin. IIRC, it compiles, but does not run. I didn't have time to troubleshoot it.

Unless you need ARM emulation for asm/c programming, then I'd recommend that you stick with EMU48.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)