+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not quite HP Calculators - but related (/forum-8.html)
+--- Thread: Trying to improve x49gp (/thread-2352.html)
Trying to improve x49gp - 3298 - 10-28-2014 10:08 PM
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.
RE: Trying to improve x49gp - Han - 10-28-2014 10:53 PM
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
RE: Trying to improve x49gp - Egan Ford - 10-29-2014 02:54 AM
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
RE: Trying to improve x49gp - Egan Ford - 10-29-2014 02:57 AM
Looks like there already is an x49gp on github:
https://github.com/NicholasKirchner/x49gp
RE: Trying to improve x49gp - Egan Ford - 10-29-2014 03:10 AM
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.
RE: Trying to improve x49gp - 3298 - 10-29-2014 08:43 AM
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 lineDoes 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));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.
RE: Trying to improve x49gp - debrouxl - 10-29-2014 09:18 AM
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
RE: Trying to improve x49gp - Claudio L. - 10-29-2014 11:58 AM
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
RE: Trying to improve x49gp - Claudio L. - 10-29-2014 12:04 PM
(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.
RE: Trying to improve x49gp - Egan Ford - 10-31-2014 12:36 AM
(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.
RE: Trying to improve x49gp - Anderson Costa - 11-03-2014 07:17 PM
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.
RE: Trying to improve x49gp - 3298 - 11-04-2014 09:50 PM
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.
RE: Trying to improve x49gp - Egan Ford - 11-08-2014 09:50 PM
(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.
RE: Trying to improve x49gp - 3298 - 05-05-2018 10:43 PM
I'm resurrecting this thread because I want to publish another set of x49gp patches. You might wonder why I'm not throwing them at GitHub, but I'd like to avoid creating an account there due to their terms of service and privacy policy (there are some things I'd like to keep private which always end up on a user's public profile). Oh well, I'll just stick to plain old diffs posted in a forum. If anybody wishes to put them onto GitHub or anywhere else, no problem; take them (though please mention author (3298) and source (link to this thread) if you do so). I've sent some of these patches to the current maintainer as well, but he indicated that life is keeping him busy. We discussed a few small bits, but nothing has happened since then (more than 7 weeks) - he must be really busy, so I'm putting this out there myself.
x49gp has seen quite a few changes since I created this thread for the grayscale patch. Most notably, Egan Ford aka datajerk has yielded official maintainer status to ecd aka chwdt. Unfortunately the new maintainer has forked the original GitHub port by NicholasKirchner instead of datajerk's, and the forks have not been merged yet. Some changes (but not all of them) have been copied and wrapped into new commits (cherry-picking the existing ones would have been better, and it would have avoided attributing authorship of the patches from this thread to datajerk when he really is just the committer). Furthermore, there are a bunch of smaller forks on GitHub, but pretty much all of them are variations on the theme "compile fix + firmware update". The compile fixes resemble the one in this thread, which is present in datajerk's fork, and the firmware update is also present in chwdt's fork, so they are redundant. The only one I picked up is the fork by our well-known member Claudio L., which contains a better variant of a change I've been privately using for a few years: he provides a way to enable the debugger, and unlike my primitive version it's not even necessary to recompile for turning it on or off. Therefore I've merged these three forks and then put a bunch of patches on top of that.
---
Okay, with that out of the way, let's get to the details. First, the user-visible changes.
You probably won't notice the fixes unless you ran into their corresponding problems in previous versions, so I'll limit myself to mentioning their existence in this section; they are listed below in the developer-focused section.
What you will notice, however, is that the build process has changed slightly. The readme has been updated to reflect that. For new users, that's probably comprehensive enough to get started, so if "new user" applies to you, just stop reading after finishing this paragraph, download my source package and open the file "README.md" inside it. But until this patch series gets merged into chwdt's fork, you'll want to replace the 'git clone' action by extracting the source archive - I've put the 'git clone' line in there so this can be merged without changes.
For previous users of x49gp, most of my patches are only fixes or additions, so pretty much everything you remember about using x49gp will still work.
The most notable exception is the ./newconfig script - it's gone. Don't worry though, it's not needed anymore; the program itself has received improvements which render it obsolete. Its two usecases were setting up an initial valid configuration, which the program will now do by itself when confronted with an absent or empty config file. The other one is resetting the calculator as if you pushed the reset button on the back. If you need that, you can simply delete the file instead, or (better) look into the options for resetting while the emulator is running (e.g. the F12 key; this particular feature is actually from chwdt's fork).
There is another exception which you will run into unless you use a state file from a previous version: when the flash file does not exist yet, x49gp will create one which only contains the bootcode; you'll need to install a firmware yourself. This may look like a step back compared to the previous system which baked a firmware into the initial flash image, but with the emergence of NewRPL as an increasingly viable alternative to the stock HP firmware I wanted to give the freedom of choice to users. In addition, constructing the initial flash file with the firmware baked into it involved some largely unexplained magic ("marking blocks" was all the relevant code had to say about it); I was worried that might somehow interfere with custom firmware. The firmware images and an update.scp file corresponding to one of them are still shipped with the source, so if you want to run the stock firmware, you won't have to download it separately.
The less apparent changes include the ability to omit the config file on the command line. That means you can now run x49gp without any parameters; in that case it will default to using a config file at ~/.x49gp/config (and if that file doesn't exist, it will be created with default values, of course). It's still possible to specify a config file, allowing you to have multiple instances of x49gp with their own configurations and memory files. I should probably secure it against using the same file for two simultaneously running instances, because they will literally share their memory - that will confuse the hell out of the firmware when they write anything to RAM or flash memory. For now, just avoid doing that. But honestly, x49gp has behaved like that right from the beginning, so that's at least not my fault.
If you want to use an old state file, I should probably point out that a handful of config properties have changed. The "basename" property is gone because it was limiting: you weren't able to move the entire collection of state files without adjusting the basename property. Add the fact that the basename wasn't allowed to be an absolute path (it was always relative to the home directory), and you have a recipe for frustration. Okay, individual filenames were allowed to be absolute, bypassing the basename entirely, but then those have to be adjusted instead. So I thought, why not interpret relative paths as relative to the location of the config file? That way you can move the collection of files without breaking anything. As a bonus, any setup created by ./newconfig and the Makefile which wasn't edited manually will continue working because that setup places all files in the source directory and puts just the bare names of the other files into the filename properties. Also, the duo of properties called "image" and "name" are reorganized into properties called "type" and "name". Previously it was possible to screw these up such that you got a 50g image with 49g+ text colors or vice versa; now you are guaranteed to get a consistent appearance determined by the "type" property (allowed values are hp49g+ and hp50g, other values will default to hp50g and emit a warning on the terminal). The name only affects the window title. (No, the lack of window decoration does not make that useless because it shows up in all places listing window names, such as KDE's dashboard or any kind of window bar that allows text.) Editing the title could be beneficial when using multiple instances at the same time. Unfortunately all old state files will convert to 50g because the "type" property is new and defaults to that, but I guess for the vast majority that's not even a change because they already were set up to be a 50g.
And then there's the popup menu. This is probably one of the more useful changes in this patch series, but unless you read the README.md file, the new manpage, or this post, you'll probably only stumble upon it by accident. Open it by right-clicking on the virtual screen or by pressing the menu key, and it will give you access to a few controls. The simpler ones are Reset (resets the calculator, for those who somehow don't have access to the F12 key) and Quit (closes the emulator; Alt-F4 or equivalent already worked, but here you have a version that looks more official and works with just a mouse). The other options affect the SD card: you can mount an SD card or unmount it. I'm using Unix terminology there, so "mount" means inserting an SD card, and "unmount" means pulling it out again. There are actually two variations of the mounting part, one for files which users of older versions are probably familiar with (the file would contain a binary image of the SD card's filesystem), and one for folders which was always there but never advertised, so next to nobody actually knew about it. Powered by QEMU's Virtual VFAT driver, this takes a folder and makes it appear like a filesystem to the emulated device. It's a pretty complicated piece of code, but it seems to work just fine after I suppressed a ton of debug logs (around 3 MiB for merely opening the SD card in the stock firmware's filer, i.e. a LOT). The need for different selection windows for files and folders is actually a GTK2 limitation, in the config file it's all handled by a single property, called "filename" in the s3c2410-sdi section, just like in older versions.
For users who debug ARM programs in x49gp (most likely custom firmware or HPGCC3 programs), I've added the ability to override the default debugger port and the ability to (re-)connect to an already running x49gp session via an additional popup menu entry that's hidden by default. It's hidden to prevent accidents (connecting to the debugger locks up the emulator until the connection is established). Consult the readme, the manpage, or the help page ('x49gp --help' in a terminal, also a new addition) for more info on that.
Now for the other big feature, the ability to install x49gp system-wide. This allows you to run x49gp from any directory, puts a shortcut into your applications menu (still looking for a decent icon), and puts the new manpage into the appropriate system folder. Note that on most systems, you might want to look into creating a package so the package manager doesn't complain about unowned files in the system directories. I've done it on Arch, so it's probably possible on most Unix-based systems (maybe excluding OSX, because Apple likes to do things differently; I have zero experience with installing stuff on OSX and no Mac, so someone else has to figure it out).
And just because I know someone will ask this again: no, Windows is still not supported. No, there are no plans to change this either. I did get x49gp to compile on Windows by swapping MinGW out for Cygwin (which has a compatibility layer that tries to cover up the differences between Windows and Unix) and grabbing another specialized x49gp fork from GitHub, but it crashes on startup somewhere deep inside the QEMU code. Fixing that will probably need a QEMU upgrade - I've been trying for a month to upgrade to a current version, but the 8 years of changes since datajerk upgraded from 0.9.0 to 0.12.50 (they're past 2.12 now) are not playing nice with x49gp, especially because QEMU isn't designed to be used as an emulation library like x49gp does. I'm stuck at an estimated 10% progress with no clear path forward (couldn't even make a binary, let alone one that works), so I'll probably abandon that attempt.
---
For interested developers, here is a summary of the code changes in the form of my commit messages (plus sometimes a few additional notes), and a handful of commands to reproduce the harder parts of the patch series on your computer. (Those who just wish to get the resulting version of the source should grab the attached source package instead.) For this to work, it's necessary that all of the three forks I use stay at the same state as they are at when this post is published. Otherwise some conflicts may show up.
Again, if you plan to push the resulting repository somewhere else, e.g. to GitHub, please remember to put a note about author and source into the commit messages. Seeing one's hard work taken and (implicitly or explicitly) attributed to someone else hurts, even when it's not done intentionally.
1. Set up a local repository and get the three forks in there.
Code:
git clone https://github.com/chwdt/x49gp
cd x49gp
git remote add -f datajerk https://github.com/datajerk/x49gp
git remote add -f claudiobsd https://github.com/claudiobsd/x49gp3. Perform the first merge and resolve the conflicts. Diffs of merges are not a well-supported thing, so I've created a combined diff (describes the changes in a stable format, but cannot currently be applied automatically) as well as a diff from the state with conflict markers to the state with all conflicts resolved (depends on the exact presentation of the conflicts being the same as for me, which may change depending on git version or settings, but at least there is a tool for applying this). I've written the commands below such that they set a relevant setting to the value I use, so you should be able to just run them. If it fails, the combined diff is there so not all is lost, but applying it by hand means you have to be familiar with the format.
Code:
git config --local merge.conflictStyle diff3
git merge datajerk/master
git apply 01.diff4. Perform the second merge. Git will not detect any conflicts by itself, but the commits in the fork to be merged add two reasons for compile warnings, and on the other side of the merge is a change that turns warnings into errors, so the result of the merge will be broken. I prefer to fix this in the merge commit itself, so the following command sequence makes it stop before producing a commit and puts a fix in.
Code:
git merge --no-commit claudiobsd/master
git apply 02.diffThis particular commit contains a number of small fixes and enhancements I've collected over a larger timeframe (if you re-read this thread, you may recognize one of them). I'll let the commit message speak for itself:
Code:
Misc changes, mostly fixes:
- fix ./newconfig systems other than OSX (broke in c8b823f)
- fix palette usage in 2-bit color mode (was broken ever since grayscale was implemented in 18e1003 and its improperly attributed copy f7913eb)
- fix continuing from breakpoints in the debugger (never worked, was exposed when the debugger was enabled in 9c1f2ed)
- restore the printf statements commented out in 9c1f2ed and hide them with #ifdefs instead
- close the server socket after accepting a debugger connection to allow another simultaneous debug session to be started using the same TCP port
- use the symbolic constant DEFAULT_GDBSTUB_PORT (already defined in gdb_stub.h as 1234) when starting the gdb server in main.c in place of the raw number 1234
- change Makefile to read the name of the firmware file from the file update.scp instead of hardcoding it; this allows users to switch to another firmware
by simply pasting it along with its accompanying update.scp into the x49gp directory6.
Code:
Enhance port G (keyboard) handling to remember the value of output bits across periods with these bits configured as input
This fixes interaction with HPGCC3 keyboard routines, and it also fixes keys with eint==7 (assuming the stock firmware is in use)
needing a double-tap to work unless pressed very shortly after another keypress (the latter broke in b5f93ed)7.
Code:
Get rid of the deprecated function warning by switching from gdk_pixbuf_new_from_inline to gdk_pixbuf_new_from_data (based on code by chwdt)8.
Code:
Delete remaining now-redundant CVS files9.
Code:
Don't release all buttons anymore if there are still physical keys and/or the left mouse button are holding some down
On the other hand, forcibly release all buttons when losing focus to avoid getting stuck in a state with buttons down
when they are not held down by anything; this would happen due to missed events while not in focus10.
Code:
Add a context menu to the screen, containing only "Reset" and "Quit" items for now11.
Code:
Ensure that the files backing flash, sram, and s3c2410-sram exist and have the correct size when opening them
Note that if the flash file does not exist, this will not fill it with the code that's supposed to be in there, obviously causing the calculator to crash. That's an improvement for later.Code:
Allow the config system to fill not only numbers, but also strings (including filenames) with default values
basename is excluded, but it's planned to be dropped entirely.Code:
Add an "install" target to the Makefile
This is not fully functional yet; some bits of the configuration (notably, the "basename" property, the UI image property and the flash) need to be set up manually.
The "install" target installs some files which will help remove this limitation, though the necessary code is not yet there.
The ./newconfig script combined with the "flash-*" targets, which used to be responsible for this job, continue to exist for now. They aren't really suitable for being installed themselves, though.14.
Code:
Implement a more generic command-line parser for substantially improved flexibility
This allows specifying the debug port, as well as omitting the config file, falling back to a default one at ~/.x49gp/config
Also adds a proper help option, though the manual referenced in the corresponding output (a manpage, hopefully) does not exist yet.Code:
Drop the "basename" config property in favor of interpreting relative paths in the config as relative to the config file's locationCode:
Retire the "image" config property in favor of simply loading the image from next to the binary or from the install directoryCode:
Split the UI name property into name (affecting only the window title) and type (affecting the UI image and in the future also the default bootcode) properties
This allows setting the window title independently, which might be useful with multiple different instances; that's the only reason I could think of for keeping the window title configurable at all.
Also, change the default calculator type to the 50g everywhere, which probably matches today's user expectations better than the 49g+.
The config.tmpl file used by the newconfig script already contained a line specifying that the type should be 50g, which overrode the code defaults unless deleted manually.Code:
Create a flash file from the calculator model's appropriate boot file if it does not exist, relying on the bootcode to detect the absence of a firmware
The bootcode will complain about the missing firmware and enter update mode, so the user needs to supply their favorite firmware version and point the bootcode's updater to it.
The easiest way is probably pointing the emulated SD card at a directory containing the firmware and its accompanying update.scp file, and then starting the SD-based update.Code:
Add SD mount / unmount options to the right-click / menu-key popup menu
Due to GTK+ silliness, a file dialog cannot be set to allow file and folder selection at the same time, only one or the other.
That is why there are two mount options (folder, image) in the menu now.Code:
Remove most of the old script-based config-generating system since the binary now has these capabilities as well
The sdcard target can stay in the Makefile because generating an image may still be useful sometimes, even though folders are supported too.
The firmware images can stay as well because the user still needs to select one during the first start, and this way they can mount the source folder as SD to pick up one.Code:
Add an applications menu item for installing22.
Code:
Keep some debug output on stderr and a huge vvfat.log file from showing up when not debugging x49gp itselfCode:
Allow (re-)connecting a debugger to a running session
This is done through the right-click / menu-key popup menu.
To avoid confusion due to the accidental clicks leading to an unresponsive interface (caused by waiting for the debugger to connect),
this option is hidden unless option -d or its new companion -D (same as -d, but does not start the debug interface right away) is present.
Users who regularly debug with x49gp are encouraged to add -D to whatever shortcut they use to launch x49gp;
if -d and -D are both present, the port is the last one explicitly specified (same as multiple of the same variant),
and the debug interface will start immediately as instructed by the presence of -d.Code:
Improved support for hardware keyboards
Notably, any pressed key is now interpreted according to its unshifted function. The previous situation could cause some key combinations to press possibly unintended virtual keys,
e.g. on a US English QWERTY keyboard Shift+8 would have been interpreted as leftshift-multiply, i.e. typing square brackets.
The intention could have been either only the multiply sign or the exp&ln menu (which is leftshift-8); the former conflicts with having both shift keys assigned to virtual keys
and prevents some shift-hold virtual key combinations, so x49gp will now assume the latter.
Also adds additional keybinds for y^x (caret or circumflex, when available), enhances support for German QWERTZ keyboards (sharp s -> divide, # -> multiply),
removes the Alt and Meta keybinds to avoid Alpha presses when switching applications with Alt-Tab or Meta-Tab,
and changes the hardware right Shift (formerly rightshift) and Control (formerly unused) keys to do the same as their left counterparts (leftshift and rightshift, respectively),
to avoid surprises when typing with the right shift key held down like in a regular text editor.
Further input on support for various keyboard layouts is welcome.25.
Code:
Update README.md, add manpage, rename other README files to TODO to reflect their contents---
Well, that's that. Unfortunately I had to pick the most efficient compression format I could find (7z with LZMA2 algorithm), split it into a few parts, and append an allowed file extension just to upload it here. That shouldn't be a big problem though, just remove the bogus .zip file extension and open it with any decent archiving program. Enjoy!
RE: Trying to improve x49gp - 3298 - 05-05-2018 10:45 PM
... and the patches attached to a separate post due to the attachment limit. If you only care about the end result, this is not what you are looking for.
RE: Trying to improve x49gp - Claudio L. - 05-07-2018 06:33 PM
Thanks for your work, these are very welcome patches. What I value the most is your effort to "un-git" the project. Distributed version control has one big pitfall: unless there's a central maintainer ready to pull patches, projects fork ad-infinitum and nobody knows which one to use. To make it worse, github does a great job at making them look all the same. There should be a different template for pages of the "official" repository of each project, so people know where to push patches and users know where to fork from.
Thanks again, I'll pull your patches in my fork, hopefully we can make all existing forks consistent.
RE: Trying to improve x49gp - dmmaster - 05-07-2018 07:17 PM
Why don't you run simply on Linux or BSD, Windows, and Mac the famous : x48
It works on raspberry, Arm, Armel, Armhf, x86, 486, 586, 686, Solaris,...
here the link. There are many users that have pre/compiled the x48 file on the sourceforge for you. just download and run
https://sourceforge.net/projects/x48.berlios/files/
Let us know about progress to help you.
RE: Trying to improve x49gp - 3298 - 05-07-2018 08:12 PM
(05-07-2018 07:17 PM)dmmaster Wrote: Why don't you run simply on Linux or BSD, Windows, and Mac the famous : x48Sigh... would you please do at least some preliminary research before trolling with such useless links? All the fame and binaries in the world can't magically make x48 emulate the 50g. Not even at Saturn level (Emu48 does that at least, and with Wine all is fine on Linux, so I don't see the point in using x48 at all). I need ARM-level emulation to run HPGCC3 programs or NewRPL. x49gp is the only emulator capable of doing that.
So: thanks for nothing. Go find yourself another thread to clutter up. This is about x49gp and only x49gp.
RE: Trying to improve x49gp - dmmaster - 05-07-2018 08:36 PM
(05-07-2018 08:12 PM)3298 Wrote:(05-07-2018 07:17 PM)dmmaster Wrote: Why don't you run simply on Linux or BSD, Windows, and Mac the famous : x48Sigh... would you please do at least some preliminary research before trolling with such useless links? All the fame and binaries in the world can't magically make x48 emulate the 50g. Not even at Saturn level (Emu48 does that at least, and with Wine all is fine on Linux, so I don't see the point in using x48 at all). I need ARM-level emulation to run HPGCC3 programs or NewRPL. x49gp is the only emulator capable of doing that.
So: thanks for nothing. Go find yourself another thread to clutter up. This is about x49gp and only x49gp.
Sorry for my post. I was trying to help, hopefully HP48G, would have help you.
OK, x49gp only and only. Got it. Good Luck.
RE: Trying to improve x49gp - 3298 - 05-07-2018 08:55 PM
(05-07-2018 06:33 PM)Claudio L. Wrote: Thanks for your work, these are very welcome patches. What I value the most is your effort to "un-git" the project. Distributed version control has one big pitfall: unless there's a central maintainer ready to pull patches, projects fork ad-infinitum and nobody knows which one to use. To make it worse, github does a great job at making them look all the same. There should be a different template for pages of the "official" repository of each project, so people know where to push patches and users know where to fork from.That wasn't my intention at all. In fact, merging the three best forks (in my opinion), using that as the base for patches, and submitting that to the official maintainer is very much Git-like. If he wasn't busy, you would probably have seen something similar to this patch series appear in his repository, including the merges, and this thread would have remained in the depths of the forum instead of resurfacing.
I agree that the lack of an active official maintainer (or group of maintainers in larger projects) can lead to fragmentation, but the beauty is that if somebody else wants to, they can get quasi-official by simply caring about a project in the absence of the maintainer, developing fixes and features and merging other forks into their own fork. In this case, I firmly believe chwdt will have time for x49gp again eventually; in the meantime we can run it ourselves...
(05-07-2018 06:33 PM)Claudio L. Wrote: Thanks again, I'll pull your patches in my fork, hopefully we can make all existing forks consistent.... by doing that, for example. Taking back the lead doesn't get much easier than a fast-forward merge, so with the tip of his fork merged into the new quasi-official branch, (and perhaps a pull request or message to notify him,) everyone should be happy. I for one would be, because it means this reaches a larger audience than this forum post can hope to. The significant influx of fresh patches compared to the number of past commits in this project should draw attention from some of the authors of the other forks too. I hope some of them will feel inspired to build on top of this work.
Judging from our private HPGCC3 conversation a few years back, I'm sure you can relate to the privacy objections that stop me from doing the GitHub push myself, so I really do appreciate the offer.